From nobody Sun Nov 1 03:00:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63353A1070 for ; Sun, 1 Nov 2020 03:00:12 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPES_CFyeZrY for ; Sun, 1 Nov 2020 03:00:10 -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 471673A1071 for ; Sun, 1 Nov 2020 03:00:10 -0800 (PST) Received: (qmail 84092 invoked by uid 100); 1 Nov 2020 11:00:09 -0000 Date: 1 Nov 2020 10:59:45 -0000 Message-ID: <20201101105945.84082.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 1 06:00:08 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 11:00:13 -0000 Count | Bytes | Who ------------+----------------+------- 1 (16.7%) | 11204 (30.7%) | Seth Blank 1 (16.7%) | 6786 (18.6%) | Tim Wicinski 1 (16.7%) | 6117 (16.8%) | Kurt Andersen (b) 1 (16.7%) | 5402 (14.8%) | Steven M Jones 1 (16.7%) | 4222 (11.6%) | Alessandro Vesely 1 (16.7%) | 2781 ( 7.6%) | John Levine From nobody Mon Nov 2 09:44:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BD23A11BC for ; Mon, 2 Nov 2020 09:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=adqnKSPe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JzIJyd3O Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnzsEPrkSvKW for ; Mon, 2 Nov 2020 09:44:27 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAC83A0EBA for ; Mon, 2 Nov 2020 09:44:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 23750968; Mon, 2 Nov 2020 12:44:27 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Mon, 02 Nov 2020 12:44:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=k5GOn lUOQdByQqgGznuBBcfOba/DYk6oJLSjCNxB7Qc=; b=adqnKSPeFpIVfwxrcqzua XM+jF89Es9Vc6Yn18/NK95JWbGMkFS2XA7aOuN+JRu2RaCyLQt0tO2B2C5wfcUqv 6ESlb3zb1/72nKWarxq7dG2saJkkp9BrwjZ5hsC1dwpMd6bXtwsJlidU9MZzgkfL 9CM/Cwtpi2yGZjAGinpiPk7YFFiVINV/UIPZaRIJlovlhi9Bzj3AvUkJLI0AI5qp 5dQ84vZoeXTI/xzxRMGXB6wEBISYQEW4jb2Cba3CxmTLM01Ano22sxzyNsODZb1W AyeUxBUcEFoVngI1ayJQQyggPwivglbPwg4LoKFmMnZu6xEby+3yhkSwDonUxRLP w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=k5GOnlUOQdByQqgGznuBBcfOba/DYk6oJLSjCNxB7 Qc=; b=JzIJyd3OZv+obE8GmHJUfJBES9Fpod1giRLgVO5j6mocRKcjI1R6Q12ti Dk+kQpWEdZ0osvfNrcMKK7T3mybbbJ9UnKWy111tL/KKemVbUW0Av7k/7Wq5IZCh LjFra0e7xIjqNZRFJfx23eTB7CMJoC93iK9QC8d16EdwfKEQWVyR1vfMZOSCC42i QdCY/4rttBwDEzouKh4gYPt6TFpeFeKXJAxm7wnEsyNRzIkAEIqKIJh86GmZW0+H +445NvGBqVI9neWBuIjj9Jlq2hVwrmTyIuNcZ/UYAyykQlMifUAcWhdVt1cGZgrq w0H9Pu6Jfva1dqDn8+UWfw4mPDflQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtuddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet lhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrih hlrdhfmheqnecuggftrfgrthhtvghrnhepleeiffelueeufeekleejfeeiheegjedtvddt udffueefveevfedtfeekueduveffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D6A31660069; Mon, 2 Nov 2020 12:44:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: <15f9054f-f32c-4be7-a812-79d7754c5610@www.fastmail.com> In-Reply-To: <3b1ee23c-cb27-1f0c-1abc-6bd6967d8b22@tana.it> References: <3b1ee23c-cb27-1f0c-1abc-6bd6967d8b22@tana.it> Date: Mon, 02 Nov 2020 17:44:03 +0000 From: "Alexey Melnikov" To: "Alessandro Vesely" , dmarc@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Nov 2020 17:44:36 -0000 Hi Alessandro, On Tue, Oct 27, 2020, at 8:17 AM, Alessandro Vesely wrote: > On Mon 26/Oct/2020 22:58:50 +0100 Tim Wicinski wrote: > > Please review this draft, and we are looking for *objections to adop= tion*, and=20 > > send comments to the list stating your objections.=C2=A0 The working= group can pick=20 > > over the document after adoption. > >=20 > > Also, the Chairs have announced that the document will be split into= multiple=20 > > pieces. The details around this split will be sent out shortly in a = separate email. >=20 >=20 > I don't think there is going to be much use of the document after the = split. The idea is that we are starting from adopting a known document in a kno= wn state, which will take less time than discussing 3 adoption calls of = documents that are nowhere ready for the WG to review. > Perhaps, it's more efficient to split the document first, so as to let= the WG=20 > review documents which are more or less in their final shape. Adoptin= g and=20 > discussing a document that is not going to be published as RFC seems r= ather=20 > tortuous. IMHO, adopting 3 documents will take much longer and we can start spinni= ng wheels discussing whether certain changes represent WG consensus, etc= . > I'm not objecting, I'm just confused. Best Regards, Alexey From nobody Mon Nov 2 12:17:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532FC3A0F00 for ; Mon, 2 Nov 2020 12:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=SOr3zP08; dkim=pass (2048-bit key) header.d=taugh.com header.b=O509ZnYM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDuLojxC8bVD for ; Mon, 2 Nov 2020 12:17:48 -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 C1BDE3A0E8F for ; Mon, 2 Nov 2020 12:17:47 -0800 (PST) Received: (qmail 24762 invoked from network); 2 Nov 2020 20:17:45 -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:cleverness; s=60b8.5fa06969.k2011; bh=hBJqhG7Eg3Sz5gaSHKSoWjMiOJq5URMybjvGpQfje4U=; b=SOr3zP08301yB/oc4Fy2Mx9BgqT+hHsryYgGqR7meHT+Z9fsTa63O8D2NvQmZf9Yq5UwaF1n5sbE6eq421bOQTPKYO9qexWs/e2+RKr2eZFV/8/I30ZstMXIJrldlFCZIklJ5v+qxT8T1l0EnsX/Zq/YrZpKv0arrtdkRjRjDfNwbgJNplXxUnytRSCemByLh36+5HJmjHiG8cvGqlrKvFtmgn0Z4rcNjCTZpi2bTtc4Z3NWoRwCYjCxdG+riX/ubzwGYgoZ5IENmR0Ph+LiUFzMqkFkfbGFLg1ZN5LkUqN+SB8kcOoKU0i8oBM865jLa57ccgdo/QNHi+wkD+elTw== 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:cleverness; s=60b8.5fa06969.k2011; bh=hBJqhG7Eg3Sz5gaSHKSoWjMiOJq5URMybjvGpQfje4U=; b=O509ZnYMv5RgqFcI05nWBoWpu2h7EmIhMdj94MVHILIKpxY5NHwLi6BkpKywPk7NR2qYfYTkil/lDz/S8fcLlKUDFCUVbcQCF6XolXYv0bxH/61e3TQZAb69pS6BKNE8ee/tobOg9xJuW0Fdx0iczaj4iosv8PvS3R+QlFn852oRb7Zbf1QhSLOfHvguqNELwMnNaZfHZN9q9K+tekQkq1ML26E+guqDVqsPBsb0ilDhaPhREAT2vUAqVivL0sToIBgLQllwpunSM64ZajxajZsLJDUBeZfkY/kvs4zWq1ZrF/ehnE0eW8e6re5ft4npc56TJUseUX5XWMsVUkOgrw== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Nov 2020 20:17:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 0E93D2546358; Mon, 2 Nov 2020 15:17:44 -0500 (EST) Date: 2 Nov 2020 15:17:44 -0500 Message-Id: <20201102201745.0E93D2546358@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: aamelnikov@fastmail.fm In-Reply-To: <15f9054f-f32c-4be7-a812-79d7754c5610@www.fastmail.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Nov 2020 20:17:49 -0000 In article <15f9054f-f32c-4be7-a812-79d7754c5610@www.fastmail.com> you write: >The idea is that we are starting from adopting a known document in a known state, which will take less time than >discussing 3 adoption calls of documents that are nowhere ready for the WG to review. Sounds good to me. I think we already have a fairly good idea of how it will be split up and the details are part of the WG editing process. R's, John From nobody Tue Nov 3 09:21:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373823A0DF6 for ; Tue, 3 Nov 2020 09:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuExBIqdVCP5 for ; Tue, 3 Nov 2020 09:21:20 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0043A0DEE for ; Tue, 3 Nov 2020 09:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1604424077; bh=sW9C8yOwT/GFAS12MhEbFcXrV6yjK6bv3NdeJ/zRkIw=; l=676; h=To:Cc:References:From:Date:In-Reply-To; b=AI9TEhhHzWCirFC0dZqONAHCPuLX+vm9B5ukYUA6ZkwU2LEhR6JOja8h9D1ladP/Y MYE45W9TTL69Rh45yts2woe3R/Qe0e6xoVUa62Y9OpicRGCU6DUgnrJwKdtCjNSloN Rc/yhuxrfLTAw9niz2b1ODPHznetwRNujX9d644QQmgOjod8s89zojU16rJ95 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: aamelnikov@fastmail.fm Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005FA1918D.000053A8; Tue, 03 Nov 2020 18:21:17 +0100 To: dmarc@ietf.org Cc: aamelnikov@fastmail.fm References: <20201102201745.0E93D2546358@ary.qy> From: Alessandro Vesely Message-ID: <82a6950f-bb95-0f75-b0ee-868af0ed5d09@tana.it> Date: Tue, 3 Nov 2020 18:21:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201102201745.0E93D2546358@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 17:21:21 -0000 On Mon 02/Nov/2020 21:17:44 +0100 John Levine wrote: > In article <15f9054f-f32c-4be7-a812-79d7754c5610@www.fastmail.com> you write: >>The idea is that we are starting from adopting a known document in a known state, which will take less time than >>discussing 3 adoption calls of documents that are nowhere ready for the WG to review. > > Sounds good to me. I think we already have a fairly good idea of how > it will be split up and the details are part of the WG editing > process. Oh, well, if adopting draft-kucherawy-dmarc-dmarcbis is a shortcut for adopting each of the three drafts that are going to follow it, I endorse the adoption. Best Ale -- From nobody Wed Nov 4 17:38:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF7B3A124E; Wed, 4 Nov 2020 17:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 vhbzCeAe2QhV; Wed, 4 Nov 2020 17:38:34 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 639743A124F; Wed, 4 Nov 2020 17:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=63Uh1YMncnnEUG5MurByIVq3K5BdChybZOjN86SQ57Q=; b=iLOVDMEuTLdFMQrBv8eRJzrOda 7svSkm9TDC0LjUF1Ydi8iOZylu93LxZNhpurTuYH8laqtiHm2PPEIGLeZGzns44sb8SrL473uDzXe dlEbER7pZsJwaVlpDHpbClpze4vi+fIflZWO45ye1Q7/+nE+PFhZiSvSp2I3mhAZA7Ts=; Received: from [2601:647:4400:1261:5c1f:d944:a68e:80d4] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kaUER-0004xW-Sl; Wed, 04 Nov 2020 17:38:34 -0800 From: "Jim Fenton" To: "Seth Blank" Cc: "IETF DMARC WG" Date: Wed, 04 Nov 2020 17:38:31 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_238AC6C6-FAD7-4B1A-A6CB-7E885A227E8E_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[1279, 4325], "plain":[897, 2454], "uuid":"C271853A-9A72-47D9-9487-1F6C9FB1AF2E"}] Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 01:38:37 -0000 --=_MailMate_238AC6C6-FAD7-4B1A-A6CB-7E885A227E8E_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I gather then that policy is part of the Base specification, and that it is assumed that reporting will not be implemented without also implementing policy. I don’t think that’s a good assumption. I would suggest instead that the base specification describe the common pieces: lookup of the DMARC record from the From: header field (or perhaps some combination of header fields recently discussed), format of the DMARC record making provision for extensibility by other DMARC specifications, and anything else that is common to both policy and reporting. A second specification would be policy, including much of what is in Section 6 of Murray’s draft except for things like policy discovery that would be in the base specification. I’m neutral on whether the aggregate and failure reporting specifications are separate or combined. -Jim On 27 Oct 2020, at 9:29, Seth Blank wrote: > One of the primary activities of the WG to review and improve the base > DMARC specification. As the chairs sat down and reviewed the issues > raised > by everyone in the issue tracker > (https://trac.ietf.org/trac/dmarc/report/1), we felt it would be > better to > split RFC7489 into three > documents. All this work will benefit from multiple document editors > working on specific pieces and interacting with the WG. After an open > call > for volunteers, we selected individuals from the community with the > idea of > balancing bringing new document authors with those with experience > with the > IETF process. > > Assuming draft-kucherawy-dmarc-dmarcbis is adopted (see the adoption > thread > started by Tim), we will then split the draft into three documents > scoped > as follows, with the corresponding editors below. > > The drafts will live in GitHub, but all issues are to be managed via > the > IETF Trac tool. All issues will continue to be discussed and resolved > on > the mailing list. > > 1. Base Spec > > * Define terms and operational implications that are now better > understood > * Clean up confusing or remove unused tags > * Address nits and errata > * Clarify Organizational Domain lookups or remove definition from base > spec > * Incorporate ARC or something that deals with indirect mailflows > > Editors: > - Emil Gustafsson, Google > - Todd Herr, Valimail > - John Levine > > 2. Aggregate reporting > > * Address reporting nits and clarifications > * Provide for more flexible reporting > * Handle ARC data in a structured manner > > Editors > - Alex Brotman, Comcast > > 3. Failure reporting > > * Create a simplified failure report > * Address privacy considerations > > Editors > - Steve Jones, LinkedIn > - Alessandro Vesely > > Thanks everyone, and join us in thanking our editors for volunteering, > > Seth, Tim, and Alexey, as Chairs > > -- > > *Seth Blank* | VP, Standards and New Technologies > *e:* seth@valimail.com > *p:* 415.273.8818 > > > This email and all data transmitted with it contains confidential > and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is > prohibited > and may be unlawful. Please immediately notify the sender by replying > to > this email and then delete it from your system. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=_MailMate_238AC6C6-FAD7-4B1A-A6CB-7E885A227E8E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I gather then that policy is part of the Base specificatio= n, and that it is assumed that reporting will not be implemented without = also implementing policy. I don=E2=80=99t think that=E2=80=99s a good ass= umption.

I would suggest instead that the base specification descr= ibe the common pieces: lookup of the DMARC record from the From: header f= ield (or perhaps some combination of header fields recently discussed), f= ormat of the DMARC record making provision for extensibility by other DMA= RC specifications, and anything else that is common to both policy and re= porting.

A second specification would be policy, including much of= what is in Section 6 of Murray=E2=80=99s draft except for things like po= licy discovery that would be in the base specification.

I=E2=80=99m neutral on whether the aggregate and failure = reporting specifications are separate or combined.

-Jim

On 27 Oct 2020, at 9:29, Seth Blank wrote:

One of the primary activities of the WG to review and impr= ove the base DMARC specification. As the chairs =C2=A0sat down and review= ed the issues raised by everyone in the issue tracker
(https://trac.ietf.org/trac/dmarc/= report/1), we felt it would be better to split RFC7489 into three documents. All this work will benefit from multiple document editors wor= king on specific pieces and interacting with the WG. After an open call f= or volunteers, we selected individuals from the community with the idea o= f balancing bringing new document authors with those with experience with= the IETF process.

Assuming draft-kucherawy-dmarc-dmarcbis is ado= pted (see the adoption thread started by Tim), we will then split the dra= ft into three documents scoped as follows, with the corresponding editors= below.

The drafts will live in GitHub, but all issues are to be m= anaged via the IETF Trac tool. All issues will continue to be discussed a= nd resolved on the mailing list.

1. Base Spec

* Define ter= ms and operational implications that are now better understood
* Clean= up confusing or remove unused tags
* Address nits and errata
* Cla= rify Organizational Domain lookups or remove definition from base spec* Incorporate ARC or something that deals with indirect mailflows
Editors:
- Emil Gustafsson, Google
- Todd Herr, Valimail
- John= Levine

2. Aggregate reporting

* Address reporting nits and= clarifications
* Provide for more flexible reporting
* Handle ARC = data in a structured manner

Editors
- Alex Brotman, Comcast
=
3. Failure reporting

* Create a simplified failure report
*= Address privacy considerations

Editors
- Steve Jones, LinkedIn=
- Alessandro Vesely

Thanks everyone, and join us in thanking o= ur editors for volunteering,

Seth, Tim, and Alexey, as Chairs
<= div>
--

Seth Blank | VP, S= tandards and New Technologies
p: 415.273.8818


<= font color=3D"#666666" face=3D"Arial">This email and all data transmitted with it contain= s confidential and/or proprietary information intended solely for the use= of individual(s) authorized to receive it. If you are not an intended an= d authorized recipient you are hereby notified of any use, disclosure, co= pying or distribution of the information included in this transmission is= prohibited and may be unlawful. Please immediately notify the sender by = replying to this email and then delete it from your system.=

______________________= _________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--=_MailMate_238AC6C6-FAD7-4B1A-A6CB-7E885A227E8E_=-- From nobody Thu Nov 5 08:46:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEAC3A17F6 for ; Thu, 5 Nov 2020 08:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFrXMS09Ieb8 for ; Thu, 5 Nov 2020 08:46:36 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABBA3A17F7 for ; Thu, 5 Nov 2020 08:46:36 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id z2so1941480ilh.11 for ; Thu, 05 Nov 2020 08:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7BuH0WOHCsadIm9pz39541nCPf28triIbhTyMTV73Qk=; b=EQz8UWtB0mRr5rHhZmZCTn1SA2UVDHZTdEbgoNt7edO7mmgc/18I1bOIYLqfwM6D7f s3Lw0drC8SL3UeVXp46QxRgCj5HjpGhG4IFxfjxXa9bONK7d1NWHQPx/p5m/QIlmzX+4 RJ60obcZ8Xv/Kzr5gD0h9zg7OCrDrTc0bFn+eDSsWas3/yiyP6l4TXiBH7ucPpXaHH6U uPvgpset9Mq2aUGdbR5q1pdKcEyj58V50mTsGwEClr4Ybz5lNqI+chOLlnyKXIU7HkEh qOBQGupoS9DMK4Eloz8gb189mASh+uD3Sl4hvJ3/748yraj8QRoAmikr0ZO/FS7wp+6Q J10A== 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=7BuH0WOHCsadIm9pz39541nCPf28triIbhTyMTV73Qk=; b=NV5eGc7+hzqurNDDVFlWq4lu3HBG6XjCDjsZauKp1nDF4VHE4SW+Ua4snUhC1uDN+S s1zggVm2jnyVfdN/g1qZfvXxIZzqihaEKoPb2eIi2MjkH0idGtcZJ/A2YYEWENek1hdI sSqbhn8GRs3WSVjlW6+IHWXi9R1d30zygBY3GnU49X8znQvPQimje/5CJ4q5FqvrTBCf +m5ONzKJBfeazBKJd4e+/Gf9uBdYAwSJwv5MgmHtKu0ynBA0H0oXTzLHwTyoBweRuKhN mxH4Szua0vNmmKDh5VNZd3EKzyHdDeaAAtAGHYCZBIk5Cj4u2aOdpyi/E5OCsu6GPklu XBqg== X-Gm-Message-State: AOAM533b85ZYy64Pd26OhDgf+nzI/h0491Pu3ISPPQhicJnYXc3X9nve RmwYjfrlztzPCxcgGBUV0NXI9REATLyUjX7x9q1PKJ0Gszg= X-Google-Smtp-Source: ABdhPJxxmrbURu/+41RASGCn5EdYNvdeS9rPcT1Dh5wUvYAbvLd6Mi15iR1L11S5soCTgF5yd6kOqdyQ9E9xRZVknqg= X-Received: by 2002:a92:cd51:: with SMTP id v17mr2414268ilq.98.1604594795435; Thu, 05 Nov 2020 08:46:35 -0800 (PST) MIME-Version: 1.0 References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> In-Reply-To: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> From: Todd Herr Date: Thu, 5 Nov 2020 11:46:19 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ca747705b35ed627" Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 16:46:39 -0000 --000000000000ca747705b35ed627 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 4, 2020 at 8:38 PM Jim Fenton wrote: > I gather then that policy is part of the Base specification, and that it > is assumed that reporting will not be implemented without also implementi= ng > policy. I don=E2=80=99t think that=E2=80=99s a good assumption. > > I would suggest instead that the base specification describe the common > pieces: lookup of the DMARC record from the From: header field (or perhap= s > some combination of header fields recently discussed), format of the DMAR= C > record making provision for extensibility by other DMARC specifications, > and anything else that is common to both policy and reporting. > > A second specification would be policy, including much of what is in > Section 6 of Murray=E2=80=99s draft except for things like policy discove= ry that > would be in the base specification. > > I=E2=80=99m neutral on whether the aggregate and failure reporting specif= ications > are separate or combined. > > > Hatless... Respectfully, I disagree with the suggestion made here to move policy to a separate document. DMARC at its core is the requested mail receiver policy that's expressed in the p=3D tag; in the draft specification, p=3D and v=3D= are the only two required tags, and I can't envision a world where policy isn't implemented as a requirement to implement DMARC. Moving discussion of policy to a second specification would render any base specification to be no more than effectively a table of contents pointing to other documents, which seems to me to be a pointless document to produce= . --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ca747705b35ed627 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 4, 2020 at 8:38 PM Jim Fenton= <fenton@bluepopcorn.net&g= t; wrote:

I gather then that policy is part of the Base specification, a= nd that it is assumed that reporting will not be implemented without also i= mplementing policy. I don=E2=80=99t think that=E2=80=99s a good assumption.=

I would suggest instead that the base specification describ= e the common pieces: lookup of the DMARC record from the From: header field= (or perhaps some combination of header fields recently discussed), format = of the DMARC record making provision for extensibility by other DMARC speci= fications, and anything else that is common to both policy and reporting.

A second specification would be policy, including much of w= hat is in Section 6 of Murray=E2=80=99s draft except for things like policy= discovery that would be in the base specification.

I=E2=80=99m neutral on whether the aggregate and failure re= porting specifications are separate or combined.


Hatless...

Respectfully, I disagree with the suggestion made here= to move policy to a separate document. DMARC at its core is the requested = mail receiver policy that's expressed in the p=3D tag; in the draft spe= cification, p=3D and v=3D are the only two required tags, and I can't e= nvision a world where policy isn't implemented as a requirement to impl= ement DMARC.=C2=A0

Moving discussion of policy to = a second specification would render any base specification to be no more th= an effectively a table of contents pointing to other documents,=C2=A0which = seems to me to be a pointless=C2=A0document to produce.

--

Todd Herr | Sr. Technical Program Manager
e: todd.herr@valimail.com
p: 703.220.4153


This email and all data transmitted with it contains confid= ential and/or proprietary information intended solely for the use of indivi= dual(s) authorized to receive it. If you are not an intended and authorized= recipient you are hereby notified of any use, disclosure, copying or distr= ibution of the information included in this transmission is prohibited and = may be unlawful. Please immediately notify the sender by replying to this e= mail and then delete it from your system.

--000000000000ca747705b35ed627-- From nobody Thu Nov 5 09:31:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B13D3A1919 for ; Thu, 5 Nov 2020 09:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvbCv-K4z6YB for ; Thu, 5 Nov 2020 09:31:25 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD443A18E0 for ; Thu, 5 Nov 2020 09:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1604597482; bh=kVIUq3hza+HaaB+Btaa3xgSBbTJ5okEOHoBzkC9t8Pc=; l=1978; h=To:References:From:Date:In-Reply-To; b=Cd9CjAN+9qXeUivdpsaNML2M8lmFV9lAEe1+AU7KnO8LdCzMy2adV4gDQdDoWdCqu pcrmtew3xbOus2fccCDR/tPLjlmZ4oEtyBq7Hfl37RijT4UHaS7BzQLd6Z/6Hj8nCp EWidUaG0O35yRzRtrdDKuJX9ABiWCK9CpaNnWVzz4DfwEaT2W71jzX1wX0ylr Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FA436EA.0000064D; Thu, 05 Nov 2020 18:31:21 +0100 To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> From: Alessandro Vesely Message-ID: <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> Date: Thu, 5 Nov 2020 18:31:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:31:27 -0000 On Thu 05/Nov/2020 17:46:19 +0100 Todd Herr wrote: > On Wed, Nov 4, 2020 at 8:38 PM Jim Fenton wrote: > >> I would suggest instead that the base specification describe the common >> pieces: lookup of the DMARC record from the From: header field (or perhaps >> some combination of header fields recently discussed), format of the DMARC >> record making provision for extensibility by other DMARC specifications, >> and anything else that is common to both policy and reporting. >> >> A second specification would be policy, including much of what is in >> Section 6 of Murray’s draft except for things like policy discovery that >> would be in the base specification. >> >> I’m neutral on whether the aggregate and failure reporting specifications >> are separate or combined. >> > > Respectfully, I disagree with the suggestion made here to move policy to a > separate document. DMARC at its core is the requested mail receiver policy > that's expressed in the p= tag; in the draft specification, p= and v= are > the only two required tags, and I can't envision a world where policy isn't > implemented as a requirement to implement DMARC. That's the old spec. The consensus of the working group is to remove the normative constraint about p= (ticket #49). So now only v= is required. > Moving discussion of policy to a second specification would render any base > specification to be no more than effectively a table of contents pointing > to other documents, which seems to me to be a pointless document to produce. Operators who don't need policy, for example external report receivers who just want to publish verification records, would find the relevant info in the base spec. A good point of Jim's proposal is that having policy in a separate spec, in the same manner as reports, avoids the unintended effect of classifying reports as a 2nd class, generally-not-used feature. jm2p Ale -- From nobody Thu Nov 5 09:44:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332A73A1935 for ; Thu, 5 Nov 2020 09:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdJnGBB0NO-H for ; Thu, 5 Nov 2020 09:44:09 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E263A1919 for ; Thu, 5 Nov 2020 09:44:08 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id u21so2625845iol.12 for ; Thu, 05 Nov 2020 09:44:08 -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=7werzHTJsOhgA1KrymBvR+Ex/wHrxhXDeSoiYSD+Tus=; b=Bl6+5r4S6AAHqPF0kgjuYI99KKLdD0wcv3rOTg9a945Vf8UuJHrEasjoyLZTgoYPAJ oskrH1fq+h2FgNM+PxgJRdjh0APcKg3M/8Pmr35CQAJiagl/cofe4vCg+Dd8989IRsMZ K+V7/55wJUxO9B4Eq3uzxAhv6ZVSjRpd1Er6k= 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=7werzHTJsOhgA1KrymBvR+Ex/wHrxhXDeSoiYSD+Tus=; b=JRCg1kD9SKvlgxUzfuLhZOiqC5eeJxjCPUHhCOohhHiqCHoQvSPkPyjokF61rfP+j0 GiQXLPSMlmkZnENhm9Dl69DYSQrxPv6j5pz0Hg2vVKJyqEHnHxbMRwxvvNPdnalU4BBb dm3JYBF1+MpjhCNvCEi+WtPVvuSAsFUHXOiECazE4QDjXDwvjbi2gwNpUbCS5U/9VWBH RUP89CG242QSYoVvnyn7lb0DlxYYxivdSZnLZy/kf+oH4wA4GLPsL1ncW4KSVK48JyWd UXEUa7l1/0613Lwt0disqI2sQOrnIOtLE40lthwh52O0ybez8JvRm8Ulv5lWJzAWZ/U2 qAFA== X-Gm-Message-State: AOAM532fbh00bKp+o+aE/Q1XbVhax8s8JfECryUH6YXNoKTxkQAqWkJI A2hmh6FHd7Itc0txDhAzmkKafrottzcyAIcC/ThUdQfMQu4= X-Google-Smtp-Source: ABdhPJwSd0MlrX39xHDKe/z9rBWzYJ+YTwzvrawpQW3ovIcmNhuwMjqmdgBUPWP2zh7QhgVj2M8+5H8QM07tgF3PG0E= X-Received: by 2002:a6b:fb07:: with SMTP id h7mr2495667iog.163.1604598248089; Thu, 05 Nov 2020 09:44:08 -0800 (PST) MIME-Version: 1.0 References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> In-Reply-To: <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> From: "Kurt Andersen (b)" Date: Thu, 5 Nov 2020 09:43:44 -0800 Message-ID: To: Alessandro Vesely Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095c1ea05b35fa453" Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:44:11 -0000 --00000000000095c1ea05b35fa453 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote: > The consensus of the working group is to remove the > normative constraint about p= (ticket #49). So now only v= is required. > I must have completely misunderstood the discussion and will have to go back and look up the thread. I thought that the discussion was strictly about whether the "p=" phrase had to be the second phrase in the record. --Kurt --00000000000095c1ea05b35fa453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 5, 2020 at 9:31 AM Alessandro= Vesely <vesely@tana.it> wrote:=
The consensus of the working group is to remove the
normative constraint about p=3D (ticket #49).=C2=A0 So now only v=3D is req= uired.

I must have completely misunders= tood the discussion and will have to go back and look up the thread. I thou= ght that the discussion was strictly about whether the "p=3D" phr= ase had to be the second phrase in the record.

--K= urt=C2=A0
--00000000000095c1ea05b35fa453-- From nobody Thu Nov 5 09:45:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F573A1939 for ; Thu, 5 Nov 2020 09:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRcYt47yvtAk for ; Thu, 5 Nov 2020 09:45:38 -0800 (PST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 549DA3A1935 for ; Thu, 5 Nov 2020 09:45:38 -0800 (PST) Received: by mail-wm1-x32a.google.com with SMTP id c18so2438643wme.2 for ; Thu, 05 Nov 2020 09:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=w6QWG3+qh8OIcFaa73Bq2R7AeDaK4nFawLQab29VeQc=; b=P+Nnyc5WH/zGKNZqQSFbuMkjP+SkhiCn023i8YTJBYEGMtLjojeumiI32wZpCCTV27 L02vqRzd0Ovk+yR1SbfcqfmPqofrh2uXJHUKnqNWvMuYG7mf18A4BSCRsoQY5NA2fXjH vZhJucVZLKsZszstPN1IBefR6nBrwQaywPWuO4do6lrlqDRt375IgRCWyGS1EnwyZyud 3XUP6MyA1qiVOHrH6+JNz9uB4Cxv+7qzb9fzkor7xe+M5IhSKHJiALVULDbeJRSrO4/c FqaZvdiEb+3BK7Os8hAAysnW4INy0gjVEDwWceZu/VbxamXB5sEyPs0pwuKDhdE52dS/ tvFw== 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=w6QWG3+qh8OIcFaa73Bq2R7AeDaK4nFawLQab29VeQc=; b=QYLDcMmFtRKbHdfU1toELmuLb9zoJh4EcJrFqFPq7QQTMMmBc6qvmVRRU0nFOcKv2e qxI9of9p/XPTOn47GbE0NbUkF8MrBIy/bZPAkxKMdWfJTRg8vRVSlcJfVS4danyFNt1g r5U54visyzS/GcavWcN3CB1pjuEo4jvGyjNi/nFEN7UxwRddiZDmlhcHBA/XLh03FVSA YjQEJuIAv2AIob8AgjY3bD9uzmmwupSL9NA9r8HJIMgFoVTHfizxGsZejiAK9RL+aeag yuheQM5xUcQnmoQ9HkjWMu/lJLMqNA0vEOPC0qFWj4dDw68vyNo7YMN8GJj7IsYvUOB8 PQew== X-Gm-Message-State: AOAM532cgNhzjntWnKD71b//jUdM+WqjnLDRFPvU/CK75KsTCuaw8GV4 P33NdaqBqZTUJw7mrVftdE+wUP1+oCxkxwBvmZwXns6+FGvfaw== X-Google-Smtp-Source: ABdhPJwVG1L4wYzTXCL6iBfwayElmkiv+XqLMw4L/p7n4T3FR01z2yD2XAjoN3UhmhQmWlVhrsWFuNdGzRgpT10Luvo= X-Received: by 2002:a1c:80cb:: with SMTP id b194mr3916410wmd.73.1604598336245; Thu, 05 Nov 2020 09:45:36 -0800 (PST) MIME-Version: 1.0 References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> In-Reply-To: <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> From: Seth Blank Date: Thu, 5 Nov 2020 09:45:25 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d6f21a05b35fa93d" Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:45:40 -0000 --000000000000d6f21a05b35fa93d Content-Type: text/plain; charset="UTF-8" On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote: > That's the old spec. The consensus of the working group is to remove the > normative constraint about p= (ticket #49). So now only v= is required. > As Chair, this is not the consensus of the group, nor what ticket #49 ( https://trac.ietf.org/trac/dmarc/ticket/49) says. What we removed was the normative requirement that p= MUST be the second tag in the record. p= is still REQUIRED. To Todd's point, DMARC is a means of communicating policy between domain owner and mail receiver regarding how to handle unauthenticated mail. DMARC does not function without policy. If someone believes policy can be spun out into a separate draft, please upload your suggestion as an I-D and we will discuss it. Seth -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000d6f21a05b35fa93d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 5, 2020 at 9:31 AM Alessandro= Vesely <vesely@tana.it> wrote:=
That's the old spec.=C2=A0 The consensus of the working gro= up is to remove the
normative constraint about p=3D (ticket #49).=C2=A0 So now only v=3D is req= uired.

As Chair, this is not the consen= sus of the group, nor what ticket #49 (https://trac.ietf.org/trac/dmarc/ticket/49) says. Wh= at we removed was the normative requirement that p=3D MUST be the second ta= g in the record. p=3D is still REQUIRED.

To Todd&#= 39;s point, DMARC is a means of communicating policy between domain owner a= nd mail receiver regarding how to handle unauthenticated mail. DMARC does n= ot function without policy.

If someone believes po= licy can be spun out into a separate draft, please upload your suggestion a= s an I-D and we will discuss it.

Seth
<= div>
--

=
Seth Blank= | VP, Standards and New Technologies
p: 415.273.8818 <= span>


This email and all data transmitted with it contains conf= idential and/or proprietary information intended solely for the use of indi= vidual(s) authorized to receive it. If you are not an intended and authoriz= ed recipient you are hereby notified of any use, disclosure, copying or dis= tribution of the information included in this transmission is prohibited an= d may be unlawful. Please immediately notify the sender by replying to this= email and then delete it from your system.

<= /div> --000000000000d6f21a05b35fa93d-- From nobody Thu Nov 5 11:55:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776763A19F5 for ; Thu, 5 Nov 2020 11:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2_SsG5nIwzg for ; Thu, 5 Nov 2020 11:55:38 -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 534F03A19FA for ; Thu, 5 Nov 2020 11:55:27 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0A5JwqKq020895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 5 Nov 2020 11:58:52 -0800 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 5 Nov 2020 11:55:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 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] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 19:55:39 -0000 On 11/5/2020 8:46 AM, Todd Herr wrote: > Moving discussion of policy to a second specification would render any > base specification to be no more than effectively a table of contents > pointing to other documents, which seems to me to be a > pointless document to produce. Separation has to have a compelling reason, mostly involving differences in anticipated revision patterns, or fundamental differences in the nature of their specifications. That is, they should be separate because, in practical terms, they have to be, either now or later. NOT making them separate will either now or later pose significant problems. The rationale for the the current, proposed separations should be posted in a message with a specifically-titled Subject: line and solid explanations for the choices. d/ ps. I think separating can be essential for some specifications. The challenge is how and why; the answers need to be compelling. A beginning point of consideration can be: Tussle in cyberspace: defining tomorrow's internet https://dl.acm.org/doi/10.1145/633025.633059 -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Nov 6 03:45:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A303A10DE for ; Fri, 6 Nov 2020 03:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phiY0pqqIMYt for ; Fri, 6 Nov 2020 03:44:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C683A10DD for ; Fri, 6 Nov 2020 03:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1604663096; bh=kubOptcraEWz9H4NT0NDnHCfNwu/6ckoFrm2aYvu6c0=; l=1106; h=To:References:From:Date:In-Reply-To; b=CkxLh7ifvpqlYwaVUl2tzQZ5aKTsnPIcMFcbQzi6JyrH82784H22AcHCtpzuzez2l Ui+IwoLARqkBdJPP/EUAP6mvJazxJe8eLPrzfO5kBufIdem6pmwNjLRE0HHABRA36l PT+bA0AIqWF0g8YrE9+/a+I3VjDt4+mbrvZvnpUUhBZTPEkNB50O68syfTZVo Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FA53738.00006431; Fri, 06 Nov 2020 12:44:56 +0100 To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> From: Alessandro Vesely Message-ID: <1ffd98af-2842-5007-5094-e977a433aeb4@tana.it> Date: Fri, 6 Nov 2020 12:44:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 11:45:01 -0000 On Thu 05/Nov/2020 18:45:25 +0100 Seth Blank wrote: > On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely wrote: > >> That's the old spec. The consensus of the working group is to remove the >> normative constraint about p= (ticket #49). So now only v= is required. >> > > As Chair, this is not the consensus of the group, nor what ticket #49 ( > https://trac.ietf.org/trac/dmarc/ticket/49) says. What we removed was the > normative requirement that p= MUST be the second tag in the record. p= is > still REQUIRED. Oops, I must have been mistaken with ticket #72. My apologies. > To Todd's point, DMARC is a means of communicating policy between domain > owner and mail receiver regarding how to handle unauthenticated mail. DMARC > does not function without policy. It still has reporting, though... > If someone believes policy can be spun out into a separate draft, please > upload your suggestion as an I-D and we will discuss it. An I-D?! What kind of I-D? Couldn't we discuss it informally, just to see what most people think? Best Ale -- From nobody Fri Nov 6 03:58:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518A13A10F7 for ; Fri, 6 Nov 2020 03:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=QIaJjJd1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NxdoPeHl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpfljMRyuGmx for ; Fri, 6 Nov 2020 03:58:36 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFFB3A10F5 for ; Fri, 6 Nov 2020 03:58:36 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 45B1298B for ; Fri, 6 Nov 2020 06:58:35 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Fri, 06 Nov 2020 06:58:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=jJSrAIk5Sb01e7Mdczd9KoiEu99Q2Un 04ltz/M3aovY=; b=QIaJjJd109Cy0aBi3qgRJGS5TVEfLZkMKIOO0jIbttkcz+U szZANRTNVx+1mESNjou2ARU/A66h483OCk6QtU1SGdbP9jOgvqW3rfj1OD3jZsJP fXMuK2EAyTFNcyw5fQJzjEcRXRokQkRw6iGj4/zYiPpXhunoa0wRgzUdojWX2OYb oxibW0gGsZiA8OB1Sy9LfH2r7YCH6doAfuOSnkGjhN4ufTeA/auw7jPKEkl+1NBB HfDGVXY0ei0O0f7GScA3e3lJUwlP4s0HZWfoLjYgap8C7y2W1E43HQNqGVEFOSA7 J8gMBb+4dfCTIo6CpiguFCgIT47SYKk6zW4gznQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=jJSrAI k5Sb01e7Mdczd9KoiEu99Q2Un04ltz/M3aovY=; b=NxdoPeHl9IHhei3d175uzn MOciNboQKXV7AGXG5B6yn5hGcBykcz1ZBuPAnYXgmRcziSKJut3xCBAOZx8w9Y4t sBlRNxzS2YPt9OmUHPbSiIkNv/CfOLahFuBvussjuYNItKX1jQWlk7NM6eXvu9IW dc6j6rzufXtlQdt8n6xZBtWYGo5e0tYgE5ISxttsvra0soC+nHVQlqYgMjHreMsI uez1brcchPW5q7FoyDa/EnxWgCkDwEBduUfEo+Rok2WMjJsPrS4HCLWbFFGdGltE v8Gen01XZGLT0+GN4zDxkz7N4EgBzb+EWaXu+UWtG02ZkphNe9K9+oOXw6tNvhyw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigvgihucfovghlnhhikhhovhdfuceorggrmhgv lhhnihhkohhvsehfrghsthhmrghilhdrfhhmqeenucggtffrrghtthgvrhhnpeefveetke effeetteegtdeghfeigeeiteeghfekiefgudfhgfejvdduudekjeefieenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovh esfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ADACE660069; Fri, 6 Nov 2020 06:58:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-570-gba0a262-fm-20201106.001-gba0a2623 Mime-Version: 1.0 Message-Id: <9a7a6ec4-382a-4c28-b8ee-08cd14e775a2@www.fastmail.com> In-Reply-To: <1ffd98af-2842-5007-5094-e977a433aeb4@tana.it> References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <1ffd98af-2842-5007-5094-e977a433aeb4@tana.it> Date: Fri, 06 Nov 2020 11:57:47 +0000 From: "Alexey Melnikov" To: dmarc@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 11:58:37 -0000 On Fri, Nov 6, 2020, at 11:44 AM, Alessandro Vesely wrote: > On Thu 05/Nov/2020 18:45:25 +0100 Seth Blank wrote: [snip] > > If someone believes policy can be spun out into a separate draft, please > > upload your suggestion as an I-D and we will discuss it. > > > An I-D?! What kind of I-D? Couldn't we discuss it informally, just to see > what most people think? In order to be able to decide on this proposal, proposer(s) have to give enough details to enable other participants (including WG chairs) to decide whether such separation has benefits. At minimum this would require Table of Content and justification of benefits. Best Regards, Alexey From nobody Fri Nov 6 04:27:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A153A111E for ; Fri, 6 Nov 2020 04:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxZ_bBKsQKia for ; Fri, 6 Nov 2020 04:27:42 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB583A1119 for ; Fri, 6 Nov 2020 04:27:42 -0800 (PST) X-ASG-Debug-ID: 1604665658-11fa31480216430001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id uK3P7q3sPk8Ae24j (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 06 Nov 2020 07:27:38 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=V9P6GB0YYpyLAOaxyE/RdPAOH/fTxjpuMZrKU1XVav8=; b=MQ4BxGmIGbdutZYDp/RtdUeoAO9sHtsTwAuB+MxOf4D3OG9aivAul62zO7Gcu/aUO +++bX0HL3tiZl9KpMZmHUP5SSJbZYXF1N7B4SCoSKODPL0XkzJ5AWe3nQ+cS/2liT aOJouLWx1+H6d3RgJ4ErP+cXRkihiqMT6sDXiuL/k= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Fri, 6 Nov 2020 07:27:30 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Optional p= makes no sense Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=e7f5ab6c280f4d31acc10b3aebaaa661 In-Reply-To: References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> X-Exim-Id: f3536eca3bfa49a3b8aabcaac0313763 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1604665658 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2414 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85685 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 12:27:44 -0000 This is a multipart message in MIME format. --e7f5ab6c280f4d31acc10b3aebaaa661 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am just catching on to the implications of this discussion, and I must di= sagree It makes no sense to allow "p=3D" missing. Why would we suggest that all = existing implementations alter their code to tolerate additional unnecessar= y complexity, rather than requiring domain administrators to key a few more= characters so that code changes will not be necessary=3F There is no functional difference between "p=3D" missing and "p=3Dnone". B= oth configurations state: "I don't know what to tell you, you are on your o= wn." I also don't understand this comment from Allesandro : "Operators who don't need policy, for example external report receivers who= just want to publish verification records, would find the relevant info in the b= ase spec." There is only one policy record, published by the domain owner. The DNS re= cord either suggests enforcement (p=3Dquarantine, p=3Dreject) or it does no= t (p=3Dnone, p=3Dmissing, no DMARC record). Let's not add code complexity when it provides no benefit. Doug Foster --e7f5ab6c280f4d31acc10b3aebaaa661 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am just catching= on to the implications of this discussion, and I must disagree
<= br>
It makes no sense to allow "p=3D" missing.   Why would w= e suggest that all existing implementations alter their code to tolerate ad= ditional unnecessary complexity, rather than requiring domain administrator= s to key a few more characters so that code changes will not be necessary= =3F

There is no functional difference between "p= =3D" missing and "p=3Dnone".  Both configurations state: "I don't know= what to tell you, you are on your own." 

I a= lso don't understand this comment from Allesandro :

"Operators who don't need policy, for example external report receivers w= ho just
want to publish verification records, would find the relevant in= fo in the base
spec."

There is only one policy = record, published by the domain owner.  The DNS record either suggests= enforcement (p=3Dquarantine, p=3Dreject) or it does not (p=3Dnone, p=3Dmis= sing, no DMARC record).

Let's not add code complex= ity when it provides no benefit.


Do= ug Foster


--e7f5ab6c280f4d31acc10b3aebaaa661-- From nobody Fri Nov 6 05:58:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479A73A11C0 for ; Fri, 6 Nov 2020 05:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=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=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1rogkTTz4tM for ; Fri, 6 Nov 2020 05:58:03 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 52EFC3A11AF for ; Fri, 6 Nov 2020 05:58:03 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id n63so770401qte.4 for ; Fri, 06 Nov 2020 05:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=fJ88NIcoRUMh9FoSGgVi9bYnRnjuZstxt//oqeCWDFw=; b=FCsq/2SoWo4UNKaSHb3N4EBiay4FMmc22uYZP/a7M5NfaPVDVrgcKhWwJbXviBv9fE tgQgftYnPTY0lL5iPXjXOopYiT9ULG+5lb9au3xJO/cXsN+ZtEuxNGmS2w4btCpqpcJm QLp51j55gtePKyNmdIovgDWchDsDVKs98Ant9FOeyrFMa467dQ+Cg/WHrtssrAaUDsLa G3q1gvN/2wzRyQjZp68fdqrC2k3wXRq9pxm81ygIFVFxO8ACHYap+S1vdFqZMHpzswiZ al8E5EiMrOdrr5M9IICGg57DiEFAU8aseGqtyiWyow+iY4Q0AOwP4eNOcm5973h2IwZi 1qAQ== 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=fJ88NIcoRUMh9FoSGgVi9bYnRnjuZstxt//oqeCWDFw=; b=j2UILI1GhrZ/BASr80iafCyp7tdd4rTusMsSJNBHZcdaWIoBwNopaTJLWtFk5tSZ2z nFHljiUZ6CsfmLx8h6YlVIifRdgqHoIbjgIF7Fwg4H8lRVh8w/td3ZExE+DX86XQKEUa bt1WQqLwXQQ3pwWn/9m5EVYwFxRGltYQ1rf+5psNTb64AkoYsn9k7GDVP75ptM6Iso3t 6JXPCLE0A4tSBWh/4mQaV9eepJESnLcjayG2PacDxdWOJIkQkVWHJNsNsXsc8euIwEWl AWjRhX8pFVQASLe4kluzCYInjmpQUnlFu01puJa9nnQuv0/0HTTcL5AAWnTQp6AMUJPS MQSQ== X-Gm-Message-State: AOAM530eDBV+FKhqHqFfKJ2mKZcrr0NNKIaNjysHB3NhUSAf++RXNR94 9izZsUX4suswYY4Jf15LBoPhCzf4T+xZ21vBEsamWKYNj0JAYg== X-Google-Smtp-Source: ABdhPJzuYJvs2BjByCRgVIldUK1GXRHCQBoFJdcyY7Jj5YnBdwHhcm1VVW4+a0KYYdg6nzjtBMQgoq4VqhDokNnvOOg= X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr1593348qtw.298.1604671081829; Fri, 06 Nov 2020 05:58:01 -0800 (PST) MIME-Version: 1.0 References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> In-Reply-To: From: Todd Herr Date: Fri, 6 Nov 2020 08:57:46 -0500 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d06c2705b37099a1" Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 13:58:05 -0000 --000000000000d06c2705b37099a1 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: > I am just catching on to the implications of this discussion, and I must > disagree > > It makes no sense to allow "p=" missing. Why would we suggest that all > existing implementations alter their code to tolerate additional > unnecessary complexity, rather than requiring domain administrators to key > a few more characters so that code changes will not be necessary? > > There is no functional difference between "p=" missing and "p=none". Both > configurations state: "I don't know what to tell you, you are on your own." > I disagree with the assertion that p=none means "I don't know what to tell you". "p=none" is the starting point for all DMARC implementations in any non-trivial environment. "p=none" allows the domain owner, through the consumption of DMARC reports, to effectively audit their own understanding of their mailstreams and authentication practices, and address any shortcomings before eventually moving along, theoretically, to "p=quarantine" or "p=reject". > I also don't understand this comment from Allesandro : > > "Operators who don't need policy, for example external report receivers > who just > want to publish verification records, would find the relevant info in the > base > spec." > > There is only one policy record, published by the domain owner. The DNS > record either suggests enforcement (p=quarantine, p=reject) or it does not > (p=none, p=missing, no DMARC record). > > I can't speak for him, but I believe he's referring to the records that a report consumer outside the authority of the domain at issue might publish, as documented currently in https://tools.ietf.org/html/rfc7489#section-7.1. In those cases where, for example, foo.com publishes a DMARC policy record with a rua= value of say "reports@bar.org", there must exist a TXT record of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that bar.org is consenting to receive these reports. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000d06c2705b37099a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 6, 2020 at 7:27 AM Douglas E.= Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
I am just catching on to th= e implications of this discussion, and I must disagree

=
It makes no sense to allow "p=3D" missing. =C2=A0 Why would = we suggest that all existing implementations alter their code to tolerate a= dditional unnecessary complexity, rather than requiring domain administrato= rs to key a few more characters so that code changes will not be necessary?=

There is no functional difference between "p= =3D" missing and "p=3Dnone".=C2=A0 Both configurations state= : "I don't know what to tell you, you are on your own."=C2=A0=

I disagree with the assertion = that p=3Dnone means "I don't know what to tell you".

"p=3Dnone" is the starting point for all DMARC i= mplementations in any non-trivial environment. "p=3Dnone" allows = the domain owner, through the consumption of DMARC reports, to effectively = audit their own understanding of their mailstreams and authentication pract= ices, and address any shortcomings before eventually moving along, theoreti= cally, to "p=3Dquarantine" or "p=3Dreject".
<= br>

I also don't unders= tand this comment from Allesandro :

"Operator= s who don't need policy, for example external report receivers who just=
want to publish verification records, would find the relevant info in t= he base
spec."

There is only one policy re= cord, published by the domain owner.=C2=A0 The DNS record either suggests e= nforcement (p=3Dquarantine, p=3Dreject) or it does not (p=3Dnone, p=3Dmissi= ng, no DMARC record).


I can't speak for him, but I believe he's referring to the re= cords that a report consumer outside the authority of the domain at issue m= ight publish, as documented currently in=C2=A0https://tools.ietf.org/html/rfc7489#section-= 7.1. In those cases where, for example, foo.= com publishes a DMARC policy record with a rua=3D value of say "reports@bar.org", there must exis= t a TXT record of "v=3DDMARC1" at foo.com._report._dmarc.bar.org in order to confirm that bar.org is consenting to receive these reports.

--
<= /p>
Todd Herr | Sr. Technical Program Manager
p: 703.220.4153 <= /span>

<= /p>


This email and all data transmitted with it contai= ns confidential and/or proprietary information intended solely for the use = of individual(s) authorized to receive it. If you are not an intended and a= uthorized recipient you are hereby notified of any use, disclosure, copying= or distribution of the information included in this transmission is prohib= ited and may be unlawful. Please immediately notify the sender by replying = to this email and then delete it from your system.

=
--000000000000d06c2705b37099a1-- From nobody Fri Nov 6 10:09:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB283A0A81; Fri, 6 Nov 2020 10:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CgeQeWNATSc; Fri, 6 Nov 2020 10:09:25 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4BB3A0A7B; Fri, 6 Nov 2020 10:09:24 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id 79so2032224otc.7; Fri, 06 Nov 2020 10:09:24 -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=BivquxGACMSHTQ9KP0xWVEXjudzdm7OnNRn3++0jSxU=; b=nrJzF/nfNcEfTEkh87jhAdRexYQ4PSxx69HVvnZoExRviaCxLGVUMx6FZQrGNe1Qy+ 0+FhyXJ3Dl9+5ICvGgYzuWBOtOAzr8tfs4n24MGkZ0dIZtoy5tSmQXeUcZsvLKYCPy1z q+3kEPZ9BP6VJWXWatc1WJZx4ZJjSyiqCLnipKhVGz8ZpY7WwBscyBoiNXClj2n7bi0l MRQVLZiNf7cLn3Mwsqj6/8K+uzd7U26dPGdQG/9A0Fqy/yWv9ZQC9weiwhw9zoOQVDmA Hkj5zQVZMoEzofbcgUUUs+ktra6tOk/rDjrAmgvJEWr4xt+QLnybrsVHoWlvpW+UhKPH BSsw== 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=BivquxGACMSHTQ9KP0xWVEXjudzdm7OnNRn3++0jSxU=; b=SLYTRyxeDRVSOdPk9PeiPKRLMJyXZM3BMtFFFag8tOvtlqxfywwgr8V2U/8/40ksb1 D2+TIg9ckZlJbqbW+DQPnRnin1JEfHwGuyFt9Ie4g1mLnMjTL0WwID98Iup8BWbT2xAU YSV1TQVGynnPw12F3PBqYTucPeoA1H7FO4005F4AzGtqXs1hIcRjL4/EtZtXbbUftaTA xpAJ9GPJbbJGHLeDPLdZN49gm2+1j2xJLFQyzbWEAAebyz3DckgKLydI7cR+Ez5zuTF+ SZjFJgEUU2mBzHPaYs+Dl5B7fFAlhv+7vKe17zGmuZoD+Zk2O5l2W0v2mtks6npEWlUn E9XA== X-Gm-Message-State: AOAM5314RJP9kdoXMo0IDIlkvzeAuJrYE+pClizGbSv7/0Idtf1Qo8Gx Pk+8Z8sEpyRKIb90QzfV0rIZ12Pni5LUHnCAOYihEAtvIvE= X-Google-Smtp-Source: ABdhPJwBLhBYKsntTPUmxTJSKsXNVluqbQGWYxBO8Ueqvwst5+aOc/ElfK0gG6Gdj5qtfSwc+ijhN1dm20HsiciwQec= X-Received: by 2002:a05:6830:400d:: with SMTP id h13mr1964837ots.371.1604686162821; Fri, 06 Nov 2020 10:09:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Fri, 6 Nov 2020 13:09:11 -0500 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b6033705b3741ca1" Archived-At: Subject: Re: [dmarc-ietf] Subject: Call for Adoption: DMARC-bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 18:09:27 -0000 --000000000000b6033705b3741ca1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All The call for adoption ended earlier in the week, with the document being adopted, and split. Since the existing document was going to be split, we will wait until the editors produce their documents and those will be adopted. Thanks tim On Mon, Oct 26, 2020 at 5:58 PM Tim Wicinski wrote: > > All > > While the chairs are aware that working on DMARC-bis is the charter of th= e > working group, we want to ensure the process is followed. > > This starts a Call for Adoption for: DMARC-bis > > We'll be starting with the text from the RFC 7489. > This is available here: > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ > > Changes made so far have been to include the current Errata. > > Please review this draft, and we are looking for *objections to adoption*= , > and send comments to the list stating your objections. The working group > can pick over the document after adoption. > > Also, the Chairs have announced that the document will be split into > multiple pieces. The details around this split will be sent out shortly i= n > a separate email. > > Since this bis project is the group=E2=80=99s currently chartered phase o= f work, > the chairs believe one week is sufficient time for objections. This call > for adoption ends: November 2nd, 2020, at 5pm PST. > > Thanks, > > tim > (for Alexey/Seth) > --000000000000b6033705b3741ca1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All
The ca= ll for adoption ended earlier in the week, with the document being adopted,= and split.=C2=A0 =C2=A0Since the existing document was going to be split, = we will wait until the editors produce=C2=A0 their documents and those will= be adopted.=C2=A0

Thanks
tim
<= br>

On Mon, Oct 26, 2020 at 5:58 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:

All

While the chairs a= re aware that working on DMARC-bis is the charter of the working group, we = want to ensure the process is followed. =C2=A0

This starts a Call f= or Adoption for: DMARC-bis

We'll be starting with the text from = the RFC 7489.
This is available here: https://datat= racker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/

Changes made= so far have been to include the current Errata.=C2=A0

Please review= this draft, and we are looking for *objections to adoption*, and send comm= ents to the list stating your objections.=C2=A0 The working group can pick = over the document after adoption.

Also, the Chairs have announced t= hat the document will be split into multiple pieces. The details around thi= s split will be sent out shortly in a separate email.

Since this bis= project is the group=E2=80=99s currently chartered phase of work, the chai= rs believe one week is sufficient time for objections. This call for adopti= on ends: November 2nd, 2020, at 5pm PST.

Thanks,

tim
(for Alexey/Seth)
--000000000000b6033705b3741ca1-- From nobody Sat Nov 7 01:11:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57B3A0CF8 for ; Sat, 7 Nov 2020 01:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=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 K3C2zyF6Lk91 for ; Sat, 7 Nov 2020 01:11:21 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6463A0CF2 for ; Sat, 7 Nov 2020 01:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1604740276; bh=JpwYQd1bFeIyPcZs/c057bs03CbAybxIzdRQwqJ8DwE=; l=1655; h=To:References:From:Date:In-Reply-To; b=BCUiDpCjikH0Grnhc6WDGgrT5OgMwj/HjJG9TD1ITKZChkSsfczml3gjNrrDs7D4g t8RAqxKlPpxCahEu8Xae79fyXeaTJirX/OVsd+EBSv/XZhQx+tt/aZUN+uHOdgGpjM tWbeYSEpX8G4vyauUi98FO9+a233izr976YNF+hdLkIP7aDJP2p7x09PJoDjE Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C3.000000005FA664B4.0000508F; Sat, 07 Nov 2020 10:11:16 +0100 To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> From: Alessandro Vesely Message-ID: <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> Date: Sat, 7 Nov 2020 10:11:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 09:11:23 -0000 On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: > On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: > >> It makes no sense to allow "p=" missing. Why would we suggest that all >> existing implementations alter their code to tolerate additional >> unnecessary complexity, rather than requiring domain administrators to key >> a few more characters so that code changes will not be necessary? Are there really implementations that choke on missing p=? How about "v=DMARC1; p=none; p=quarantine;"? >> I also don't understand this comment from Alessandro : >> >>> "Operators who don't need policy, for example external report receivers >>> who just want to publish verification records, would find the relevant >>> info in the base spec." >> >> There is only one policy record, published by the domain owner. The DNS >> record either suggests enforcement (p=quarantine, p=reject) or it does not >> (p=none, p=missing, no DMARC record). >> >> > I can't speak for him, but I believe he's referring to the records that a > report consumer outside the authority of the domain at issue might publish, > as documented currently in https://tools.ietf.org/html/rfc7489#section-7.1. > In those cases where, for example, foo.com publishes a DMARC policy record > with a rua= value of say "reports@bar.org", there must exist a TXT record > of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that > bar.org is consenting to receive these reports. Exactly! Dropping the requirement allows the definition of DMARC record to be unique. Not a terrific gain, just a little simplification. Best Ale -- From nobody Sat Nov 7 01:53:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD84E3A0D58 for ; Sat, 7 Nov 2020 01:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=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=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAVP2yRyv6d4 for ; Sat, 7 Nov 2020 01:53:23 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7E93A0D51 for ; Sat, 7 Nov 2020 01:53:23 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A79qii9037471 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 7 Nov 2020 09:53:20 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A79qii9037471 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604742801; bh=MfK3fTQR/BbwddNAWYV7i8K24ymndC7fXQbpofF+aRo=; h=Subject:To:References:From:Date:In-Reply-To; b=2Sr1ifCLJbp7sDKr2+qr+efbfXrJHTIEQM+IcYC7E9+u6NB+Q1roxcfytaQ3kplJT DrVhcWQipCIQ/Q6VTbT+1c2xzbHfblsXzcvqigj53oDs+HvGaVB1BA6EFcZZQ8N2rR 2QWq4RhWUqsp+IYEzWSoj2a0sraFMgdBn5MG5yCOqAN9rd3MJM+ESoG/XazBbt+3K+ 29w/FgDbgdAl45wMgaXGjX7i2pZG/okaJNq/HAg+DuS/guhsOK/3TjstRd/2FUDWYj y4R4sjkaY3/McTQt+eAJhj2T9w2StTih84uzzhfJCEphRh1td7lHva9iQBHijRzCcC o2n+rUElJPP1g== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> From: Steven M Jones Message-ID: Date: Sat, 7 Nov 2020 01:52:44 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 07 Nov 2020 09:53:20 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 09:53:25 -0000 On 11/7/20 1:11 AM, Alessandro Vesely wrote: > On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: >> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: >> >>> It makes no sense to allow "p=" missing.   Why would we suggest that >>> all >>> existing implementations alter their code to tolerate additional >>> unnecessary complexity, rather than requiring domain administrators >>> to key >>> a few more characters so that code changes will not be necessary? > > > Are there really implementations that choke on missing p=? > > How about "v=DMARC1; p=none; p=quarantine;"? I'm pretty sure both cases would be invalid as DMARC policy records, in which case they should be ignored. If an implementation is trying to do something with invalid records like these, particularly one with multiple "p=" tags, then that would be a problem. > > >>> I also don't understand this comment from Alessandro : >>> >>>> "Operators who don't need policy, for example external report >>>> receivers who just want to publish verification records, would find >>>> the relevant >>>> info in the base spec." >> >>> There is only one policy record, published by the domain owner.  The >>> DNS >>> record either suggests enforcement (p=quarantine, p=reject) or it >>> does not >>> (p=none, p=missing, no DMARC record). >>> >>> >> I can't speak for him, but I believe he's referring to the records >> that a >> report consumer outside the authority of the domain at issue might >> publish, >> as documented currently in >> https://tools.ietf.org/html/rfc7489#section-7.1. >> In those cases where, for example, foo.com publishes a DMARC policy >> record >> with a rua= value of say "reports@bar.org", there must exist a TXT >> record >> of "v=DMARC1" at foo.com._report._dmarc.bar.org in order to confirm that >> bar.org is consenting to receive these reports. > > > Exactly!  Dropping the requirement allows the definition of DMARC > record to be unique.  Not a terrific gain, just a little simplification. I'm not aware of any requirement for third party report receivers to publish a DMARC policy record for their domain, in order to operate as report receivers. If that's what you meant, Ale, can you tell us where it appears in RFC7489 or the -bis spec? --S. From nobody Sat Nov 7 05:09:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66D3A00D8 for ; Sat, 7 Nov 2020 05:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, SPOOF_COM2OTH=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=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdK6jJ0jOHlq for ; Sat, 7 Nov 2020 05:09:37 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8229D3A005C for ; Sat, 7 Nov 2020 05:09:37 -0800 (PST) X-ASG-Debug-ID: 1604754574-11fa314802266e0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id KGBqTex2Ka7fRVPC (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 07 Nov 2020 08:09:34 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=32ggLEhH4VvwSJcjzNGnO22QAVSMR35tOK1RWGc8R38=; b=P/T9+pP+MGUed+oyuKt+PYjgs6DWdu2yZM/xt0/gDhCUZ/4PXVCfSRcawGrWQSBgF M9RSL/Hb5mWmimiUhM05se+SUHFk6oWlfJC4uTJi/iXQhDxzSVIJiqNFmySSSGBeZ C0tRJkjBS9b23mpK/b+3Pu2/QX0A8rqEh3Q8ia33k= From: "Douglas E. Foster" To: Date: Sat, 7 Nov 2020 08:09:27 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Optional p= makes no sense Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=7869221f857c4676be27a97f92478433 In-Reply-To: References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> X-Exim-Id: b87f2ce51c494212905caaa003331450 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1604754574 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10432 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.85 X-Barracuda-Spam-Status: No, SCORE=0.85 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, SPOOF_COM2OTH, SPOOF_COM2OTH_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85708 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 SPOOF_COM2OTH URI: URI contains ".com" in middle 0.00 HTML_MESSAGE BODY: HTML included in message 0.85 SPOOF_COM2OTH_2 URI contains ".com" in middle Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 13:09:39 -0000 This is a multipart message in MIME format. --7869221f857c4676be27a97f92478433 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The report receiver verification step was referenced in the response. Thi= s was the pointer: https://tools.ietf.org/html/rfc7489#section-7.1. It requires a DNS entry at: . =5Freport.=5Fdmarc.,= type TXT, value "v=3DDMARC1" (No other content is specified.) Since the DNS location, the purpose of the entry, and the content are all d= ifferent, I do not see that it has any bearing on the question of whether "= p=3D" is required or not. p=3Dnone probably means "I am trying to get my administrative controls in p= lace, but I am not there yet", which still supports my earlier comment that= "I don't know how to advise you on whether to accept or reject this messag= e". If p=3Dmissing means, "I am trying to get my administrative controls in pla= ce, but I am so chaotic that I cannot construct a compliant DMARC record", = then I don't know why I should take the policy seriously. If p=3Dmissing means "I am not trying to get any administrative controls in= place, but I like to know whether my bot network is successful", then it i= s still not a DMARC record that I want to take seriously. Overall, it is a small requirement to insist that the domain owner publish = a compliant DMARC policy. In addition, I propose making rua reporting mandatory. A domain owner tha= t does not want to learn about, and correct, his configuration errors canno= t be a reliable source of policy information. False positives will persis= t indefinitely, and therefore the policy record itself cannot be trusted. = Domain owners with persistent errors made SPF pretty much useless until DMA= RC came along. I don't want to see it repeated. Doug Foster ---------------------------------------- From: Steven M Jones Sent: 11/7/20 4:54 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Optional p=3D makes no sense On 11/7/20 1:11 AM, Alessandro Vesely wrote: > On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: >> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: >> >>> It makes no sense to allow "p=3D" missing. Why would we suggest that >>> all >>> existing implementations alter their code to tolerate additional >>> unnecessary complexity, rather than requiring domain administrators >>> to key >>> a few more characters so that code changes will not be necessary=3F > > > Are there really implementations that choke on missing p=3D=3F > > How about "v=3DDMARC1; p=3Dnone; p=3Dquarantine;"=3F I'm pretty sure both cases would be invalid as DMARC policy records, in which case they should be ignored. If an implementation is trying to do something with invalid records like these, particularly one with multiple "p=3D" tags, then that would be a problem. > > >>> I also don't understand this comment from Alessandro : >>> >>>> "Operators who don't need policy, for example external report >>>> receivers who just want to publish verification records, would find >>>> the relevant >>>> info in the base spec." >> >>> There is only one policy record, published by the domain owner. The >>> DNS >>> record either suggests enforcement (p=3Dquarantine, p=3Dreject) or it >>> does not >>> (p=3Dnone, p=3Dmissing, no DMARC record). >>> >>> >> I can't speak for him, but I believe he's referring to the records >> that a >> report consumer outside the authority of the domain at issue might >> publish, >> as documented currently in >> https://tools.ietf.org/html/rfc7489#section-7.1. >> In those cases where, for example, foo.com publishes a DMARC policy >> record >> with a rua=3D value of say "reports@bar.org", there must exist a TXT >> record >> of "v=3DDMARC1" at foo.com.=5Freport.=5Fdmarc.bar.org in order to confir= m that >> bar.org is consenting to receive these reports. > > > Exactly! Dropping the requirement allows the definition of DMARC > record to be unique. Not a terrific gain, just a little simplification. I'm not aware of any requirement for third party report receivers to publish a DMARC policy record for their domain, in order to operate as report receivers. If that's what you meant, Ale, can you tell us where it appears in RFC7489 or the -bis spec=3F --S. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --7869221f857c4676be27a97f92478433 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The report receive= r verification step was referenced in the response.   This was the poi= nter:


It requires a DNS entry at: <sourcedoman>. = =5Freport.=5Fdmarc.<domainname>, type TXT, value "v=3DDMARC1"  (= No other content is specified.)

Since the DNS loca= tion, the purpose of the entry, and the content are all different, I do not= see that it has any bearing on the question of whether "p=3D" is required = or not.

p=3Dnone probably means "I am trying to ge= t my administrative controls in place, but I am not there yet", which still= supports my earlier comment that "I don't know how to advise you on whethe= r to accept or reject this message".

If p=3Dmissin= g means, "I am trying to get my administrative controls in place, but I am = so chaotic that I cannot construct a compliant DMARC record", then I don't = know why I should take the policy seriously.

If p= =3Dmissing means "I am not trying to get any administrative controls in pla= ce, but I like to know whether my bot network is successful", then it is st= ill not a DMARC record that I want to take seriously.

<= div>Overall, it is a small requirement to insist that the domain owner publ= ish a compliant DMARC policy.

In addition, I propo= se making rua reporting mandatory.   A domain owner that does not want= to learn about, and correct, his configuration errors cannot be a reliable= source of policy information.   False positives will persist indefini= tely, and therefore the policy record itself cannot be trusted.  Domai= n owners with persistent errors made SPF pretty much useless until DMARC ca= me along.   I don't want to see it repeated.

=
Doug Foster

From: Steven M Jones <smj@crash.com>
Se= nt: 11/7/20 4:54 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Optional p=3D makes no sense<= /div>

On 11/7/20 1:11 AM, Alessandro Vesely wrote:
=
> On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote:
>= > On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote:
>= >
>>> It makes no sense to allow "p=3D" missing. &nbs= p; Why would we suggest that
>>> all
>>&= gt; existing implementations alter their code to tolerate additional
<= div>>>> unnecessary complexity, rather than requiring domain admin= istrators
>>> to key
>>> a few more c= haracters so that code changes will not be necessary=3F
>
>
> Are there really implementations that choke on mi= ssing p=3D=3F
>
> How about "v=3DDMARC1; p=3Dnone= ; p=3Dquarantine;"=3F


I'm pretty su= re both cases would be invalid as DMARC policy records, in
which = case they should be ignored. If an implementation is trying to do
something with invalid records like these, particularly one with
multiple "p=3D" tags, then that would be a problem.



>
>
>>>= I also don't understand this comment from Alessandro :
>>&= gt;
>>>> "Operators who don't need policy, for exampl= e external report
>>>> receivers who just want to pub= lish verification records, would find
>>>> the releva= nt
>>>> info in the base spec." >>
&g= t;>> There is only one policy record, published by the domain owner. =  The
>>> DNS
>>> record either s= uggests enforcement (p=3Dquarantine, p=3Dreject) or it
>>&g= t; does not
>>> (p=3Dnone, p=3Dmissing, no DMARC record)= .
>>>
>>>
>> I can't = speak for him, but I believe he's referring to the records
>&g= t; that a
>> report consumer outside the authority of the d= omain at issue might
>> publish,
>> as docu= mented currently in




--S.


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmarc mailing list
dmarc= @ietf.org
Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 18:33:50 -0000 --000000000000d8fd4205b3889130 Content-Type: text/plain; charset="UTF-8" .. > > p=none probably means "I am trying to get my administrative controls in > place, but I am not there yet", which still supports my earlier comment > that "I don't know how to advise you on whether to accept or reject this > message". > p=none simply means "This domain is not asserting policy". Reading anything more than that into it is pure speculation. Michael Hammer --000000000000d8fd4205b3889130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<SNIP>..

p=3Dnone probably means "I am trying to get = my administrative controls in place, but I am not there yet", which st= ill supports my earlier comment that "I don't know how to advise y= ou on whether to accept or reject this message".

p=3Dnone simply means "This domain is not asser= ting policy". Reading anything more than that into it is pure speculat= ion.

Michael Hammer
--000000000000d8fd4205b3889130-- From nobody Sat Nov 7 11:54:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D83A0DFB for ; Sat, 7 Nov 2020 11:54:18 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hioRS1Y2kYZM for ; Sat, 7 Nov 2020 11:54:16 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385323A0DF6 for ; Sat, 7 Nov 2020 11:54:16 -0800 (PST) X-ASG-Debug-ID: 1604778850-11fa31480228a50001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 9LMrS3q4hLSDsDIq (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 07 Nov 2020 14:54:10 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=f3nX9TTlIi4/7B+goq80NLgI1SOK1CAlHrHAmPf+qFE=; b=C9YBHn+2lmlnKwuA6pIO5baaiLRZlveXx8AWsPnfDq9Lkw9OIaMI4yyPCGTvz+r91 n3rbsggjNVNnpx7BegAPJEoP3LP/r9HioBWkdeQLVb0f5kupmsqoHCVi7fVxloVr8 RDRtwP255ap1bklwNgSz3yQ4kYzW0/kmdfdxWMcCw= Received: by webmail.bayviewphysicians.com via HTTP; Sat, 7 Nov 2020 14:54:02 -0500 To: IETF DMARC WG Date: Sat, 07 Nov 2020 14:54:00 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Optional p= makes no sense Message-ID: MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=ff11698e13e64feda1d1a044e6111fc8 SavedFromEmail: fosterd@bayviewphysicians.com Importance: normal From: "Douglas E. Foster" X-Exim-Id: f626d39faced4a8486b8ae253fc672ab X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1604778850 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2757 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 19:54:18 -0000 This is a multipart message in MIME format. --ff11698e13e64feda1d1a044e6111fc8 Content-Type: multipart/alternative; boundary=5b7aed9a11a4487b8e3f7f62fcee6ff2 --5b7aed9a11a4487b8e3f7f62fcee6ff2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Exactly. I was speculating.=A0 What reasons could possibly exist for a doma= in to be given another method for not saying anythng=3F=A0=A0You make my po= int - there are no valid reasons to do so.Sent from my Verizon, Samsung Gal= axy smartphone
-------- Original message --------
=
From: Dotzero
Date: 11/7/20 1:34 PM (= GMT-05:00)
To: IETF DMARC WG
Subject= : Re: [dmarc-ietf] Optional p=3D makes no sense
.. > > p=3Dnone probably means "I am trying to get my administrative controls in > place, but I am not there yet", which still supports my earlier comment > that "I don't know how to advise you on whether to accept or reject this > message". > p=3Dnone simply means "This domain is not asserting policy". Reading anythi= ng more than that into it is pure speculation. Michael Hammer =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --5b7aed9a11a4487b8e3f7f62fcee6ff2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Exactly. I was specul= ating.  What reasons could possibly exist for a domain to be given ano= ther method for not saying anythng=3F  
You make my point - there are no valid reasons to= do so.

Sent fr= om my Verizon, Samsung Galaxy smartphone

<= /div>


-------- Or= iginal message --------
From: Dotzero <dotzero@gmail.com> <= /div>
Date: 11/7/20 1:34 PM (GMT-05:00)
To: IETF DMARC WG = <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Optional p=3D m= akes no sense

<SNIP>..

p=3Dnone p= robably means "I am trying to get my administrative controls in place,= but I am not there yet", which still supports my earlier comment that= "I don't know how to advise you on whether to accept or reject th= is message".

p=3Dnone simp= ly means "This domain is not asserting policy". Reading anything = more than that into it is pure speculation.

Michae= l Hammer
--5b7aed9a11a4487b8e3f7f62fcee6ff2-- --ff11698e13e64feda1d1a044e6111fc8-- From nobody Sat Nov 7 12:16:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAAF3A0E1E for ; Sat, 7 Nov 2020 12:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv74cCe4bbE3 for ; Sat, 7 Nov 2020 12:16:56 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFC23A0E13 for ; Sat, 7 Nov 2020 12:16:56 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A7KGlJN010452 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 7 Nov 2020 20:16:55 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A7KGlJN010452 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604780216; bh=4tzA2duZMjuGCjoqjRCZoxYo9gcZMLcmcVwqTg2I43g=; h=Subject:To:References:From:Date:In-Reply-To; b=g6s/GPoas3B5uGtrT/MJ0erEU5DIkiszGLjg9ITJBNWpTkW/BOzavHn7loeI3cCab pg6t0RFYAxZHpyX5C9WICSZtsZjcOHt8MjljrAn+aZ0Kzt9FJiSanp4QGlaPoyk8G3 CkW+ifYVNK5iq7J8WNLa8cWEBQQBeWlE49Qm+JS/kPtSI8LioWMjWZrAvaUehwoqdY b03IpEG14SBCa0SFI6gNPk6VIfxQizg0WfYOTUVo9H2DQWUg4CL51G7Ew1AQyQslD4 S+/jvNzr/cD9UGlHnfxY8/RNWA11p+IyvtXCaYKQsMnUgLiWmMYqQHTs42SYKMapZE xE4baq2ix6qjg== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> From: Steven M Jones Message-ID: <3160f014-b348-b9e9-f375-112a44bb21db@crash.com> Date: Sat, 7 Nov 2020 12:16:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------38E2E9E77CE0BD91D1EDB8A5" Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 07 Nov 2020 20:16:56 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 20:16:58 -0000 This is a multi-part message in MIME format. --------------38E2E9E77CE0BD91D1EDB8A5 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/7/20 5:09 AM, Douglas E. Foster wrote: > The report receiver verification step was referenced in the response. > This was the pointer: > > https://tools.ietf.org/html/rfc7489#section-7.1. > > It requires a DNS entry at: . > _report._dmarc., type TXT, value "v=DMARC1" (No other > content is specified.) Thank you Doug, I'm familiar with section 7.1. I think the question of whether the "p=" tag is optional has been adequately addressed. I'll respond to the other topic in this thread separately, with a subject line that reflects the topic. --S. --------------38E2E9E77CE0BD91D1EDB8A5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/7/20 5:09 AM, Douglas E. Foster wrote:
The report receiver verification step was referenced in the response. This was the pointer:

It requires a DNS entry at: <sourcedoman>. _report._dmarc.<domainname>, type TXT, value "v=DMARC1" (No other content is specified.)


Thank you Doug, I'm familiar with section 7.1.

I think the question of whether the "p=" tag is optional has been adequately addressed.


I'll respond to the other topic in this thread separately, with a subject line that reflects the topic.

--S.


--------------38E2E9E77CE0BD91D1EDB8A5-- From nobody Sat Nov 7 12:19:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E8E3A0E1E for ; Sat, 7 Nov 2020 12:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jDXh9xy8h-O for ; Sat, 7 Nov 2020 12:19:54 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BAF3A0E13 for ; Sat, 7 Nov 2020 12:19:54 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A7KJjHp039870 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 7 Nov 2020 20:19:54 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A7KJjHp039870 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604780394; bh=1CEwnwKUZchJZQoZ2CWCYywbb95abKtO9RxOfRWtYPA=; h=Subject:To:References:From:Date:In-Reply-To; b=HNBApbrBfRwMXcUXX/UCDTCA88RSHqFZDcEimvsJhMWtkPkplKWi8znenJbdqo9UH HHwWP0cUnBkXeJ8eUxjzzm2Y4jrt8MBq7Xj3+cBrKA4ZzSxgi4k2a/YlIvsp/L3Fwm tNewPDa/KtMMNHJutzG/y2jG1KhOt+SH+ZnZlFH4q+xF07k+9F3OhIVnblvdvW4gmK yRg1HF60Pz0T1Mplxzbl9OAg15hRcKgA3MXSdBjghkUb8J9MsttKhIKxwpduw4+FsG vHnoZLC5iVMgQ1SfFB/ZQwgXrjWJejHV6b5vvAgRMRTxsD5oLxzwpZXcDiv8qmPKsw SkWnZRF+gj3HA== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> From: Steven M Jones Message-ID: <288f82f1-698f-e591-6296-af65e25551cc@crash.com> Date: Sat, 7 Nov 2020 12:19:45 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sat, 07 Nov 2020 20:19:54 +0000 (UTC) Archived-At: Subject: [dmarc-ietf] Separate policy spec, was Re: Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Nov 2020 20:19:56 -0000 I wanted to bring this topic into a visibly different thread, as it's really about further splitting up of the base DMARC document. In digging through recent messages, I think I see what Ale meant. The topic was Jim Fenton's suggestion of splitting the policy section out into a separate document. This would be the relevant reference from Ale's message on Nov 5th, subject "Announcing DMARCbis Editors" - Ale is responding to Todd Herr in this snippet: >> Moving discussion of policy to a second specification would render >> any base >> specification to be no more than effectively a table of contents >> pointing >> to other documents, which seems to me to be a pointless document to >> produce. > > > Operators who don't need policy, for example external report receivers > who just want to publish verification records, would find the relevant > info in the base spec. > > A good point of Jim's proposal is that having policy in a separate > spec, in the same manner as reports, avoids the unintended effect of > classifying reports as a 2nd class, generally-not-used feature. Alessandro: Correct me if I'm wrong, but it seems from this quotation that you were just constructing a case were a valid DMARC role (third party report receiver) would need to use the "base" spec (without policy content), and the reporting specs, without direct need for a separate/split-out "policy" spec. While you have a point, I would think that any report receiver would need to reference that policy spec as soon as they receive a report and need to interpret it. In which case, I would need a more compelling reason or benefit to split the policy section out into a separate document. With regard to the "Optional p= makes no sense" thread, I think the quotation with too-little context gave the impression of a different or larger issue. --Steve. From nobody Sat Nov 7 16:50:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0936D3A0E27; Sat, 7 Nov 2020 16:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 GSogfqhAGMxl; Sat, 7 Nov 2020 16:50:35 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 0CA193A0E25; Sat, 7 Nov 2020 16:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nU9XN91bIZ9zeBTOxaaHr525gj+J61xk6c72QPw3fGk=; b=jEdRm/aB9/ZzW4g2Z7dmExWJFT EdYmByIGE00boDQefi906x2TvheiVtaw1EpTspfaBzr4M/DasFQAUkQhcOnZGhX0R5qeR5x0LQqNv vbi7ZPYVaBxDb2zPejniHviZKN4ZM2Ssxq+mF9m5PzCZv+ipTqve2oa2r6mli8SyB6uA=; Received: from [2601:647:4400:1261:f1cc:a084:931b:26ca] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kbYuf-00042A-LU; Sat, 07 Nov 2020 16:50:34 -0800 From: "Jim Fenton" To: "Seth Blank" Cc: "IETF DMARC WG" Date: Sat, 07 Nov 2020 16:50:32 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> In-Reply-To: References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 00:50:38 -0000 On 5 Nov 2020, at 9:45, Seth Blank wrote: > On Thu, Nov 5, 2020 at 9:31 AM Alessandro Vesely > wrote: > >> That's the old spec. The consensus of the working group is to remove >> the >> normative constraint about p= (ticket #49). So now only v= is >> required. >> > > As Chair, this is not the consensus of the group, nor what ticket #49 > ( > https://trac.ietf.org/trac/dmarc/ticket/49) says. What we removed was > the > normative requirement that p= MUST be the second tag in the record. p= > is > still REQUIRED. > > To Todd's point, DMARC is a means of communicating policy between > domain > owner and mail receiver regarding how to handle unauthenticated mail. > DMARC > does not function without policy. If that last sentence is the consensus of the working group (and I see that the charter could be interpreted that policy is required), then fine. But I consider the reporting aspect to be useful even in the absence of policy assertion or enforcement, allow a domain owner to obtain information about recipients’ receipt of unauthenticated email from that domain. I realize that RFC 7489 treats policy as the primary function and reporting as secondary, but this WG is about improving that specification, and I consider this to be an improvement. > If someone believes policy can be spun out into a separate draft, > please > upload your suggestion as an I-D and we will discuss it. That’s quite a bit of work for something that might very well be dead on arrival. I have outlined the portions of the specification that would go in the base specification and the portions that go into the policy document, and that should be sufficient to make this decision. To Todd’s earlier comment, the base specification would be much more than a “table of contents” because that is where the format of DMARC records, the discovery mechanisms, and the like would be specified. However, the base specification would not stand alone; it would require the policy specification or one or both of the reporting specifications to do anything useful. -Jim From nobody Sat Nov 7 17:01:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016B53A0E2F for ; Sat, 7 Nov 2020 17:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Q7MWWcEeuO for ; Sat, 7 Nov 2020 17:00:57 -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 0CEF03A0E2D for ; Sat, 7 Nov 2020 17:00:54 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0A814IDY003823 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 7 Nov 2020 17:04:20 -0800 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <4e81d748-c5aa-1674-91d2-4f3fc54e6ccc@dcrocker.net> Date: Sat, 7 Nov 2020 17:00:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 In-Reply-To: <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 01:00:58 -0000 On 11/7/2020 4:50 PM, Jim Fenton wrote: > If that last sentence is the consensus of the working group (and I see > that the charter could be interpreted that policy is required), then > fine. But I consider the reporting aspect to be useful even in the > absence of policy assertion or enforcement, allow a domain owner to > obtain information about recipients’ receipt of unauthenticated email > from that domain. I realize that RFC 7489 treats policy as the primary > function and reporting as secondary, but this WG is about improving that > specification, and I consider this to be an improvement. DMARC can do 3 things: 1. Define alignment and how to effect it 2. Request receive-side disposition of non-aligned mail 3. Request reporting. DMARC does not have to do 2 or 3. It can refrain from making a handling request and it can refrain from requesting reporting. A claim that DMARC isn't DMARC unless there is policy seems an odd view, given p=none. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Nov 7 20:12:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822323A0FDA for ; Sat, 7 Nov 2020 20:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZZnRIDZfx1t for ; Sat, 7 Nov 2020 20:12:48 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BF03A0FD9 for ; Sat, 7 Nov 2020 20:12:48 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A84CaR1013670 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 8 Nov 2020 04:12:45 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A84CaR1013670 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604808767; bh=uyDaeIcEqaJu/FlHOxLye7paYkBZdmcI+jU+Qb/f7NI=; h=Subject:To:References:From:Date:In-Reply-To; b=oZJdYMIbIb7mpCXPp+w7efGc3ZjiXAHIdPpMhkOluzAeY+9d8JyH7CVnt+T+Tx0EM yCpoYw9s9zfVvddKmNlyMGW38kQuyQgsfJhdxdogqUp0zA+4kdxRqomZ04HS+anRSu 4ZPYiHhCv3K/PSu9eHf+Oj/uPlmNNLTNAZbuqa8PebIGpj9hy3lGP5Lz12jsYPck1n AV3KlLTXvVBC5iw3kXkoJq5d0GRIh+vHCiZowylwEe4iaG3CeUX68r8hUyGu031e/S y0fOyCNx3KB4pwgO12IsRIT0K6SjSuJZ0yjJnhbKvQsUWtFh21D0uUTJBjYp7NhHFJ w7JRw7EN7Doiw== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> From: Steven M Jones Message-ID: <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> Date: Sat, 7 Nov 2020 20:12:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sun, 08 Nov 2020 04:12:45 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 04:12:50 -0000 On 11/7/20 4:50 PM, Jim Fenton wrote: > On 5 Nov 2020, at 9:45, Seth Blank wrote: >> [...] >> >> To Todd's point, DMARC is a means of communicating policy between domain >> owner and mail receiver regarding how to handle unauthenticated mail. >> DMARC >> does not function without policy. > > [...] But I consider the reporting aspect to be useful even in the > absence of policy assertion or enforcement, allow a domain owner to > obtain information about recipients’ receipt of unauthenticated email > from that domain. I realize that RFC 7489 treats policy as the primary > function and reporting as secondary, but this WG is about improving > that specification, and I consider this to be an improvement. I agree there is a great deal of value in reporting without "enforcement" -- that's why the policy option of "p=none" exists. Perhaps the use of the string "none," meaning "no change in handling," is too readily confused with "none" meaning "no policy?" Which is indeed an odd duck, a policy saying there is no policy... Is there a problem with using the "p=" tag to signal the desire for reports without requesting a change in the processing of messages that don't get a DMARC "pass?" > [ Quoting Seth again: ] >> If someone believes policy can be spun out into a separate draft, please >> upload your suggestion as an I-D and we will discuss it. > > That’s quite a bit of work for something that might very well be dead > on arrival. I have outlined the portions of the specification that > would go in the base specification and the portions that go into the > policy document, and that should be sufficient to make this decision. Okay, but what is the expected payoff from splitting it out? Does it make it easier to process and approve updates of the policy content separately from, say, the description of record discovery or Alignment concepts? Easier to pass muster for Standards Track? Are implementers currently confused and dissuaded by having policy details mixed with the other content? If the benefits seem worthwhile, I could get behind the split - but there ought to be a clear benefit. --S. From nobody Sat Nov 7 20:20:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF073A0FE4 for ; Sat, 7 Nov 2020 20:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjFS3_Rf5ygP for ; Sat, 7 Nov 2020 20:20:16 -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 A75133A0FDF for ; Sat, 7 Nov 2020 20:20:16 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0A84NhOf024749 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 7 Nov 2020 20:23:44 -0800 Reply-To: dcrocker@bbiw.net To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sat, 7 Nov 2020 20:20:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 In-Reply-To: <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 04:20:18 -0000 On 11/7/2020 8:12 PM, Steven M Jones wrote: > that's why the policy option of "p=none" exists. Perhaps the use of the > string "none," meaning "no change in handling," is too readily confused > with "none" meaning "no policy?" Which is indeed an odd duck, a policy > saying there is no policy... Although the DMARC spec defines p=none as: > none: The Domain Owner requests no specific action be taken > regarding delivery of messages. This is rather tortured language that invites confusion. Forgive me, but "requests no specific action" is a request that isn't a request. It has no real meaning. What is actually intended is: "The Domain Owner is expressing no policy for action to be taken regarding delivery of the message." d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Nov 7 20:27:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6983A0FF5 for ; Sat, 7 Nov 2020 20:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0iMIm5b_ke3 for ; Sat, 7 Nov 2020 20:27:14 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579EF3A0FF4 for ; Sat, 7 Nov 2020 20:27:14 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A84R5Hc077924 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 8 Nov 2020 04:27:14 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A84R5Hc077924 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604809634; bh=k4/H9WsbIER7kAKsEZ7lnfT+8DUBWNc5ORRmPNYx4aE=; h=Subject:To:References:From:Date:In-Reply-To; b=S3K0g+XZ5qFLBL7D8RufxUqpDHrrP0DY/cs6cd0g3WJsQfZqMbbBjoAEUk6F/xNri FGUuq4jCeZN1/tQ43DzfuDIb2qxIqvMdIIyxE7IJZD6tEB7u4RQYGKqi+UMWTDK6Yg T3+qswZq5QlpXi5yhr/vamiOO5/T3shoDYRp0p0Oo17teWfnBZeWbOHZd1L0gWsqcS bXldFLuyEEVBcoRV/+kdc9J7qvyIp5xYiUBotUedqWqMncGT5Y8bcQUXMZVR59oEGg 1p+CtWU/2POUS6k/IPcf/D6g7wroj9L8TsuNY89ct0gdDMylZZP0I/XD+J8dTHnxPy fcCA5C+v6Pt5Q== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> <4e81d748-c5aa-1674-91d2-4f3fc54e6ccc@dcrocker.net> From: Steven M Jones Message-ID: Date: Sat, 7 Nov 2020 20:27:05 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <4e81d748-c5aa-1674-91d2-4f3fc54e6ccc@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sun, 08 Nov 2020 04:27:14 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 04:27:15 -0000 On 11/7/20 5:00 PM, Dave Crocker wrote: > On 11/7/2020 4:50 PM, Jim Fenton wrote: >> If that last sentence is the consensus of the working group (and I >> see that the charter could be interpreted that policy is required), >> then fine. But I consider the reporting aspect to be useful even in >> the absence of policy assertion or enforcement, allow a domain owner >> to obtain information about recipients’ receipt of unauthenticated >> email from that domain. > > > DMARC can do 3 things: > >    1. Define alignment and how to effect it > >    2. Request receive-side disposition of non-aligned mail > >    3. Request reporting. > > DMARC does not have to do 2 or 3.  It can refrain from making a > handling request and it can refrain from requesting reporting. > > A claim that DMARC isn't DMARC unless there is policy seems an odd > view, given p=none. "p=none" is the defined _policy_ to get 1 and 3 without 2. That's how you set a _policy_ that allows you to request reporting without enforcement. "p=none" allows Jim's desired use case to have reporting without a change in handling. Since it _is_ a policy, what Seth wrote ("DMARC does not function without policy.") is not in conflict with that use case. Maybe changing that option to "none" from "monitoring" wasn't actually the best choice? But I'm not sure it would be wise to change it now, in light of the installed base... --S. From nobody Sat Nov 7 20:32:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216D3A1006 for ; Sat, 7 Nov 2020 20:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3_Li9P387Ck for ; Sat, 7 Nov 2020 20:32:53 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2153A02C1 for ; Sat, 7 Nov 2020 20:32:53 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A84Wi7f052153 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 8 Nov 2020 04:32:52 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A84Wi7f052153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604809973; bh=2TSxpjl/HY2rT1snPUlE5uEXAMmgvDPS9So2O/jEJBA=; h=Subject:To:References:From:Date:In-Reply-To; b=XtoItaxY8yNGRG0s5KeuCGvx4CWzV3L+zzPujIen/METQg0arLucW2/PKUGT9xoVV LOtO8uPsrhgZChDFyazpd5RKiUzynDkC4gjeTBBisiUuASX/xEX9vw8pXqXdzIh8FG Vdfjb4Fs6KOOxApPZvs136CGbVEwdxzAn9/nd7jS2IPyE32MPD2wJcQI96Fi3vy6Mc K92iNkaEqaKUtrASclzzeddJfMiV90GkwaDp5KggRKH7e8Y6JjqmDK0WYrmYXwIpRr rBDwYHcAJX7R702Tdw5adKli18j5DVz6I6ozvDDMrzgNnenpo51j6DMpvReVqvsu5v tFFiuntE8p+ag== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> From: Steven M Jones Message-ID: Date: Sat, 7 Nov 2020 20:32:44 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Sun, 08 Nov 2020 04:32:52 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 04:32:54 -0000 On 11/7/20 8:20 PM, Dave Crocker wrote: > On 11/7/2020 8:12 PM, Steven M Jones wrote: >> that's why the policy option of "p=none" exists. Perhaps the use of >> the string "none," meaning "no change in handling," is too readily >> confused with "none" meaning "no policy?" Which is indeed an odd >> duck, a policy saying there is no policy... > > > Although the DMARC spec defines p=none as: > >>       none:  The Domain Owner requests no specific action be taken >>          regarding delivery of messages. > > This is rather tortured language that invites confusion.  Forgive me, > but "requests no specific action" is a request that isn't a request.  > It has no real meaning. > > What is actually intended is: > >       "The Domain Owner is expressing no policy for action to be taken >        regarding delivery of the message." > > d/ Fair point, the language could be improved - and by a lovely coincidence, I understand there's a group tasked with revising the spec. ;^) Though I'm not convinced that it seems confusing when you read it in the context of the "quarantine" and "reject" options right below it... --S. From nobody Sun Nov 8 03:00:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E063A07E6 for ; Sun, 8 Nov 2020 03:00:14 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM4hPMalK0bF for ; Sun, 8 Nov 2020 03:00:10 -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 9D4F93A07EA for ; Sun, 8 Nov 2020 03:00:09 -0800 (PST) Received: (qmail 77392 invoked by uid 100); 8 Nov 2020 11:00:06 -0000 Date: 8 Nov 2020 10:59:42 -0000 Message-ID: <20201108105942.77384.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 8 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 11:00:15 -0000 Count | Bytes | Who ------------+----------------+------- 6 (21.4%) | 37334 (19.0%) | Steven M Jones 4 (14.3%) | 20033 (10.2%) | Alessandro Vesely 3 (10.7%) | 31826 (16.2%) | Douglas E. Foster 3 (10.7%) | 12418 ( 6.3%) | Dave Crocker 2 ( 7.1%) | 24593 (12.5%) | Todd Herr 2 ( 7.1%) | 20065 (10.2%) | Jim Fenton 2 ( 7.1%) | 13227 ( 6.7%) | Alexey Melnikov 2 ( 7.1%) | 7310 ( 3.7%) | John Levine 1 ( 3.6%) | 9730 ( 4.9%) | Seth Blank 1 ( 3.6%) | 8573 ( 4.4%) | Tim Wicinski 1 ( 3.6%) | 6156 ( 3.1%) | Dotzero 1 ( 3.6%) | 5744 ( 2.9%) | Kurt Andersen (b) From nobody Sun Nov 8 12:18:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF03A0D4C for ; Sun, 8 Nov 2020 12:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q0GzuMdsvzH for ; Sun, 8 Nov 2020 12:17:54 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664C23A0D45 for ; Sun, 8 Nov 2020 12:17:50 -0800 (PST) X-ASG-Debug-ID: 1604866668-11fa3148022d5f0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id dMlnr02qXbMFZEPQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 08 Nov 2020 15:17:48 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:to:subject; bh=+sX3E3XDwZxhRhPAe3pt+h6qIPbM/o8hzGATpXNIxZE=; b=kOJn3qkwO5IftBXINB5rWyQTN4Vf/5xc1t1KeQeTX4E1h3+H7cSWYc4ptGgHx/E+S zhs3PjdCkYJu5bK8h+lARF/DTFijK3TxXwsXTsvr6M8pb5Hx1bSKRzN8tXdQKP8a9 wztj8A/qJqRE6CBgsp0RAZONiPbx5dKo0ZYUeD3VM= SavedFromEmail: fosterd@bayviewphysicians.com Date: Sun, 08 Nov 2020 15:17:37 -0500 Importance: normal X-ASG-Orig-Subj: [dmarc-ietf] Separate document for policy? To: IETF DMARC WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1185841101661420" From: "Douglas E. Foster" X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1604866668 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2673 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.14 X-Barracuda-Spam-Status: No, SCORE=0.14 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, MISSING_MID X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85738 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 MISSING_MID Missing Message-Id: header 0.00 HTML_MESSAGE BODY: HTML included in message Message-Id: <20201108201750.664C23A0D45@ietfa.amsl.com> Archived-At: Subject: [dmarc-ietf] Separate document for policy? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 20:18:01 -0000 ----_com.samsung.android.email_1185841101661420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 ClJlZ2FyZGluZyBEYXYncyBjb21tZW50OkEgY2xhaW0gdGhhdCBETUFSQyBpc24ndCBETUFSQyB1 bmxlc3MgdGhlcmUgaXMgcG9saWN5IHNlZW1zIGFuIG9kZCB2aWV3LGdpdmVuIHA9bm9uZS5JIGlt cHV0ZSBzb21lIHNvY2lhbCBub3JtcyB0byB0aGUgRE1BUkMgcHJvY2VzczogwqAgVGhlIGRvbWFp biBvd25lciBzYXlzIHRvIHRoZSByZWNlaXZlciwgIkkgd2FudCB0byBoZWxwIHlvdSBibG9jayB0 aHJlYXRzIGZyb20gc3Bvb2ZlZCBtZXNzYWdlcyAoYnkgcHJvdmlkaW5nIHBvbGljeSksIGJ1dCBJ IG5lZWQgeW91ciBoZWxwIChieSBwcm92aWRpbmcgZmVlZGJhY2spIi4gwqAgwqBJbiB0aGlzIGNv bnRleHQsIHA9bm9uZSBpcyBpbXBsaWVkIHRvIG1lYW4sICJJIHdhbnQgdG8gaGVscCB5b3UsIGJ1 dCBJIG5lZWQgeW91IHRvIGhlbHAgbWUgZmlyc3QsIHdoaWxlIEkgYW0gdHJhbnNpdGlvbmluZyB0 byBmdWxsIGVuZm9yY2VtZW50Ii4gwqBUaGlzIGFzc3VtZXMgdGhhdCB0aGUgZG9tYWluIMKgb3du ZXIgaW50ZW5kcyB0byBwcm9jZWVkIHRvIGVuZm9yY2VtZW50LCB3aGljaCBtYXkgbm90IGJlIHRy dWUuVGhpcyBvZiBjb3Vyc2UgZW5hYmxlcyBhIGZyZWUtcmlkZXIgbW9kZTogwqAiSSBhbSBub3Qg aW50ZXJlc3RlZCBpbiBoZWxwaW5nIHlvdS4gwqBJIHdpbGwgYmUgdXNpbmcgcD1ub25lIGZvcmV2 ZXIsIHNpbXBseSBiZWNhdXNlIEkgd2FudCB5b3UgdG8gaGVscCBtZSBjb2xsZWN0IGRlbGl2ZXJ5 IHN0YXRpc3RpY3MiLiDCoCDCoCBCdXQgZXZlbiB0aG91Z2ggaXQgaXMgcG9zc2libGUsIEkgZG9u J3QgdGhpbmsgaXQgaXMgc29tZXRoaW5nIHRoYXQgSUVURiBzaG91bGQgZXhwbGljaXRseSBlbmNv dXJhZ2UsIMKgwqBJIGRvIG5vdCBzZWUgcG9saWN5IGFzIGEgc3VmZmljaWVudGx5IGNvbXBsZXgg dG9waWMgdG8gd2FycmFudCBhIHNlcGFyYXRlIGRvY3VtZW50LCBlc3BlY2lhbGx5IGlmIHRoZSBz ZXBhcmF0aW9uIGlzIGludGVuZGVkIHRvIGNvbW11bmljYXRlIHRoYXQgZnJlZS1yaWRlciBtb2Rl IGlzIGVuY291cmFnZWQuRG91Zwo= ----_com.samsung.android.email_1185841101661420 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PGJyPjwv ZGl2PjxkaXYgYWxpZ249ImxlZnQiIGRpcj0iYXV0byIgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2Nv bG9yOiMwMDAwMDAiPjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyIgZGlyPSJhdXRvIj48ZGl2 PlJlZ2FyZGluZyBEYXYncyBjb21tZW50OjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OiAyMHB4OyI+QSBjbGFpbSB0aGF0IERNQVJDIGlzbid0IERNQVJDIHVubGVz cyB0aGVyZSBpcyBwb2xpY3kgc2VlbXMgYW4gb2RkIHZpZXcsPC9kaXY+PGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6IDIwcHg7Ij5naXZlbiBwPW5vbmUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5J IGltcHV0ZSBzb21lIHNvY2lhbCBub3JtcyB0byB0aGUgRE1BUkMgcHJvY2VzczogJm5ic3A7IFRo ZSBkb21haW4gb3duZXIgc2F5cyB0byB0aGUgcmVjZWl2ZXIsICJJIHdhbnQgdG8gaGVscCB5b3Ug YmxvY2sgdGhyZWF0cyBmcm9tIHNwb29mZWQgbWVzc2FnZXMgKGJ5IHByb3ZpZGluZyBwb2xpY3kp LCBidXQgSSBuZWVkIHlvdXIgaGVscCAoYnkgcHJvdmlkaW5nIGZlZWRiYWNrKSIuICZuYnNwOyAm bmJzcDtJbiB0aGlzIGNvbnRleHQsIHA9bm9uZSBpcyBpbXBsaWVkIHRvIG1lYW4sICJJIHdhbnQg dG8gaGVscCB5b3UsIGJ1dCBJIG5lZWQgeW91IHRvIGhlbHAgbWUgZmlyc3QsIHdoaWxlIEkgYW0g dHJhbnNpdGlvbmluZyB0byBmdWxsIGVuZm9yY2VtZW50Ii4gJm5ic3A7VGhpcyBhc3N1bWVzIHRo YXQgdGhlIGRvbWFpbiAmbmJzcDtvd25lciBpbnRlbmRzIHRvIHByb2NlZWQgdG8gZW5mb3JjZW1l bnQsIHdoaWNoIG1heSBub3QgYmUgdHJ1ZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoaXMg b2YgY291cnNlIGVuYWJsZXMgYSBmcmVlLXJpZGVyIG1vZGU6ICZuYnNwOyJJIGFtIG5vdCBpbnRl cmVzdGVkIGluIGhlbHBpbmcgeW91LiAmbmJzcDtJIHdpbGwgYmUgdXNpbmcgcD1ub25lIGZvcmV2 ZXIsIHNpbXBseSBiZWNhdXNlIEkgd2FudCB5b3UgdG8gaGVscCBtZSBjb2xsZWN0IGRlbGl2ZXJ5 IHN0YXRpc3RpY3MiLiAmbmJzcDsgJm5ic3A7IEJ1dCBldmVuIHRob3VnaCBpdCBpcyBwb3NzaWJs ZSwgSSBkb24ndCB0aGluayBpdCBpcyBzb21ldGhpbmcgdGhhdCBJRVRGIHNob3VsZCBleHBsaWNp dGx5IGVuY291cmFnZSwgJm5ic3A7Jm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGRv IG5vdCBzZWUgcG9saWN5IGFzIGEgc3VmZmljaWVudGx5IGNvbXBsZXggdG9waWMgdG8gd2FycmFu dCBhIHNlcGFyYXRlIGRvY3VtZW50LCBlc3BlY2lhbGx5IGlmIHRoZSBzZXBhcmF0aW9uIGlzIGlu dGVuZGVkIHRvIGNvbW11bmljYXRlIHRoYXQgZnJlZS1yaWRlciBtb2RlIGlzIGVuY291cmFnZWQu PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Eb3VnPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PC9kaXY+CjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_1185841101661420-- From nobody Mon Nov 9 04:15:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CEE3A0FFD for ; Mon, 9 Nov 2020 04:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30RfQSEFdl70 for ; Mon, 9 Nov 2020 04:15:11 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E164F3A0FFA for ; Mon, 9 Nov 2020 04:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1604924102; bh=zDk7nMAN/n0CFHhCKbWmM83RkgdHps+tPOpPtGvjZU4=; l=2052; h=To:References:From:Date:In-Reply-To; b=B6kj8bVISQnbhbSjABtKVGdqm8oDoJuO7zPsREun0CaEOs8pT6aDg8Y3XDJ5nURam yYWSAMV2IV0wCjIwAIJoAoagdZhYAJNfyrQGdS4G51IZP5irJBOEvMrrYpaD+lLBjh UjI00BOLgggVbrmRc6zRjmRbfwwvITRKTpcnnB/lS1ryVcQzWlFIxyKDX4jLM Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC083.000000005FA932C6.0000420F; Mon, 09 Nov 2020 13:15:02 +0100 To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> From: Alessandro Vesely Message-ID: <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> Date: Mon, 9 Nov 2020 13:15:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 12:15:13 -0000 On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote: > On 11/7/20 1:11 AM, Alessandro Vesely wrote: >> On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: >>> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: >>> >>>> It makes no sense to allow "p=" missing.   Why would we suggest that all >>>> existing implementations alter their code to tolerate additional >>>> unnecessary complexity, rather than requiring domain administrators to key >>>> a few more characters so that code changes will not be necessary? >> >> >> Are there really implementations that choke on missing p=? >> >> How about "v=DMARC1; p=none; p=quarantine;"? > > > I'm pretty sure both cases would be invalid as DMARC policy records, in which > case they should be ignored. I don't think so. The current draft says: 6. If a retrieved policy record does not contain a valid "p" tag, or contains an "sp" tag that is not valid, then: 1. if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=none" was retrieved, and continue processing; > If an implementation is trying to do something with invalid records like > these, particularly one with multiple "p=" tags, then that would be a > problem. Invalid or repeated p= tags are a problem, but possibly they don't completely disqualify a record. So the question becomes "How does a missing p= tag differ from an invalid one?" This is a marginal question, to define the syntax of a DMARC record as simply as possible (but not simpler). I added a comment to ticket #7[*] with a proposed syntax. IMHO the spec should just mention undefined behavior or some such, without trying to impose overly strict commitments —given that parsers have to deal with the possibility of non-conforming records anyway. This question is not related with splitting policy into its own document. Best Ale -- [*] https://trac.ietf.org/trac/dmarc/ticket/7#comment:4 From nobody Mon Nov 9 05:51:53 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFC63A10F9 for ; Mon, 9 Nov 2020 05:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I93bC1Um1-x for ; Mon, 9 Nov 2020 05:51:49 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AC33A10F6 for ; Mon, 9 Nov 2020 05:51:48 -0800 (PST) X-ASG-Debug-ID: 1604929907-11fa31480232170001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id JnchZfvmkOoTIbpf (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 09 Nov 2020 08:51:47 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=L2wgnxw2haBbbxdmRRVPN0gdSYiMZeoybeyNQPYyMPE=; b=KSJV0y6mKhz0ui8lVBDxZcQMtk4OHY5rNgHs56h4hMjkf9AHVYvpxvQH0P1cbpFmp eH4aqTvum/qa1AZ/BD70//wJ7Z/w7riv06IP6r+RLoJEvX0waNRowiWtWRfZ712D0 t0HrWmn74ur6j268NO2PnhzbUztAr4VGMWGMf2kCQ= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 9 Nov 2020 08:51:40 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> In-Reply-To: Date: Mon, 9 Nov 2020 08:51:41 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Optional p= makes no sense Message-ID: <000801d6b69f$7436ebe0$5ca4c3a0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJnFvAYYNPxbo682UuXkqFmV91VxgE2L/ShAi1iu64BP6dQ+gF+zLGjAXgLJX4BWknEuQCz0PCrAI+BOUcCO4hT1wFR+JhYqDDnfEA= X-Exim-Id: 000801d6b69f$7436ebe0$5ca4c3a0$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1604929907 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2835 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85756 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 13:51:51 -0000 I would be content with language that says: If an evaluator detects a DMARC record without a policy tag, it MAY = reject the record as invalid or it MAY treat the record as equivalent to = p=3Dnone.=20 Consequently, domain owners SHOULD include a p=3D tag, as the recipient = action is otherwise unpredictable.. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Alessandro = Vesely Sent: Monday, November 09, 2020 7:15 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Optional p=3D makes no sense On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote: > On 11/7/20 1:11 AM, Alessandro Vesely wrote: >> On Fri 06/Nov/2020 14:57:46 +0100 Todd Herr wrote: >>> On Fri, Nov 6, 2020 at 7:27 AM Douglas E. Foster wrote: >>> >>>> It makes no sense to allow "p=3D" missing. Why would we suggest=20 >>>> that all existing implementations alter their code to tolerate=20 >>>> additional unnecessary complexity, rather than requiring domain=20 >>>> administrators to key a few more characters so that code changes = will not be necessary? >> >> >> Are there really implementations that choke on missing p=3D? >> >> How about "v=3DDMARC1; p=3Dnone; p=3Dquarantine;"? >=20 >=20 > I'm pretty sure both cases would be invalid as DMARC policy records,=20 > in which case they should be ignored. I don't think so. The current draft says: 6. If a retrieved policy record does not contain a valid "p" tag, = or contains an "sp" tag that is not valid, then: 1. if a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver SHOULD act as if a record containing a valid "v" tag and "p=3Dnone" was retrieved, and continue processing; > If an implementation is trying to do something with invalid records=20 > like these, particularly one with multiple "p=3D" tags, then that = would=20 > be a problem. Invalid or repeated p=3D tags are a problem, but possibly they don't = completely disqualify a record. So the question becomes "How does a = missing p=3D tag differ from an invalid one?" This is a marginal question, to define the syntax of a DMARC record as = simply as possible (but not simpler). I added a comment to ticket #7[*] = with a proposed syntax. IMHO the spec should just mention undefined = behavior or some such, without trying to impose overly strict = commitments =E2=80=94given that parsers have to deal with the = possibility of non-conforming records anyway. This question is not related with splitting policy into its own = document. Best Ale --=20 [*] https://trac.ietf.org/trac/dmarc/ticket/7#comment:4 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Nov 9 06:05:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8633A0C8B for ; Mon, 9 Nov 2020 06:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLASSDmNaLmG for ; Mon, 9 Nov 2020 06:05:21 -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 BB2C53A0C1F for ; Mon, 9 Nov 2020 06:05:21 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0A9E8nTP019548 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 9 Nov 2020 06:08:50 -0800 Reply-To: dcrocker@bbiw.net To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 9 Nov 2020 06:05:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 In-Reply-To: <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 14:05:23 -0000 On 11/9/2020 4:15 AM, Alessandro Vesely wrote: > Invalid or repeated p= tags are a problem, but possibly they don't > completely disqualify a record. The concept of 'partial' disqualification points to the problem of trying to be subtle in specifications. A specification should provide and demand simple details and simple handling of problems. If a domain owner cannot produce a DMARC record that is correct, then it is far too likely they don't know enough to participate in DMARC. Here, the simple rule should be: An invalid DMARC record MUST be treated as if no DMARC record is present. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 9 08:06:17 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6913A117B for ; Mon, 9 Nov 2020 08:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYxe8axV26yC for ; Mon, 9 Nov 2020 08:06:14 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 52B793A117A for ; Mon, 9 Nov 2020 08:06:14 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id t5so6315222qtp.2 for ; Mon, 09 Nov 2020 08:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M72Cm9bmknfAFHUD0LbJnqPxiCBeRujdBBSI4hFz6z8=; b=Rr2jL1uw2nBpQbVmImkNpg10VNUTgnIr8RcMxxBaPd2Tnzd2Ti7Pfpr3Cgeov34xp4 6d1vI/z61XCheEWvdFf5yfcaoh6RthIL9qks6z9SAW1ThKc5xd1rnn96HURokmyTCifn hh39vpQdko3o6xs2QoKXcfF+GtFuI2L/09GhxgeVoyUBtAmMGPFj9uY3Kr2TD/nsg588 5P3HhKAtfI/KA1syQWlZqe77AS73AhHctSY54mpy5jubosG71RBT3cmk8jDwCL9/dHcT rT8cgEArgnSRIsal/z2/hUSCclkKB4GZMy5PLLJ242Wl2uNnaq5QtW78Za4cvGHhPNZ6 Bo3w== 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=M72Cm9bmknfAFHUD0LbJnqPxiCBeRujdBBSI4hFz6z8=; b=S+lEVK5OMr2cctL2jLvjH0wt05OoaKzmmukvobuNAg6x6qYnjO9OYJmVPEOgdPjc7g LaOCoEfudAOWuho1R95Oydt/2wse437XQs/tOlB8JHYV72INgYkJY6dR73Mh+Bpw9wg3 Bnpd1c3juZ+dTLzHWKJ+MS8uehlgKBuSkPN2TB8Qyjyl2P0IcmUfdIv8VLUI7O1Bsajm KZK8etJew0zpfYO32XpODhdAM9du8rqzHxJUGbbTZUUfMv0shsVZ0MC4pRzuT/0bTbZC eth9yxWDl4PmyC5/E7T5O1YGPwRRtDqKCZKOu7KK2kXtdhZIc6/jtZLAg9cvVAjkuHjw R32g== X-Gm-Message-State: AOAM5324hnceAK9SAwo4uAcAX6CVLCVuzvOP3v0HicbRa+4G62TFB0BN kaXfR8sN0+ABZYS2OEsteTh23Ac1O2Uwnc2pJkSwNELB X-Google-Smtp-Source: ABdhPJxXziYvo/T8j3KIdy6RlcOE5cYK4glBWvcaG381FCPVYAPTX+f7M4l1NzdGz4JX5n/6JVlNON//AYNXfG1GRew= X-Received: by 2002:ac8:5412:: with SMTP id b18mr14255094qtq.220.1604937973306; Mon, 09 Nov 2020 08:06:13 -0800 (PST) MIME-Version: 1.0 References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> In-Reply-To: From: Dotzero Date: Mon, 9 Nov 2020 11:06:02 -0500 Message-ID: To: Dave CROCKER Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c9184905b3aebd23" Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 16:06:16 -0000 --000000000000c9184905b3aebd23 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 9, 2020 at 9:05 AM Dave Crocker wrote: > On 11/9/2020 4:15 AM, Alessandro Vesely wrote: > > Invalid or repeated p= tags are a problem, but possibly they don't > > completely disqualify a record. > > > The concept of 'partial' disqualification points to the problem of > trying to be subtle in specifications. > > A specification should provide and demand simple details and simple > handling of problems. > This! > If a domain owner cannot produce a DMARC record that is correct, then it > is far too likely they don't know enough to participate in DMARC. > +1 > Here, the simple rule should be: > > An invalid DMARC record MUST be treated as if no DMARC record is > present. > +100 Michael Hammer --000000000000c9184905b3aebd23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 9, 2020 at 9:05 AM Dave C= rocker <dhc@dcrocker.net> wro= te:
On 11/9/2020= 4:15 AM, Alessandro Vesely wrote:
> Invalid or repeated p=3D tags are a problem, but possibly they don'= ;t
> completely disqualify a record.


The concept of 'partial' disqualification points to the problem of =
trying to be subtle in specifications.

A specification should provide and demand simple details and simple
handling of problems.

This!
=

If a domain owner cannot produce a DMARC record that is correct, then it is far too likely they don't know enough to participate in DMARC.

+1


Here, the simple rule should be:

=C2=A0 =C2=A0 =C2=A0 An invalid DMARC record MUST be treated as if no DMARC= record is
present.

+100

Micha= el Hammer
--000000000000c9184905b3aebd23-- From nobody Mon Nov 9 09:07:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4C23A1149 for ; Mon, 9 Nov 2020 09:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVtLwRUtt29J for ; Mon, 9 Nov 2020 09:07:44 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B9C3A0DDD for ; Mon, 9 Nov 2020 09:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1604941661; bh=lh0zHvn03ioaelYtzUZuGQnSoFP5IeyIckoFomuVyCM=; l=963; h=To:References:From:Date:In-Reply-To; b=Ag3CRVw2gNnw1PkoTvBHRDKxn02NXDg5DGoHLRHsC3SjQsmqMf9apz4soqIKrdSoB oAQhCg/VApWnTeQj9X9fOk5xBQ/2mRb3e5Tg4J63SOmkhDbIqdZ6lI4ZBI9gppe5JV uywSLEestoKobY5wfz5+sdfHIZZn+Ib+4A8CoF/hPNI10yY2tHCZ2IGUwZ3cZ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FA9775D.00005FDE; Mon, 09 Nov 2020 18:07:41 +0100 To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> From: Alessandro Vesely Message-ID: <30676b2a-9f84-414b-c029-416061c68e19@tana.it> Date: Mon, 9 Nov 2020 18:07:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 17:07:46 -0000 On Mon 09/Nov/2020 17:06:02 +0100 Dotzero wrote: > On Mon, Nov 9, 2020 at 9:05 AM Dave Crocker wrote: > >> If a domain owner cannot produce a DMARC record that is correct, then it >> is far too likely they don't know enough to participate in DMARC. >> > > +1 Agreed. Possibly, bad DMARC records can be reported to the human point of contact disclosed in aggregate reports, for domains which generate them. >> Here, the simple rule should be: >> >> An invalid DMARC record MUST be treated as if no DMARC record is >> present. >> > > +100 +1e2 for me too, even if it disparages bullet 6 of Section 6.6.3. (Aren't we inflating consensus a little bit this way?) Yet, it is going to require more wording to make p= mandatory (while sp= is optional) except for external destination verification records where p= is not required, than to make all tags optional except v=, at least syntactically. Best Ale -- From nobody Mon Nov 9 12:02:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E293A12D7 for ; Mon, 9 Nov 2020 12:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbPd4dGGCtLf for ; Mon, 9 Nov 2020 12:02:10 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC4B3A0980 for ; Mon, 9 Nov 2020 12:02:10 -0800 (PST) Received: from [10.10.10.124] (135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94]) (authenticated bits=0) by segv.crash.com (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 0A9K21xu016921 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 9 Nov 2020 20:02:10 GMT (envelope-from smj@crash.com) DKIM-Filter: OpenDKIM Filter v2.10.3 segv.crash.com 0A9K21xu016921 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1604952130; bh=JRqURWuu839Zvc0YZDl5sRz+AXS9QPvIxmlOeOzmMgE=; h=Subject:To:References:From:Date:In-Reply-To; b=uo7S0P9hgvAkSWRwPtBn87yip3CD5uFvjk+3La0utOP3gTBMD0ArVRWGJOE9uJd9q w7ZtxL0UUfWQv3eE1IqaUHi0czaRvCgKrGrDSoOtTsV0a5kFsPbbsXru7Fyo1ohHHU OnkdHA0sViYYjZkK9/TSf8CSllvQKPyTHOVAo0ToXm29LqpBJD8t9Gaak3iho9rP3I sFheHXgJiWCkuoTQS5D7XyMa8BVdW0hWfdYO4lEtY/CGo4IQUBgMrnEOpTSIQXLoO8 06TLwxpABuBnWsxxLv7SH/KE+J5/MJdprLBHES/Oks/rtK2i1wN7ZiuCXEb0+NLlSP N9R9EbdUDkvbQ== X-Authentication-Warning: segv.crash.com: Host 135-180-6-94.fiber.dynamic.sonic.net [135.180.6.94] claimed to be [10.10.10.124] To: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> From: Steven M Jones Message-ID: <0c361121-b80a-c76a-9069-39ca0613a897@crash.com> Date: Mon, 9 Nov 2020 12:02:00 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (segv.crash.com [72.52.75.15]); Mon, 09 Nov 2020 20:02:10 +0000 (UTC) Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 20:02:12 -0000 On 11/9/20 4:15 AM, Alessandro Vesely wrote: > On Sat 07/Nov/2020 10:52:44 +0100 Steven M Jones wrote: >> >> I'm pretty sure both cases would be invalid as DMARC policy records, >> in which case they should be ignored. > > > I don't think so.  The current draft says: > > [...] Oops - thank you for the gentle correction about absent "p=" tags in policy records, Ale. On 11/9/20 6:05 AM, Dave Crocker wrote: > On 11/9/2020 4:15 AM, Alessandro Vesely wrote: >> Invalid or repeated p= tags are a problem, but possibly they don't >> completely disqualify a record. > > > The concept of 'partial' disqualification points to the problem of > trying to be subtle in specifications. > > A specification should provide and demand simple details and simple > handling of problems. At least "clear and unambiguous" if we can't quite reach "simple." > > [...] > > Here, the simple rule should be: > >      An invalid DMARC record MUST be treated as if no DMARC record is > present. +1 --S. From nobody Mon Nov 9 15:04:44 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95083A14C9 for ; Mon, 9 Nov 2020 15:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 GjbE4l0RxHjP for ; Mon, 9 Nov 2020 15:04:41 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 25EA53A14BC for ; Mon, 9 Nov 2020 15:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3h1aY9u716nlvG+Imnl/MMH9EEOzHjdLiOK61AYhn3s=; b=rfwJDLg0BAWZUt5/hdy1s344+L fgTto+UgFye3Tabc3CRB4pLpkGYezZGeh3ZdBkNROJkBxngbHZ+6eF5xWpAtYP53LDuGrVUMA6Kcn Jb7ZDuQSQr/p9+zSCDEPsRWhE+Q0nmhBlNhuBkQhfdG9wxNi59DdpkR2jMY4rkOmYUVU=; Received: from [2601:647:4400:1261:5a7:ee78:8a14:e735] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcGDI-0006cP-4U; Mon, 09 Nov 2020 15:04:40 -0800 From: "Jim Fenton" To: "Steven M Jones" Cc: dmarc@ietf.org Date: Mon, 09 Nov 2020 15:04:39 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 23:04:43 -0000 On 7 Nov 2020, at 20:12, Steven M Jones wrote: > Okay, but what is the expected payoff from splitting it out? Does it > make it easier to process and approve updates of the policy content > separately from, say, the description of record discovery or Alignment > concepts? Easier to pass muster for Standards Track? Are implementers > currently confused and dissuaded by having policy details mixed with > the other content? > > If the benefits seem worthwhile, I could get behind the split - but > there ought to be a clear benefit. The benefit I have in mind is that reporting does not cause issues with indirect mail flows (the addressing of which is item 1 on the WG charter), so it can proceed even while there isn’t WG consensus on how to solve that problem for the policy piece. Or in the extreme case, it can proceed even if IESG considers the policy piece to not have an acceptable solution. Of course, if the solution to the policy piece is likely to affect the discovery/binding of the policy and reporting, which would be in the base document, this argument doesn’t hold. -Jim From nobody Tue Nov 10 13:57:11 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC5D3A1086 for ; Tue, 10 Nov 2020 13:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=IF84fPnH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=dnJLrFWR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LGiuA3X5hAA for ; Tue, 10 Nov 2020 13:57:06 -0800 (PST) Received: from mail.winserver.com (mail.santronics.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A443A1082 for ; Tue, 10 Nov 2020 13:57:05 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4583; t=1605045423; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=n+TE0yg7PZ521aNSTokrLZZNB5Fk M9m62EV6GpHn1yI=; b=IF84fPnH4ciAYjW9QoFyBx7clmF6sZZESulopi5bOYA4 u50VEV1e8JH35Oagqw+xin71BYoLbOS1tG8BToOVjrH5wwvsBdgQOOmO14xloDOg +u19Ud/0CvgSFzKp10acTyT/AKoJEVUsEzXt6tU/3C1tp8HHQZ2NrTz6PVCGIqg= Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 10 Nov 2020 16:57:03 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2780503524.1.3708; Tue, 10 Nov 2020 16:57:02 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4583; t=1605045132; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=n+TE0yg 7PZ521aNSTokrLZZNB5FkM9m62EV6GpHn1yI=; b=dnJLrFWRElKNXG2fNBONTjL v5PTwgMpXxqNlepg6M/I5AxncZ5B9cZZlRhkh7YbWueTvX+sQWdlwpNzfGxpZ7gK svuvykWkyGDHwwDACJ9cjQC56KnUiWnMiq25m/6QkCPsN+b7pgSFk2vHE76IbaWg QFw/UEkJDfWsQzjgnhc8= Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for dmarc@ietf.org; Tue, 10 Nov 2020 16:52:12 -0500 Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 2647403813.1.5260; Tue, 10 Nov 2020 16:52:11 -0500 Message-ID: <5FAB0CAD.4090809@isdg.net> Date: Tue, 10 Nov 2020 16:57:01 -0500 From: Hector Santos Reply-To: hsantos@isdg.net Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Jim Fenton , Steven M Jones CC: dmarc@ietf.org References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <6460DF58-84E9-4390-9268-A7492476E0F3@bluepopcorn.net> <00c2d38b-914b-274f-af3f-c0c808de37e4@crash.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Announcing DMARCbis Editors X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 10 Nov 2020 21:57:10 -0000 On 11/9/2020 6:04 PM, Jim Fenton wrote: > On 7 Nov 2020, at 20:12, Steven M Jones wrote: > >> Okay, but what is the expected payoff from splitting it out? Does it >> make it easier to process and approve updates of the policy content >> separately from, say, the description of record discovery or >> Alignment concepts? Easier to pass muster for Standards Track? Are >> implementers currently confused and dissuaded by having policy >> details mixed with the other content? >> >> If the benefits seem worthwhile, I could get behind the split - but >> there ought to be a clear benefit. > > The benefit I have in mind is that reporting does not cause issues > with indirect mail flows (the addressing of which is item 1 on the WG > charter), so it can proceed even while there isn’t WG consensus on how > to solve that problem for the policy piece. Or in the extreme case, it > can proceed even if IESG considers the policy piece to not have an > acceptable solution. > > Of course, if the solution to the policy piece is likely to affect the > discovery/binding of the policy and reporting, which would be in the > base document, this argument doesn’t hold. My view. I was the 2nd on Jim's proposal to split DMARC. I presumed the obvious: - DMARC-BASE - DMARC-REPORTS (optional reporting features. Not required) DMARC-BASE is the base policy protocol based on the DKIM-POLICY model as was DKIM-SSP and DKIM-ADSP. All these proposals used the required DKIM 5322.From domain identity binding as input for a DKIM Policy model.The DKIM Signer Domain identity is input for an Reputation lookup that never materialized. DKIM-VBR is the closes thing we have to a IETF proposed reputation lookup for DKIM. DKIM-VBR does the Author and Signer as input. I favored the split for the same reasons DKIM was split into two WG PS work items: - DKIM-BASE was the base signing/verification protocol, - DKIM-POLICY where DKIM-SSP was the draft proposal on the table. The split allowed DKIM-BASE to be completed and now we have a DKIM STD document. Fenton was the editor of DKIM-SSP. It evolved to DKIM-ADSP which was abandoned and the DKIM WG ended. It was replaced with DKIM-DMARC as an Informational Status document. Keep in mind that DKIM-SSP covered 3rd party policies with an "o=" tag: SSP Draft: o=~ NEUTRAL (signature optional [No 3rd party?]) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER WG Suggestions: o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) Due to the ambiguity of the 3rd party policies and the lack of a 3rd party authorization protocol, Levine rewrote DKIM-SSP draft 3 titled DKIM-ASP and by draft 10, it became DKIM-ADSP. ADSP stripped the 3rd party semantics and pretty much left an EXCLUSIVE policy with ADSP DISCARDABLE policy. DMARC also offered a similar exclusive signing policy and also reported as well. Fast forward to today. I believe the charter is touching based with the 3rd party resigners design issues. So we are back to a situation where we may have three documents: - DMARC-BASE base protocol for current strong 1st party policy, - DMARC-REPORTS optional reporting - DMARC-TPA Third party Authorization proposals. The DMARC-TPA should cover ATPS, ARC and hopefully conditional signatures. However, based on the charter, it outlined specifically: * Incorporate ARC or something that deals with indirect mailflows This work item was lumped into DMARC-BASE. My position is this: I believe ARC or "something that deals with indirect mailflows" that is not well defined or has not gained traction as a TPA solution, should not be included in DMARC-BASE. DMARC-BASE should be independent of any other add-on but it should allowed for Tag Extensions to support TPA concepts included ARC, ATPS and conditional signatures. In my opinion, this is a best way to get DMARC-BASE fast tracked to standardization. DMARC-TPA or DKIM-TPA can be a separate doc that specifies add-on DMARC augmentations which are designed to help address the long time 3rd party resigned and authorization issue. While I personally, and I believe ideally, prefer ATPS be included in the DMARC-BASE protocol, due to the lack of WG support, I rather get the DKIM-BASE 1st party semantics completed first. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos From nobody Tue Nov 10 16:54:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FDA3A1273 for ; Tue, 10 Nov 2020 16:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrBBS_OzYGrl for ; Tue, 10 Nov 2020 16:54:10 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 9D4ED3A1274 for ; Tue, 10 Nov 2020 16:54:10 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id u24so209929vsl.9 for ; Tue, 10 Nov 2020 16:54:10 -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=fhoAM0O9khN6QoPSbRuPx94An1HKPv2o4ZMNmmxRhX0=; b=Ly8LbOXBehzpnXMn3z4gU+XAPuv/qHybf8wLpo01gmJxlXGom/bBXrrp1pIBGAZN6C cHjsenLa04vZU3L0lJ3NXUgaEexPaW5WHvhTH2CIA/9F8NJ9EorXaxojp/SiMPanf5ht EGIEZivP8W0esYMl5IaBwvcghJzDgJBAAwgdvIrw7bXTYjTzwmFMEolixBZoXIWRfm9U q4lb+hKQ+U+RQ+1QJ2ha7KlBnHb1ihGDocycT+ifA0FEAVXfJLK6xLa6TYhgPpZhjhme W14X+j6xy0VkO33Wmn5wrg3mY8P2TYfTtXG3BGq38KidkzSQNM38yHkeaEcO87KkI/k9 jVng== 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=fhoAM0O9khN6QoPSbRuPx94An1HKPv2o4ZMNmmxRhX0=; b=Hjku48Gz7UP0hS3UgQOfFifb0NHfVpd6/2QrVsmm/T028L69qVaTVHLxo5g2m0VYfs VzlNhoFXMpW5zn1NSiB+QP92Zq0pB4gWirr3ZHfh1hHNjcHUBSjkMcy5rXMH6MpCuCA7 rawXYPH2LC9g5UK0XMAsyYYVrLFisSETl/aPw+alMy5bIW1R9cj4nqX3edERoVpEjECi gUOzPPFaQjkzuS5Wg+hRFZI8ttirF30jgP5A2O5zwW7/2ZgZQyBATji1oJo+6nAv1yC3 /cYpTTgZv4jhg79gCRELHgvIIOck/3LtuLxoYHW5bkJdK8PUYLxSjC/LChjXqdLe6fQU heyQ== X-Gm-Message-State: AOAM532RSBJrPpIKUrS7cVnXh3TeFLf0fEQf3K+LwewmhpBs0JuVhsY2 /aB4D3w6BUDQ3eozK1Ynk5Yrf/+QtnHr44hTaU6i1X/V X-Google-Smtp-Source: ABdhPJxSyCLdX8JOfL0DsfRDEId/U6YcnDyzLGkoDLiz/30f1PeLVXfQ8j7iHzrLTyL3WSpJJkLk/iPqK229Ufv8P/I= X-Received: by 2002:a67:783:: with SMTP id 125mr3702276vsh.15.1605056049474; Tue, 10 Nov 2020 16:54:09 -0800 (PST) MIME-Version: 1.0 References: <5A7444DD-385E-44E3-BAAF-BE87AE5FDA61@bluepopcorn.net> <3676bcc9-8c7f-102a-f844-d08d6914077e@tana.it> <7a0730e3-50cd-7c02-149c-d325f4508494@tana.it> <74f6fc6c-40f4-044d-225c-bda891bdd963@tana.it> <000801d6b69f$7436ebe0$5ca4c3a0$@bayviewphysicians.com> In-Reply-To: <000801d6b69f$7436ebe0$5ca4c3a0$@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Tue, 10 Nov 2020 16:53:57 -0800 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ac6f5105b3ca3b19" Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 00:54:12 -0000 --000000000000ac6f5105b3ca3b19 Content-Type: text/plain; charset="UTF-8" Merely as a participant: +1 to Dave's reply to this. On one particular point: On Mon, Nov 9, 2020 at 5:51 AM Doug Foster wrote: > If an evaluator detects a DMARC record without a policy tag, it MAY reject > the record as invalid or it MAY treat the record as equivalent to p=none. > Consequently, domain owners SHOULD include a p= tag, as the recipient > action is otherwise unpredictable.. > When it comes to requirements language in standards track documents, and particularly with respect to SHOULD, be prepared to answer this question: Under what circumstances might an implementer deviate from the recommendation presented by the SHOULD? If the text doesn't make that clear already, you can expect I'll ask that question when it comes up for AD Evaluation. If there's no solid answer to that, then you might consider MAY or MUST, or omit the requirements language entirely. In this case, why might an operator consciously omit "p=", and to what end? If there's no good answer to that, I'd consider making "p=" mandatory. -MSK --000000000000ac6f5105b3ca3b19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Merely as a participant: +1 to Dave&= #39;s reply to this.

On one particular point:
<= /div>

On Mon, Nov 9, 2020 at 5:51 AM Doug Foster <fosterd=3D40bayviewphysicians.com@dmarc.= ietf.org> wrote:
If an evaluator detects a DMARC record without a policy tag, it MAY= reject the record as invalid or it MAY treat the record as equivalent to p= =3Dnone.
Consequently, domain owners SHOULD include a p=3D tag, as the recipient act= ion is otherwise unpredictable..

<ad= >
When it comes to requirements language in standards track documents= , and particularly with respect to SHOULD, be prepared to answer this quest= ion: Under what circumstances might an implementer deviate from the recomme= ndation presented by the SHOULD?=C2=A0 If the text doesn't make that cl= ear already, you can expect I'll ask that question when it comes up for= AD Evaluation.

If there's no solid answer to = that, then you might consider MAY or MUST, or omit the requirements languag= e entirely.

In this case, why might an operator co= nsciously omit "p=3D", and to what end?=C2=A0 If there's no g= ood answer to that, I'd consider making "p=3D" mandatory.</ad>

-MSK
--000000000000ac6f5105b3ca3b19-- From nobody Tue Nov 10 17:06:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E2E3A127B for ; Tue, 10 Nov 2020 17:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gKMFJ4hIQ6g for ; Tue, 10 Nov 2020 17:06:24 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2B33A1276 for ; Tue, 10 Nov 2020 17:06:23 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id l22so241298vsa.4 for ; Tue, 10 Nov 2020 17:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bx1NLCfaov/pcHIxMefPYSPCc3dK7OncPBXaHSex37k=; b=USYhhJuXplEqRdFXblB9HTwoLJMwUsV+ssQ9Z/CBjZeN8p4k5lbyprsVBXvf5bUguT rjaDxS238vUg7I888uHUWpn4jZh7Ha1dZbs60c3KM986YZgnNVZP3H5nvfYZzp+cuLk0 LPFotahzOJC78+i2wx8trnU7rhpZdU3dfZoNCqceJA00SVeQcmRt0ndZZg2ymKJFOeOL 5ma8fdgLcUCtJnQHukesGngQVZgbsRNmnDTzTmULjdl6H47XO0bFaMqS8FXFNikuAToS NWF/XNsu5NgH1qDkadr3/LmZbrIXdmzclIr2W6JtMBoKJ32jHnBTFVxRSeZlyfOvdur7 13pQ== 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=bx1NLCfaov/pcHIxMefPYSPCc3dK7OncPBXaHSex37k=; b=MgG5TOJc0p3hX7I9wwLCrFnDuMVEKGxqn/GHI85nBqcCPpZaZ8VVNDGXNKPEzqxgZb UDuO0W8yRATitD0PGUslGWzFn+POHRlbQgwPnkro2ZbtZOHbeXLQmFF/A1K+MyQ8g8KQ MIRi+yNtKrJVvSta1AgwKcc5o6+GxMKYrUUg9cVqNGOIESkQsQQWYiAwiwnaoWFKY5gG A32sabaB8GxSyr2PIzR9B7gHzfF6cryciPt16+aTyGtERPMMlCVdn7JSCQKqvy8DAydv yVsIGGmHgsHURkexyAZupsY+BaTEsDEMGpG76U54lLs83/phh9oz+C9uVlsoUxU4yd1Q ZTAQ== X-Gm-Message-State: AOAM5321E7KiYdUtpOLi/o9QeE6uQys8T2+o0TO83Gv3y5FXIskPUx7k r7hCFZOcC0dIx0Xdp8zGcUQq/MncWHtiMq8F8wkNcsA6mSQ= X-Google-Smtp-Source: ABdhPJzkdPLvmb4imF7ScX/tBew+BqenbHjBdbqJhItC/IjL7UvEsX7vovvFAHQ3zw0DrvWdhdPtiT6nr4ri1j4UPEo= X-Received: by 2002:a67:f04:: with SMTP id 4mr9627801vsp.54.1605056782579; Tue, 10 Nov 2020 17:06:22 -0800 (PST) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Tue, 10 Nov 2020 17:06:10 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005eba0205b3ca6713" Archived-At: Subject: [dmarc-ietf] On splitting documents X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 01:06:26 -0000 --0000000000005eba0205b3ca6713 Content-Type: text/plain; charset="UTF-8" Not to lob monkey wrenches around, but at one point we were talking about putting the determination of the Organizational Domain into a separate document. I think it was Dave who suggested it. This would allow for simple augmentation of DMARC implementations when something better than the current PSL-type mechanisms came along, without having to spin up a full "Updates" pass over DMARCbis itself. I ask because this came up during IESG Evaluation of a document from another working group[1] recently, where that working group was doing something that mandated a DMARC "pass". Since DMARC is currently Informational (and not an IETF product in any case), it might be beneficial for DMARCbis (the core of it) and things like the OD algorithm's evolution to progress, and be reference-able, independently. [1] See Barry's DISCUSS position on draft-ietf-acme-email-smime. -MSK, participating --0000000000005eba0205b3ca6713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not to lob monkey wrenches around, but at one point w= e were talking about putting the determination of the Organizational Domain= into a separate document.=C2=A0 I think it was Dave who suggested it.=C2= =A0 This would allow for simple augmentation of DMARC implementations when = something better than the current PSL-type mechanisms came along, without h= aving to spin up a full "Updates" pass over DMARCbis itself.
<= br>
I ask because this came up during IESG Evaluation of a docume= nt from another working group[1] recently, where that working group was doi= ng something that mandated a DMARC "pass".=C2=A0 Since DMARC is c= urrently Informational (and not an IETF product in any case), it might be b= eneficial for DMARCbis (the core of it) and things like the OD algorithm= 9;s evolution to progress, and be reference-able, independently.
=
[1] See Barry's DISCUSS position on draft-ietf-acme-emai= l-smime.

-MSK, participating
--0000000000005eba0205b3ca6713-- From nobody Tue Nov 10 17:48:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886E3A12CF for ; Tue, 10 Nov 2020 17:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHNGuZB0HVdW for ; Tue, 10 Nov 2020 17:48:34 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 C30F33A12C7 for ; Tue, 10 Nov 2020 17:48:34 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id y197so340192qkb.7 for ; Tue, 10 Nov 2020 17:48:34 -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=CSAn4pmpXzU/WCAjMMzhvbViDm8EiKUjFcqeJ2fUg38=; b=PTf6eyRtSbL3PnUa2KtfKXZ4H55PB2fS/guxTJXjrHQIW+OFIG4OAwloZvpgK8mKsi MHB7i8zZif3KYBJFd4m0fHpvJJy6Y7dU+/lCBBkwy1HiPY5/XSMLjpIXJNscNrQY0cPw mo2MgPrJ2mKMSziYNAvK2idVLqHySAntO4Heo3tMmS+YEwxvJvFKXojgiZ2gfLd40y6u IdV0rE3sms482w2y4cABs9/g6hY24yNYCg2kEpsZsoyfcB0a6Lyhb+NWr2BCceNMFl8C KdZSHXtKAGVH1YLJ1b80BSWw9BXLtqKQ3hGA7jd9Bw94Hjsgv1LGpLgQYI3XsA8+WbrX cnxg== 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=CSAn4pmpXzU/WCAjMMzhvbViDm8EiKUjFcqeJ2fUg38=; b=Rqp63hxmh5htU2YmRkIcaBvzM++tjlL0hTXCmHtPyTMeROQxlHZlHOa1WvJKDuz95m URFuYKs1uylz+TtfdW8ef8daWXX0GoJqe3gsgGXCXEdmBLEVXkR/6KCCXjip21TVtSGM WdyBXqg5/a7EpHSIs+leMEu/TUYQmRntWSqxGUbBxys5HrdhWrlbt2zMMxL9LW+26uYZ KRhtSoa24vzBdSCkStJfxNAx678bEWVHQywWEGZnxlvhwSvlJD8JCMoL/9mZihGr7mMZ 92nl19cBUhVYv2mnkgJ6DRJAJstuCAPbbywXgvk72r0iQecYNdkzdjV+5MDOlD6wv8Bb Wybg== X-Gm-Message-State: AOAM530hHZxpvksdL7FbNbB4pBmqRuKevqsMGhtFW32/e4x/FuFZKBU5 5EzsCRRIBGgjjjirZGP6ZsiiSH4xzSRWlrSdqq8= X-Google-Smtp-Source: ABdhPJy36SRukkq7l944Toed+NGaSvWna+Twp0hBfrg7x/IKAUyL2pDRcM/Bpv7x967ozmvup724mEMguMS/C/cwEms= X-Received: by 2002:a05:620a:1521:: with SMTP id n1mr15222072qkk.187.1605059313868; Tue, 10 Nov 2020 17:48:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dotzero Date: Tue, 10 Nov 2020 20:48:22 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003f22d705b3cafeb4" Archived-At: Subject: Re: [dmarc-ietf] On splitting documents X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 01:48:37 -0000 --0000000000003f22d705b3cafeb4 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 10, 2020 at 8:06 PM Murray S. Kucherawy wrote: > Not to lob monkey wrenches around, but at one point we were talking about > putting the determination of the Organizational Domain into a separate > document. I think it was Dave who suggested it. This would allow for > simple augmentation of DMARC implementations when something better than the > current PSL-type mechanisms came along, without having to spin up a full > "Updates" pass over DMARCbis itself. > This actually makes sense because there are other potential documents/uses besides DMARC that could reference PSL-type mechanisms. > > I ask because this came up during IESG Evaluation of a document from > another working group[1] recently, where that working group was doing > something that mandated a DMARC "pass". Since DMARC is currently > Informational (and not an IETF product in any case), it might be beneficial > for DMARCbis (the core of it) and things like the OD algorithm's evolution > to progress, and be reference-able, independently. > > [1] See Barry's DISCUSS position on draft-ietf-acme-email-smime. > Michael Hammer --0000000000003f22d705b3cafeb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 10, 2020 at 8:06 PM Murra= y S. Kucherawy <superuser@gmail.c= om> wrote:
Not to lob monkey wrenches around, but at one point= we were talking about putting the determination of the Organizational Doma= in into a separate document.=C2=A0 I think it was Dave who suggested it.=C2= =A0 This would allow for simple augmentation of DMARC implementations when = something better than the current PSL-type mechanisms came along, without h= aving to spin up a full "Updates" pass over DMARCbis itself.
<= /div>

This actually makes sense becau= se there are other potential documents/uses besides DMARC that could refere= nce PSL-type mechanisms.

I ask because this came up = during IESG Evaluation of a document from another working group[1] recently= , where that working group was doing something that mandated a DMARC "= pass".=C2=A0 Since DMARC is currently Informational (and not an IETF p= roduct in any case), it might be beneficial for DMARCbis (the core of it) a= nd things like the OD algorithm's evolution to progress, and be referen= ce-able, independently.

[1] See Barry's DISCUS= S position on draft-ietf-acme-email-smime.
Michael Hammer
--0000000000003f22d705b3cafeb4-- From nobody Tue Nov 10 18:12:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1609A3A12EB for ; Tue, 10 Nov 2020 18:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=I0vrQG1T; dkim=pass (2048-bit key) header.d=taugh.com header.b=cWOUg8wO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bisc8rvwnkAc for ; Tue, 10 Nov 2020 18:12:48 -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 8B74F3A12EA for ; Tue, 10 Nov 2020 18:12:48 -0800 (PST) Received: (qmail 79410 invoked from network); 11 Nov 2020 02:12:45 -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:cleverness; s=1362a.5fab489d.k2011; bh=qImJD557mA+H87m4veyRF61tCc8oxZscVqIuD/iNWzU=; b=I0vrQG1TR47+ZbT6uGVzIYbKHBq3gZ+cmowcfr5pnR2fbE2SBRtiOptPIN+KGLvvOHf/0fBUzuYJQKI1pazQxNzqsqf76/hVpO7pecySZJ0CflHVpQQjP/Zm71yKSYYqAS17CYzQh5a+lSvIVwOx5uMoONdBIM1oqi3R3itAOA/QOfxz7WA5vSGTUOzzeq9TNcrgH6HL6TDPoOfB+XAbQlb4dOoh9r6Zsy29sHtfU8btvS9EqXBpsm3acoCNm9MB7g50Kt0QI8ul2RkBbd3M3bgAaAYJ8rgAVhBEE+irw4e9TIn9JMI/gD6mQWA0zcoi63AGEoaxyw9gw9Fmu4Dumg== 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:cleverness; s=1362a.5fab489d.k2011; bh=qImJD557mA+H87m4veyRF61tCc8oxZscVqIuD/iNWzU=; b=cWOUg8wOr0OpY5XEoufRJwxfbpkOixHHD0VzPRpE3Q37CIliuLOytgZzumgsgMKYiRA4pX25qzbhTdpWFFoTZ5FyLqZT0VPqKoASj8Tny0gnV2b6Gd0LH+Gakq0s0UB/wmmjxf9CMZnVceXSllumerD2+hamHbOPXo3lNonaI76+swwMxAhnlrSutUxfjrekHn0Ob2ZQFLuTJn6p7AOWNEa9GZFOO/5/mRAsMXkR2moa/XRj1nyHrKiDw9X1S6s8sGxerc+0Snfs3+DVtbQR8deqmcE/H6MHQdKJs7Vdw3zv7Tr2n2FnihkRZR5xGMYXfc8nlMNkgB4MnIYk8zFX6w== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 11 Nov 2020 02:12:45 -0000 Received: by ary.qy (Postfix, from userid 501) id EBD2525EE02C; Tue, 10 Nov 2020 21:12:44 -0500 (EST) Date: 10 Nov 2020 21:12:44 -0500 Message-Id: <20201111021244.EBD2525EE02C@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Optional p= makes no sense X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 02:12:50 -0000 In article you write: >In this case, why might an operator consciously omit "p=", and to what >end? If there's no good answer to that, I'd consider making "p=" mandatory. Make it mandatory. If you can publish a DMARC record at all, you can put a p= tag in it. I agree we should remove the rule about what order the tags appear. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Nov 10 18:24:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8F3A00E3 for ; Tue, 10 Nov 2020 18:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=gWbeMtbv; dkim=pass (2048-bit key) header.d=taugh.com header.b=kGxsIW/e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79xaw-AB8w8F for ; Tue, 10 Nov 2020 18:24:46 -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 5A1463A00DB for ; Tue, 10 Nov 2020 18:24:46 -0800 (PST) Received: (qmail 86878 invoked from network); 11 Nov 2020 02:24:45 -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:cleverness; s=15358.5fab4b6d.k2011; bh=omahp0NhZhqmWMWF6ohyOsaE9KAu7N8UXIX5oNeJ0ZE=; b=gWbeMtbvTIvSa3OKt2E5xzHXaYogSWx74xCrR4Y28SSEPl497VcAxr9bG1B6jxsH4BmhCE69U+dtpkexyxG1GlROtjxglIWdbVORHujwACTmidgtmuh+NJLn59drXinZKTff8yp+mm+7sGTlC0mpUghXXROfpMntzfLbdrsZwZ42vas2zempoQ+IM3dp5oTqBi/nnb9ZSGRYE5VZPHy3TdpSejrEaF/rBkvCW/5AH6kP5ErsazG/xM1ER9sc+hBcsm9kLOcSxLY0qbsRjtPmsXPQ7ts4J3ESKa0Y30l5h5ZyLl2ivc8gpG3Zf0VmRbK8mxQVTAIGScRFmc/gyZOjdA== 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:cleverness; s=15358.5fab4b6d.k2011; bh=omahp0NhZhqmWMWF6ohyOsaE9KAu7N8UXIX5oNeJ0ZE=; b=kGxsIW/epvqHbCbaSqsc+NhosRG0Ngm3fSvClbDLPHZLJKTr6B34+zV6/Pv3B/lfe1dJKFgrDvup39SCtENrv1VklPO030ryfHd0OfzLcdhZNktQs2tL0sqpF73WAKk06D7M9w63ndZjQG++w4Geq7RM+1kXHqY6+hCSmuprIsa1xFl7iYYHTKBcSa6ZSVE1k6apAaMrYmzGPMJ6yJPEfvtD4sYj/l8VD+KAha4N//D+BvVwKuEAVhyhdh0OVfbzseRwDwFIcd4RBAejuDVM+XohBHYokVbHkeR/frlE7/7N+jvqynRc6RNewWZqvL5ZV5SVT7uOdak/w1ITCO7S6w== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 11 Nov 2020 02:24:45 -0000 Received: by ary.qy (Postfix, from userid 501) id AF87925EE227; Tue, 10 Nov 2020 21:24:43 -0500 (EST) Date: 10 Nov 2020 21:24:43 -0500 Message-Id: <20201111022444.AF87925EE227@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dotzero@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 02:24:48 -0000 In article you write: >This actually makes sense because there are other potential documents/uses >besides DMARC that could reference PSL-type mechanisms. Remember that this is a well-known swamp of despair. We had a whole DBOUND working group that failed to define a PSL-like thing. I am inclined to do nothing at this point, and if someday we actually succeed in doing DBOUND, whateever we define can update 7489bis to say to use it. R's, John PS: https://github.com/jrlevine/bound is ready when you are From nobody Wed Nov 11 05:43:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACA83A103D for ; Wed, 11 Nov 2020 05:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbPlYyTNdWd0 for ; Wed, 11 Nov 2020 05:43:17 -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 65D803A0E17 for ; Wed, 11 Nov 2020 05:43:15 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ABDkcgI022747 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 11 Nov 2020 05:46:39 -0800 Reply-To: dcrocker@bbiw.net To: John Levine , dmarc@ietf.org Cc: dotzero@gmail.com References: <20201111022444.AF87925EE227@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> Date: Wed, 11 Nov 2020 05:43:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <20201111022444.AF87925EE227@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] On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 13:43:18 -0000 On 11/10/2020 6:24 PM, John Levine wrote: > In article you write: >> This actually makes sense because there are other potential documents/uses >> besides DMARC that could reference PSL-type mechanisms. > > Remember that this is a well-known swamp of despair. We had a whole > DBOUND working group that failed to define a PSL-like thing. > > I am inclined to do nothing at this point, and if someday we actually > succeed in doing DBOUND, whateever we define can update 7489bis to say > to use it. There is a difference between "splitting out existing text, on topic x" from "revise text on topic x". The current suggestion is to take the org domain text that is current in the DMARC spec and to split it out, so that the core DMARC spec does not contain specification language about organization domain, other than "find the organizational domain". That's a documentation hack, making later changes easier, rather than a current attempt to devise better OD specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 06:00:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096413A13BC for ; Wed, 11 Nov 2020 06:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy9etXrsuEmw for ; Wed, 11 Nov 2020 06:00:51 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365523A12F4 for ; Wed, 11 Nov 2020 06:00:38 -0800 (PST) X-ASG-Debug-ID: 1605103236-11fa31480256120001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 3s4OIOejE6wtUv7F (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 11 Nov 2020 09:00:36 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=40426YDrOP4Zxsf+VE4ASy5DcYB1Ym0bSBzVFtrEM1w=; b=dTGSD4EvB4NPfuAcj0M/SQih6rxW5pyzL4ExU2O5ttDJlMiUjL8A2CBhkU84+RV0y Uvw+29SD5N6S2Pu/+FlUtq+ODYGQtazYLr/9/pvFqMDq5IUSV62S/EU4YCmMCWZ1O huEUNr7o/3uS58YMgaVcg5frevTbSeRW+dSenQvrg= From: "Douglas E. Foster" To: Date: Wed, 11 Nov 2020 09:00:27 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] On splitting documents and DBOUND Reply-To: fosterd@bayviewphysicians.com Message-ID: <840755cdaa0646468adf79604ce051b7@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=cb5dcd56f9b24df29de651e9c333d715 In-Reply-To: <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> X-Exim-Id: 840755cdaa0646468adf79604ce051b7 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605103236 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4662 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85801 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 14:00:58 -0000 This is a multipart message in MIME format. --cb5dcd56f9b24df29de651e9c333d715 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can we eliminate the PSL problem simply by adding some DNS queries=3F Isn't there a maximum depth to the PSL, so that the evaluator can simply wa= lk up the top N levels of the domain tree to find either an organizational = DMARC entry with sp=3D or a PSD DMARC entry with sp=3D=3F It looks like c= urrently, n=3D4, because the published suffixes appear to extend to 3 level= s. DF ---------------------------------------- From: Dave Crocker Sent: 11/11/20 8:43 AM To: John Levine , dmarc@ietf.org Cc: dotzero@gmail.com Subject: Re: [dmarc-ietf] On splitting documents and DBOUND On 11/10/2020 6:24 PM, John Levine wrote: > In article you write: >> This actually makes sense because there are other potential documents/us= es >> besides DMARC that could reference PSL-type mechanisms. > > Remember that this is a well-known swamp of despair. We had a whole > DBOUND working group that failed to define a PSL-like thing. > > I am inclined to do nothing at this point, and if someday we actually > succeed in doing DBOUND, whateever we define can update 7489bis to say > to use it. There is a difference between "splitting out existing text, on topic x" from "revise text on topic x". The current suggestion is to take the org domain text that is current in the DMARC spec and to split it out, so that the core DMARC spec does not contain specification language about organization domain, other than "find the organizational domain". That's a documentation hack, making later changes easier, rather than a current attempt to devise better OD specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --cb5dcd56f9b24df29de651e9c333d715 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can we eliminate t= he PSL problem simply by adding some DNS queries=3F

Isn't there a maximum depth to the PSL, so that the evaluator can simply = walk up the top N levels of the domain tree to find either an organizationa= l DMARC entry with sp=3D or a PSD DMARC entry with sp=3D=3F   It looks= like currently, n=3D4, because the published suffixes appear to extend to = 3 levels.

DF


= From: Dave Crocker <dhc@dcrocker.net>
Sen= t: 11/11/20 8:43 AM
To: John Levine <johnl@= taugh.com>, dmarc@ietf.org
Cc: dotzero@gmail.com
= Subject: Re: [dmarc-ietf] On splitting documents and DBOUN= D

On 11/10/2020 6:24 PM, John Levine wrote:=
> In article <CAJ4XoYfuU531rmMhsY4VA3Kq5SN4Pzv91QEegZivF5= =5FaBJnhdQ@mail.gmail.com> you write:
>> This actually m= akes sense because there are other potential documents/uses
>&= gt; besides DMARC that could reference PSL-type mechanisms.
><= /div>
> Remember that this is a well-known swamp of despair. We had = a whole
> DBOUND working group that failed to define a PSL-lik= e thing.
>
> I am inclined to do nothing at this = point, and if someday we actually
> succeed in doing DBOUND, w= hateever we define can update 7489bis to say
> to use it.


There is a difference between "splittin= g out existing text, on topic x"
from "revise text on topic x".

The current suggestion is to take the org domain te= xt that is current in
the DMARC spec and to split it out, so that= the core DMARC spec does not
contain specification language abou= t organization domain, other than
"find the organizational domain= ".

That's a documentation hack, making later chang= es easier, rather than a
current attempt to devise better OD spec= ification.

d/


<= div>--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmarc mailing list
dmarc= @ietf.org
To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 16:51:19 -0000 On Wed, 11 Nov 2020, Dave Crocker wrote: > There is a difference between "splitting out existing text, on topic x" from > "revise text on topic x". > > The current suggestion is to take the org domain text that is current in the > DMARC spec and to split it out, so that the core DMARC spec does not contain > specification language about organization domain, other than "find the > organizational domain". The current text says (in many more words), take a list of public suffixes, find the longest match, and the Org domain is one below that match. If we consider the Org domain to be found via a list of public registration points, that won't change. We might change where the list comes from, and perhaps some hackery like my DNS wildcards to make the implementation of the search faster. This tells me the separate document is on the order of one sentence saying where the list is. The other alternative is forget public suffixes and walk up the tree until you find a _dmarc record or you hit the root. That has a lot of advantages: it's easy to describe, everyone gets the same answer, and Scott automatically gets his superdomain check. I believe the main argument against it is that the DNS crowd has has been allergic to tree walks, but the cost of potentially malicious tree walk names like a.b.c ... x.y.z.example.com is not a big deal any more since RFC 8020. If you mean that we would punt a potential change this large into a different document, that seems like a stretch. 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 Nov 11 08:55:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728503A09C9 for ; Wed, 11 Nov 2020 08:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bbiw.net header.b=v+kqF18U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rhxKWzb8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8e2wMPb8ogg for ; Wed, 11 Nov 2020 08:55:10 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F07B3A0978 for ; Wed, 11 Nov 2020 08:55:10 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9CDF25C016D; Wed, 11 Nov 2020 11:55:09 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 11 Nov 2020 11:55:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbiw.net; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=Y R1H4rMxL37phmX3SGfs4MHUOxk3LrE1KX8OLJqYWgI=; b=v+kqF18UhygUNZCqx guz+HPYu42AzTabcBH8ymCLA3f41h/ZnRprRLHEpKC12g4MJS60dBnqhsusWLXRL fJieC9LflNWgbEpC6B/jK1kbANFAcvhHKpWEyEH3Ary+ow/2TgDizeSKlYct0sl0 XqAgZ6WQhoqnZ7h/FZ0DrMhO9eA1EUtXZp5SxnuOt4W4SAsNZo2+wqPLH1OgIIlL TVOefARb1DuFNi5qASuIHYCvxRc0jb628SpaWk+RYk+qNem4u3VHkyA+gGe8dLP7 SXd5jPoZVRxSQ0HB1qhGFfROqFgBcy4qOkeZsdPww6IHEhqxn3RrOZkhh0F2//iT UCqOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=YR1H4rMxL37phmX3SGfs4MHUOxk3LrE1KX8OLJqYW gI=; b=rhxKWzb8MUd1bguAVFaFlGHPTCFdtUa0lPK9t6GkaE9rXzkhrOEKQJqa0 C491/xRBlt75PLv0RnWH2MTvdc+n/zqLn4b44Fw/1Bqh9scD17rwrySQ4Ac4Grxd dhrAxLfYUOT5kBhVVaxwZWv2fBBCUvr87My73mDBip4goZCi/HIW2ShEe4EBk4yR UFHgNw8E5G2QGZHJz82kbCEUHIW8kuOLgj6YJNWfkcafRktletvi4h9eSjCaawTM KaNWBvGd9lEddHCSbP5fXgWcHB10WL0CmAu0WgcoHef8I41iNXmaiOuvIMNaXgX7 d/V6TnaE3tq11lJ5tkLXk/NOpKAhw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvtddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeffrghv vgcuvehrohgtkhgvrhcuoegutghrohgtkhgvrhessggsihifrdhnvghtqeenucggtffrrg htthgvrhhnpeeihfdvuefgjeekffdthfelveelteevfeegteefgeetjeejudejueegheef hefgieenucffohhmrghinhepsggsihifrdhnvghtnecukfhppedvgedrudeftddriedvrd dukedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep uggtrhhotghkvghrsegssghifidrnhgvth X-ME-Proxy: Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) by mail.messagingengine.com (Postfix) with ESMTPA id EA9723063080; Wed, 11 Nov 2020 11:55:08 -0500 (EST) To: John R Levine , dmarc@ietf.org References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <7a8c0466-3ad7-4b16-29d2-abed45df81bf@bbiw.net> Date: Wed, 11 Nov 2020 08:55:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 16:55:11 -0000 On 11/11/2020 8:50 AM, John R Levine wrote: > The current text says (in many more words), take a list of public > suffixes, ... > If you mean that we would punt a potential change this large into a > different document, that seems like a stretch. It's not. The entire topic is a mess. In pretty much every possible way. Even reliance on the construct of 'public suffix' is problematic. (cf, .google, etc.) So, DMARC should punt the entire topic. It should have some text, along the lines of: Find the Organizational Domain. The means of finding the Organizational Domain are outside the scope of this specification. Full Stop. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 08:58:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD423A09D4 for ; Wed, 11 Nov 2020 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=jH/5KkxV; dkim=pass (2048-bit key) header.d=taugh.com header.b=heYnxgi7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KX-YOTKY8vd for ; Wed, 11 Nov 2020 08:58:48 -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 2EC4E3A0FD9 for ; Wed, 11 Nov 2020 08:58:47 -0800 (PST) Received: (qmail 78133 invoked from network); 11 Nov 2020 16:58:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=13132.5fac1847.k2011; i=johnl-iecc.com@submit.iecc.com; bh=nU8SZelDyA/YbTXgS/0ZrcORzDdWX/8i02u/Xualqis=; b=jH/5KkxVlphJWwRZOIxcowpXFKOw71kCw1yyp/b+FXyr7Z5X/7Hw9WRHAzvKQBdOf0NnQNhwAXZweR5XcCFWRt0Hv6q3h53GnWmqQGcpesZ4P4WCvptd4AA8sB1QGFdYrJ9qo//iBLtbFY/mOWfP4xzeWHYFLqez+dL09POa4CmyW+OIBG/bL7meykgeFq305fXoXU6XS6h2SiGf6DQv56SerCVQ5G3TCpfEmlwHk/ioK75RMcOXltihCZQrBIWO4bTSfgkE5b1KBMLgcOpv0EtUC3axsjWlhYrGo0d66c/ia0MDXH0jlQPTpxNUqw+EeR2BDHFD1I5bj93q1jcCnA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=13132.5fac1847.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=nU8SZelDyA/YbTXgS/0ZrcORzDdWX/8i02u/Xualqis=; b=heYnxgi7Dt4Fn2eHABAeMGeyRRL0WeBMPNpY5d1aFAS0BlAfCjRwLvIL1OaQCgmqE9GdcaV3kqjn43cAC0ojlMWq1iolvcDHs+OXTlTtyR/gPTFCH7r9C5JN1h4veiZHe/J37ZujaCpWKTPOROg1wS4vLOaAd08OZo5gVNkSajRNsVXZzMBkwrBItWX6MNOTrTu7BEEAdoATFGR6COMqgxTvHWvX3GUEoxALAgfe82QjZv+g0NnsuYnc3tdAMlj/avcSUMfSWAM2S+NN9IAKmwSOD7EI1eT+CGHpl4Ct3qRQEKU/HxiVs0hnpYFIUjGWuMY2aZvd0PtaAnQPC62QRA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 11 Nov 2020 16:58:46 -0000 Date: 11 Nov 2020 11:58:46 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: <7a8c0466-3ad7-4b16-29d2-abed45df81bf@bbiw.net> References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> <7a8c0466-3ad7-4b16-29d2-abed45df81bf@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 16:58:50 -0000 On Wed, 11 Nov 2020, Dave Crocker wrote: > So, DMARC should punt the entire topic. It should have some text, along the > lines of: > > Find the Organizational Domain. The means of finding the Organizational > Domain are outside the scope of this specification. Except that if we do a tree walk, I don't think we'd call that the Organizational Domain any more. 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 Nov 11 09:00:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9983A005F for ; Wed, 11 Nov 2020 09:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uKPIhvIHe_4 for ; Wed, 11 Nov 2020 09:00:01 -0800 (PST) Received: from mail-vs1-xe44.google.com (mail-vs1-xe44.google.com [IPv6:2607:f8b0:4864:20::e44]) (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 BC7F43A1246 for ; Wed, 11 Nov 2020 08:59:11 -0800 (PST) Received: by mail-vs1-xe44.google.com with SMTP id u24so1533081vsl.9 for ; Wed, 11 Nov 2020 08:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a427RBJiMvj/LhOu9MRPnV/HMV/GhTDrYy5Yu4vgUB0=; b=YcYygmd/KNyzQVICAwQgd5cqY+bHpojF3Y5BlgXkB7/LJUTkVj+eyri9nuritNJ1o6 FRrQPQSs4obieMqxTWhuWa6McU/AccaPueLfp40JTWuOLkHICmKznPMxEME2p3Bu58OF t7P0zFCKg+IBU2gPcrhk8hF1cgIh2fQ/bofDD1RG64Ny/C13hsno24asqP/G9/idKHkX 858wZoRLUYpBUh9gYMdHX7TosSE11P9b/0aEd0IYCTUXJw7zSacya4IxwTiXtK8zMDRJ zVlHawUs+HQYeUaJag+IwsfzrxBYcOBxjb9Ul8PTAjCfGML0mnvPrRwD8StdNnam+Q/P /z+A== 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=a427RBJiMvj/LhOu9MRPnV/HMV/GhTDrYy5Yu4vgUB0=; b=RBUTWgCxESoZnf2Kd28tRyAVwVH/WYiWFXmEcRaW1i//BNZk8wXBpWX5LU561I7VFU gIPyVB9rtDUaVEykpI+lpxdxhYo+AM+wR6FezKqOqHDBxCy2MtWuM1C+tT9uEEpXRToF NdzJBuTce0+a2PwvOJ1indIQB2Uosgz8krijYYk85GPFJaZtv/JlcDqdQXi9yR+hljse Mt9J98L9kpLxxarnfOZGsOpS/ZKgasW/am9mzRmyZT9Y5IX9i4fVqEzicT+S7JbQEHz3 xcvSaECmX2RanX9PSDB2Gzb0lHzQuU3MIjbKJYx3io7IiUGnG/A/h1sz74JVbgJ6oWNX FzoQ== X-Gm-Message-State: AOAM533hIBpuSRsAPripbCtVXW5upfofysu5qzeOOSQ22YkKhTaVWus9 6yu+8/2WPO+Kndd4y0tBzo/yvDt//DJxU8Vkr3FR6DHM X-Google-Smtp-Source: ABdhPJyp1D48EmrzIWPCVgK7ssjkmJToEQCwspV0p1DfxJvGu5kotkRVMckFa6A8ZsibXyqcmdJm65YnKwgmBEIklYU= X-Received: by 2002:a67:ec10:: with SMTP id d16mr16174148vso.33.1605113950672; Wed, 11 Nov 2020 08:59:10 -0800 (PST) MIME-Version: 1.0 References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> In-Reply-To: <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> From: "Murray S. Kucherawy" Date: Wed, 11 Nov 2020 08:58:59 -0800 Message-ID: To: John R Levine Cc: Dave Crocker , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000da9bda05b3d7b6ba" Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 17:00:04 -0000 --000000000000da9bda05b3d7b6ba Content-Type: text/plain; charset="UTF-8" On Wed, Nov 11, 2020 at 8:52 AM John R Levine wrote: > The current text says (in many more words), take a list of public > suffixes, find the longest match, and the Org domain is one below that > match. If we consider the Org domain to be found via a list of public > registration points, that won't change. We might change where the list > comes from, and perhaps some hackery like my DNS wildcards to make the > implementation of the search faster. This tells me the separate document > is on the order of one sentence saying where the list is. > > The other alternative is forget public suffixes and walk up the tree until > you find a _dmarc record or you hit the root. That has a lot of > advantages: it's easy to describe, everyone gets the same answer, and > Scott automatically gets his superdomain check. I believe the main > argument against it is that the DNS crowd has has been allergic to tree > walks, but the cost of potentially malicious tree walk names like > a.b.c ... x.y.z.example.com is not a big deal any more since RFC 8020. > > If you mean that we would punt a potential change this large into a > different document, that seems like a stretch. > The proposal is, I think, to change the main document to leave a pointer, and the pointer can be changed much more easily than the actual method. So the new DMARC document would say: "Determine the Organizational Domain. The legacy way to do this can be found in [other-RFC], but other better methods are anticipated." Then when something better than PSL (maybe a tree walk, maybe something else) comes along, the IETF publishes that specification and DMARC implementations and operators switch to that method. The base document doesn't need to change at all. -MSK --000000000000da9bda05b3d7b6ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current text says (in many more words), take a list of publi= c
suffixes, find the longest match, and the Org domain is one below that
match.=C2=A0 If we consider the Org domain to be found via a list of public=
registration points, that won't change.=C2=A0 We might change where the= list
comes from, and perhaps some hackery like my DNS wildcards to make the
implementation of the search faster.=C2=A0 This tells me the separate docum= ent
is on the order of one sentence saying where the list is.

The other alternative is forget public suffixes and walk up the tree until =
you find a _dmarc record or you hit the root.=C2=A0 That has a lot of
advantages: it's easy to describe, everyone gets the same answer, and <= br> Scott automatically gets his superdomain check.=C2=A0 I believe the main argument against it is that the DNS crowd has has been allergic to tree walks, but the cost of potentially malicious tree walk names like
a.b.c ...=C2=A0 x.y.z.example.com is not a big deal any more since RFC 8= 020.

If you mean that we would punt a potential change this large into a
different document, that seems like a stretch.

The proposal is, I think, to change the main document to leave a po= inter, and the pointer can be changed much more easily than the actual meth= od.=C2=A0 So the new DMARC document would say: "Determine the Organiza= tional Domain.=C2=A0 The legacy way to do this can be found in [other-RFC],= but other better methods are anticipated."=C2=A0 Then when something = better than PSL (maybe a tree walk, maybe something else) comes along, the = IETF publishes that specification and DMARC implementations and operators s= witch to that method.=C2=A0 The base document doesn't need to change at= all.

-MSK
--000000000000da9bda05b3d7b6ba-- From nobody Wed Nov 11 09:02:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2703A1628 for ; Wed, 11 Nov 2020 09:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSnsFmoU2bwy for ; Wed, 11 Nov 2020 09:02:38 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888CD3A13FE for ; Wed, 11 Nov 2020 09:01:51 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id u24so1539114vsl.9 for ; Wed, 11 Nov 2020 09:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WT4oU2Go/maAYLSO631paEgEvcs88zvYCW67Fiu2upA=; b=BrCZZKgePyjMv1dc1L7IbLpfwmjuP536Zd4z6FwASCLIQmo4eSyVQv0K/RjEq+P1YL gqTAjQoMbWstgCR7yTk+Dhixk3SYR0oDSAUZeyCRkWl/kQEKV8CmPQySARr/L3cHIUNh bSWhhXbAeJpkP+YiwJ9ggsZLNOfY1SZNlh5WiJtl8QG6gewDP3iOL9L7eg2SgqHCJRO1 PiBQ3xJpJ7fxlMarIEXiz4RAs8yr3olZnZXYTMPOiiGA1WKlEoYogC0v08zW8TH4NTpx UKMMYKBwPST0uLoLEuVLrOxKSfTLMySdUoa6AMn8xxsTf5PmjiScP/HoFBz0o1HdE0HH /4/g== 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=WT4oU2Go/maAYLSO631paEgEvcs88zvYCW67Fiu2upA=; b=W/kZXhTSzxgSiJmEa6vAdxHaI9JOGsSd1J6BoUstxhR/PIHJB4qOz/6bytPw2ATwpm T8afH6JZ+zRdN7j6L/CxqCVVZnqNc9WtbHzTwoYCpLFMTKjUvGSeWgg/3v7V+qtQ+e4D zp51XYDFOjRaLpDEA3imlQkxK/uWO9TDezTufLV3benhYPcDSAr01dfR9DsiBPovOyDL leTWjWoYrIcbnwmyeoDUXtqXiV8J1lZRfxJ3rRWVa6GiSKrZXJLthDeCyovfCUy07ca4 N1u8KGnuq25sPDTnF79+fh77Cxs+mOWld6cPU+j43eJ+cM6RfR7KMHHLFoqqdwL2mkmX KEHg== X-Gm-Message-State: AOAM531udFrlwlji37Nx9NBbm8qWlTQGO/JC2fIz9D1eLnIbW3eRiz2c M95NNcWA8T1SdFA3MHUvB8j3cUgHfvbNM7ji/3Ysj6T6 X-Google-Smtp-Source: ABdhPJyCvdNkhCEEXDjJoIWIFdMkGS26qtBIjFZ5ih8po3S/LBfOf9lCRbjN9wZJtXmif/b1kbrXd9Jyg2vi63a1a0g= X-Received: by 2002:a67:783:: with SMTP id 125mr6050922vsh.15.1605114110574; Wed, 11 Nov 2020 09:01:50 -0800 (PST) MIME-Version: 1.0 References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <840755cdaa0646468adf79604ce051b7@bayviewphysicians.com> In-Reply-To: <840755cdaa0646468adf79604ce051b7@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Wed, 11 Nov 2020 09:01:39 -0800 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000062855d05b3d7c0aa" Archived-At: Subject: Re: [dmarc-ietf] On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 17:02:46 -0000 --00000000000062855d05b3d7c0aa Content-Type: text/plain; charset="UTF-8" On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster wrote: > Can we eliminate the PSL problem simply by adding some DNS queries? > > Isn't there a maximum depth to the PSL, so that the evaluator can simply > walk up the top N levels of the domain tree to find either an > organizational DMARC entry with sp= or a PSD DMARC entry with sp=? It > looks like currently, n=4, because the published suffixes appear to extend > to 3 levels. > That's been proposed, and I think it's a future topic for this WG. (A ticket might be open about it already.) As John just said in another thread, the DNS crowd has been largely allergic to the notion of a tree walk in the past, but the last time this was given serious consideration was when DKIM was young (2007) and it might be ripe for revisiting now. It certainly would make our lives simpler. -MSK --00000000000062855d05b3d7c0aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 11, 2020 at 6:01 AM Douglas E= . Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
Can we eliminate the PSL p= roblem simply by adding some DNS queries?

Isn'= t there a maximum depth to the PSL, so that the evaluator can simply walk u= p the top N levels of the domain tree to find either an organizational DMAR= C entry with sp=3D or a PSD DMARC entry with sp=3D? =C2=A0 It looks like cu= rrently, n=3D4, because the published suffixes appear to extend to 3 levels= .

That's been proposed, and= I think it's a future topic for this WG.=C2=A0 (A ticket might be open= about it already.)

As John just said in another t= hread, the DNS crowd has been largely allergic to the notion of a tree walk= in the past, but the last time this was given serious consideration was wh= en DKIM was young (2007) and it might be ripe for revisiting now.=C2=A0 It = certainly would make our lives simpler.

-MSK
--00000000000062855d05b3d7c0aa-- From nobody Wed Nov 11 10:02:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A353A4152 for ; Wed, 11 Nov 2020 09:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FSrRuLNGOow for ; Wed, 11 Nov 2020 09:51:35 -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 4A6133A4157 for ; Wed, 11 Nov 2020 09:35:35 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ABHd4wU016069 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 11 Nov 2020 09:39:04 -0800 From: Dave Crocker To: dmarc@ietf.org References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 11 Nov 2020 09:35:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 17:51:43 -0000 On 11/11/2020 8:50 AM, John R Levine wrote: > The current text says (in many more words), take a list of public > suffixes, ... > If you mean that we would punt a potential change this large into a > different document, that seems like a stretch. It's not. The entire topic is a mess. In pretty much every possible way. Even reliance on the construct of 'public suffix' is problematic. (cf, .google, etc.) So, DMARC should punt the entire topic. It should have some text, along the lines of: Find the Organizational Domain. The means of finding the Organizational Domain are outside the scope of this specification. Full Stop. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 10:05:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66613A1724 for ; Wed, 11 Nov 2020 10:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC8h3RihdHOD for ; Wed, 11 Nov 2020 10:05:35 -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 C69B93A4509 for ; Wed, 11 Nov 2020 09:38:46 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ABHgGel016470 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 11 Nov 2020 09:42:16 -0800 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 11 Nov 2020 09:38:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 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] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:05:38 -0000 On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: > The proposal is, I think, to change the main document to leave a > pointer, and the pointer can be changed much more easily than the actual > method.  So the new DMARC document would say: "Determine the > Organizational Domain.  The legacy way to do this can be found in > [other-RFC], but other better methods are anticipated." wfm. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 10:09:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04B3A0BA1 for ; Wed, 11 Nov 2020 10:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-w8F1ycx1vf for ; Wed, 11 Nov 2020 10:09:11 -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 295293A24A3 for ; Wed, 11 Nov 2020 09:37:37 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ABHf6Rr016332 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 11 Nov 2020 09:41:06 -0800 Reply-To: dcrocker@bbiw.net To: John R Levine , dmarc@ietf.org References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> <7a8c0466-3ad7-4b16-29d2-abed45df81bf@bbiw.net> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <03758d8d-a4d7-3f9d-bc0c-3ee404fc53d1@dcrocker.net> Date: Wed, 11 Nov 2020 09:37:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 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] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:09:13 -0000 On 11/11/2020 8:58 AM, John R Levine wrote: > Except that if we do a tree walk, I don't think we'd call that the > Organizational Domain any more. What would you call it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 10:18:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53BD3A07DE for ; Wed, 11 Nov 2020 10:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=UMLmAa5M; dkim=pass (2048-bit key) header.d=taugh.com header.b=ODxWFFcK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSSRb8goC0ER for ; Wed, 11 Nov 2020 10:18:39 -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 646D13A07DB for ; Wed, 11 Nov 2020 10:18:39 -0800 (PST) Received: (qmail 7750 invoked from network); 11 Nov 2020 18:18:38 -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:cleverness; s=1e44.5fac2afe.k2011; bh=P5rzJZR3riES2+sDFKeTxIyGgULGUmlLSwMe6YqRjN4=; b=UMLmAa5MPueRESti2tIqszDHKh54hRkW9AWJ6BLQKIe03Yszy/T9J5hLENZU5kyUvuPGKigqJ86NwxkQDVjFBqlOPKBHgess7naAsriKS1YxQF/Q2s1sk2lgUV38JOxUlNPnjmfe4A+rFZw62XGA5ZYvmYZOYI4+TZ0rTGdEZAk3DoaP+MG4i3WGIKBLpkM2AnqaweBuZmPU/4EOq55FV72f1Uw8q0GeceCSZ1VyYN+mWGUgi/SvXEKvKvl6irI0DLgFJy0jeqgT0QxNVO9ZhYACsRDjjMGiybQUtZT9DIxwr+w/5KDCCRze7A0kY2pWlnUwm29G0hZrciGmLxukIQ== 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:cleverness; s=1e44.5fac2afe.k2011; bh=P5rzJZR3riES2+sDFKeTxIyGgULGUmlLSwMe6YqRjN4=; b=ODxWFFcKi7iWHEgF3gLMlWPeqb5HazDS138hCnKDHMsFAhi1zKYWg/1JHwdWvVmvTHf+ntMJnnWImzswwbyIUtULwIP8z52TW1lbJz2+qyNweIJOVETLQtPf6j5kTi0+yp9TDbaaMpk2/7kQrdc0tVaj88/34khletu5qZzcZTIsqpf0YDlTZ+DUpuOgrNPqJkjQ7SMR42I6gccOCaD7aPqvf3gZTQapWp119GcCTy2ugctVxgf46VLZ0ri2C3k678wOMMAMFGUasHfyKgcrDSjvKG1VCmNHm25wj4oFZbbOoyhzPKLGKqPqtlfYwwc0j0K+1JOz2iKKyqZHRb5W7w== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 11 Nov 2020 18:18:37 -0000 Received: by ary.qy (Postfix, from userid 501) id 79128262943F; Wed, 11 Nov 2020 13:18:37 -0500 (EST) Date: 11 Nov 2020 13:18:37 -0500 Message-Id: <20201111181837.79128262943F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <03758d8d-a4d7-3f9d-bc0c-3ee404fc53d1@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:18:41 -0000 In article <03758d8d-a4d7-3f9d-bc0c-3ee404fc53d1@dcrocker.net> you write: >On 11/11/2020 8:58 AM, John R Levine wrote: >> Except that if we do a tree walk, I don't think we'd call that the >> Organizational Domain any more. > >What would you call it? "Parent default" or something like that. There's no claim that it is or isn't in the same organization, just that it's a parent name of the target name. For Scott's _dmarc.BANK. thing it would deliberately *not* be the same organization. R's, John From nobody Wed Nov 11 10:24:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35833A0836 for ; Wed, 11 Nov 2020 10:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK1FH9qjYYkc for ; Wed, 11 Nov 2020 10:24:49 -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 1C19F3A07DE for ; Wed, 11 Nov 2020 10:24:49 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ABISIgL023074 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 11 Nov 2020 10:28:18 -0800 Reply-To: dcrocker@bbiw.net To: John Levine , dmarc@ietf.org References: <20201111181837.79128262943F@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 11 Nov 2020 10:24:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <20201111181837.79128262943F@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] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:24:50 -0000 On 11/11/2020 10:18 AM, John Levine wrote: > "Parent default" or something like that. There's no claim that it is > or isn't in the same organization, just that it's a parent name of the > target name. > > For Scott's _dmarc.BANK. thing it would deliberately*not* be the same organization. Where is such generality discussed in DMARC? I don't recall seeing it. DMARC has had a consistent construct, which is 'the domain name that is at the top of the organization's administrative hierarchy". Hence, Organizational Domain. Nothing in the term requires that it be up the 'current' domain name chain. ] "Parent default" is an example of a more generic term that actually has the same meaning, but less intuitive. For one thing, it's likely to be quite a bit higher than the parent domain name. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 10:31:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB383A0957 for ; Wed, 11 Nov 2020 10:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16c14Npf7Epd for ; Wed, 11 Nov 2020 10:31:47 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D42D3A08AB for ; Wed, 11 Nov 2020 10:31:46 -0800 (PST) X-ASG-Debug-ID: 1605119505-11fa3148025cc70001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 7vLkswtSon3d7A7D (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 11 Nov 2020 13:31:45 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=qZel0m+wgx768ZKBuaFZpbN0E6Sl40gN8tQcBtVSpfA=; b=hguoGbLGg52jcfjP+4T7/ge60AB1Tbq3wJnJ8b6C3J7XRQzzNiwLLmz6hGru/o0gM a8D8laPzlly2WG+QzbrfK533aOov8mEHk5gICe8lSYBwKp3Owm1zz55spx54stOdK yDAmcQEqTggfpQKtwteWwk4q9w4IEP9qxp5w+5l4Y= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 11 Nov 2020 13:31:37 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF DMARC WG'" References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <840755cdaa0646468adf79604ce051b7@bayviewphysicians.com> In-Reply-To: Date: Wed, 11 Nov 2020 13:31:37 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] On splitting documents and DBOUND Message-ID: <001201d6b858$e3dc8080$ab958180$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01D6B82E.FB0714C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIzPWX+bs5p0Kx9f1TonY28ybGMiAHybP8RAWAxjk4CB8VZi6jfYgLA Content-Language: en-us X-Exim-Id: 001201d6b858$e3dc8080$ab958180$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605119505 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 7051 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85805 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:31:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01D6B82E.FB0714C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I was trying to address the tree walk objections and denial-of-service = objections by starting at the upper end of the tree, so that an = evaluator cannot be tricked into trying 100 possibilities for a single = email message. =20 An additional protection would be to specify a few TLDs, (particularly = .COM. .EDU, .NET, and .ORG) which will never be used for PSD DMARC = entries, so an implementer MUST NOT look for a DMARC entry there. = Those TLDS would be the ones at most risk of performance problems if = saturated by a DMARC TXT lookups during tree walk. A short = don=E2=80=99t-look-here list is much more sustainable than what we have = right now. =20 DF =20 From: Murray S. Kucherawy [mailto:superuser@gmail.com]=20 Sent: Wednesday, November 11, 2020 12:02 PM To: Doug Foster Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] On splitting documents and DBOUND =20 On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster = wrote: Can we eliminate the PSL problem simply by adding some DNS queries? =20 Isn't there a maximum depth to the PSL, so that the evaluator can simply = walk up the top N levels of the domain tree to find either an = organizational DMARC entry with sp=3D or a PSD DMARC entry with sp=3D? = It looks like currently, n=3D4, because the published suffixes appear to = extend to 3 levels. =20 That's been proposed, and I think it's a future topic for this WG. (A = ticket might be open about it already.) =20 As John just said in another thread, the DNS crowd has been largely = allergic to the notion of a tree walk in the past, but the last time = this was given serious consideration was when DKIM was young (2007) and = it might be ripe for revisiting now. It certainly would make our lives = simpler. =20 -MSK ------=_NextPart_000_0013_01D6B82E.FB0714C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I was trying to address the tree walk objections and = denial-of-service objections by starting at the upper end of the tree, = so that an evaluator cannot be tricked into trying 100 possibilities for = a single email message.

 

An additional protection would be to specify a few TLDs, = (particularly .COM. =C2=A0.EDU, .NET, and .ORG) which will never be used = for PSD DMARC entries, so an implementer MUST NOT look for a DMARC entry = there.=C2=A0=C2=A0=C2=A0 Those TLDS would be the ones at most risk of = performance problems if saturated by a DMARC TXT lookups during tree = walk.=C2=A0=C2=A0 A short don=E2=80=99t-look-here list is much more = sustainable than what we have right now.

 

DF

 

From:= = Murray S. Kucherawy [mailto:superuser@gmail.com]
Sent: = Wednesday, November 11, 2020 12:02 PM
To: Doug = Foster
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] = On splitting documents and DBOUND

 

On = Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster <fosterd=3D40bayviewphysician= s.com@dmarc.ietf.org> wrote:

Can we = eliminate the PSL problem simply by adding some DNS = queries?

 

Isn't there = a maximum depth to the PSL, so that the evaluator can simply walk up the = top N levels of the domain tree to find either an organizational DMARC = entry with sp=3D or a PSD DMARC entry with sp=3D?   It looks like = currently, n=3D4, because the published suffixes appear to extend to 3 = levels.

 

That's been proposed, and I think it's a future topic = for this WG.  (A ticket might be open about it = already.)

 

As John just said in another thread, the DNS crowd has = been largely allergic to the notion of a tree walk in the past, but the = last time this was given serious consideration was when DKIM was young = (2007) and it might be ripe for revisiting now.  It certainly would = make our lives simpler.

 

-MSK

------=_NextPart_000_0013_01D6B82E.FB0714C0-- From nobody Wed Nov 11 10:54:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B89E3A0D22 for ; Wed, 11 Nov 2020 10:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xx46AnxcmRv for ; Wed, 11 Nov 2020 10:54:09 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 0F0353A0D20 for ; Wed, 11 Nov 2020 10:54:08 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id m16so1749124vsl.8 for ; Wed, 11 Nov 2020 10:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ujUNiUrYh+xrfI0COOmnFdrYrZDi53f2Nbncn/Fk8E=; b=FiIh4n6WYU4aJkJva6u54+BmU+xgPxZWtEvsAwq1Y3aTg/VfhAEl4Zrd7pMwcod+u6 LecX5RN0zRjXnR0hzm19Lf3UjP0ELYJNntV+Fvp+eBOuEPSz0AZ8gvANYrb+xQquSkns mCxm1Cp7kiBA9Ei9elDgS5bsAVKhg3JSPLNpvljvuzvNQeHQHMWMo5K7Zbf2JTzFWrNS aSN+1gECy0HMO1xT0mePgzeVVf3OQ90ihfPA+BwiexLq4lAeBqrOZ4UB/6ivImD44vlC 7G3ivIu8SDG2+Qx7Q6yn0NUHeudgju79CeqBOpUagxDXxbCR/9luZflSdqYy/CA5hgBO 1fBA== 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=0ujUNiUrYh+xrfI0COOmnFdrYrZDi53f2Nbncn/Fk8E=; b=uOE/XAnGH0yNZNp7cKd7Ke6JKDJAQN+cl7eNEb1dTFSF9V8Dyx2R+Khz5jSwvmpikp CTP+d4Prg/aD4ai8fyqtLvZUjf3LMNtUYEgQYCow1T6lnKsrxsoWgRq8VdZkrARrtdx6 3PnZq8jqqdJ1/PVEwDQKX3Mr9Bgu8MAvQt//zBzNIBFHJL1BUXtIdg5sVUiKxOQWWWOb NNs2vRkiFcMJVC/BK9JeNDTgLUX66eC8/RA/9Z9Yksb4+E5cp5/A4drtuNJ2C0YN2IDV KgCTsxLHntUw8s1B75kT2mOeiWX/hTGnwynKwVTerqPJJ32t/AasF/CWU+UHx4VC8SFD 2nIQ== X-Gm-Message-State: AOAM531gtYoqbUJn/gXN8aI0BKhXJNvMq8MGwhnbGF8ZGvFm/NJufka8 vUSf/EY9dvzTMzjxb/7joCQHz9COPgNo84hk5RX01kAdYME4qg== X-Google-Smtp-Source: ABdhPJxnLh5jmnhWlX5VkyKhqm00LyS+8zefGM5LbGNXW9tmDSfEHC6jvhxgSxRTbMmIYe5WlV5Lb7TcQFObOoWwUW0= X-Received: by 2002:a67:d84:: with SMTP id 126mr17192966vsn.43.1605120847563; Wed, 11 Nov 2020 10:54:07 -0800 (PST) MIME-Version: 1.0 References: <20201111181837.79128262943F@ary.qy> In-Reply-To: From: Seth Blank Date: Wed, 11 Nov 2020 10:53:56 -0800 Message-ID: To: IETF DMARC WG Cc: Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000f0e40b05b3d951d5" Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:54:11 -0000 --000000000000f0e40b05b3d951d5 Content-Type: text/plain; charset="UTF-8" I believe the core of this is referenced in https://trac.ietf.org/trac/dmarc/ticket/68 and can be discussed in detail when the chairs or relevant editors open that ticket. The further discussion seems to be if "org domain" (or whatever new name its given) definition and discovery mechanism should live in a separate I-D, and DMARC should simply reference this for discovery purposes. If we believe a new document is in order, we'll need an editor. I believe Scott Kitterman expressed interest in this previously, and it's also a natural extension of some of the work he's already done with PSD. Is anyone interested in volunteering to be an editor for this draft and bringing an -00 to the group? Seth, as co-Chair On Wed, Nov 11, 2020 at 10:25 AM Dave Crocker wrote: > On 11/11/2020 10:18 AM, John Levine wrote: > > "Parent default" or something like that. There's no claim that it is > > or isn't in the same organization, just that it's a parent name of the > > target name. > > > > For Scott's _dmarc.BANK. thing it would deliberately*not* be the same > organization. > > > Where is such generality discussed in DMARC? I don't recall seeing it. > > DMARC has had a consistent construct, which is 'the domain name that is > at the top of the organization's administrative hierarchy". Hence, > Organizational Domain. Nothing in the term requires that it be up the > 'current' domain name chain. > ] > "Parent default" is an example of a more generic term that actually has > the same meaning, but less intuitive. For one thing, it's likely to be > quite a bit higher than the parent domain name. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000f0e40b05b3d951d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the core of this is referenced in https://trac.ietf.org/trac/= dmarc/ticket/68 and can be discussed in detail when the chairs or relev= ant editors open that ticket.

The further disc= ussion seems to be if "org domain" (or whatever new name its give= n) definition and discovery mechanism should live in a separate I-D, and DM= ARC should simply reference this for discovery purposes.

If we believe a new document is in order, we'll need an editor. = I believe Scott Kitterman expressed interest in this previously, and it'= ;s also a natural extension of some of the work he's already done with = PSD.

Is anyone interested in volunteering to be an= editor for this draft and bringing an -00 to the group?

Seth, as co-Chair

On Wed, Nov 11, 2020 at 10:25 AM Dave Crocker= <dhc@dcrocker.net> wrote:
On 11/11/2020 10:1= 8 AM, John Levine wrote:
> "Parent default" or something like that. There's no clai= m that it is
> or isn't in the same organization, just that it's a parent nam= e of the
> target name.
>
> For Scott's _dmarc.BANK. thing it would deliberately*not*=C2=A0 be= the same organization.


Where is such generality discussed in DMARC?=C2=A0 I don't recall seein= g it.

DMARC has had a consistent construct, which is 'the domain name that is=
at the top of the organization's administrative hierarchy".=C2=A0 = Hence,
Organizational Domain.=C2=A0 Nothing in the term requires that it be up the=
'current' domain name chain.
]
"Parent default" is an example of a more generic term that actual= ly has
the same meaning, but less intuitive.=C2=A0 For one thing, it's likely = to be
quite a bit higher than the parent domain name.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion intended solely for the use of individual(s) authorized to receive it. = If you are not an intended and authorized recipient you are hereby notified= of any use, disclosure, copying or distribution of the information include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--000000000000f0e40b05b3d951d5-- From nobody Wed Nov 11 10:58:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5883A0D22 for ; Wed, 11 Nov 2020 10:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EurUmQFT7dUd for ; Wed, 11 Nov 2020 10:58:10 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701213A0A4F for ; Wed, 11 Nov 2020 10:58:10 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id v9so1021894uar.11 for ; Wed, 11 Nov 2020 10:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8Z5lzp1zz33b4x5Zq7bGjKLwwUgl4sTQelWRqBgTtvY=; b=Zf9rSQuclxtYZr3V6th+h+TWGZsQ1lG+l9e0gqwFYvhyUx6QLgO0oW5LgBW431r6px 2svs2qcfo/ZroSupFphLCAGqSuOtKY9o1/tbDWxCrdOMgBD4ADD4tqoW/HszchiwG0Td FuRv7KbIX7tbn86azXDjwnWy6oW56vpb60sMD4jXIxGn90I/wXQq4pA7od9hIFejUvxh suUS79qzqJ9+tnR2W1LOliTNOUcNt/5sBFHDBi9CmlZjl5tnFfAQCJ9DC9nbNr/m/TYf ezU6+rycvrx+YdkGlHHQYpNmTZ/Lo164GNKjLJ6PYxtvafnMkGTW/XuiKUzHDpyMCdLf EwVQ== 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=8Z5lzp1zz33b4x5Zq7bGjKLwwUgl4sTQelWRqBgTtvY=; b=J6K1Jjev/28llL24uecmdvWxmUMQgAoFGGoJyYzenVq7SvcefRQCQ6mbbUOke89Dqt EEbFSMezCFDjhbgqqK0myDO/iuC8/yzmpLtH09lCkyFs9GA5I8vZd8U8uHTryH/lXWCt s+P0HZcn52/yEDijQcK0Q4dfs5B1cHx7om5XCgsWDumhktwAZwgB47HJk0i2CLfCPNwt 9+9X2+jGw3KZDLfxg20Jz4r5ld/eajvPTt+LzMuefHnLKlG8s4aZKky1hF96F21pZOvg XyAQfxQMg2beXDulANjL9Hgo67OO+97LQjXnwtqPk74eYFCJlcZITgr1eOtb5zHbfLEX 0TNg== X-Gm-Message-State: AOAM531e/BdGItb5e/ek0JgOsylE1wtyxI6yxOY35YmKYT7/Th6A7OZl bD5WQbIQeTfot/VTaKgXZESpfd9KNrtxJ6TYEndzIahBQeg= X-Google-Smtp-Source: ABdhPJxEO69z+54QDcsMrJl/YBaBzag4xpxWPhrcih43ZgNKd6Nm+3kNiUv87mN/rADTSJx68c6/XIQyrwQm5WDyx90= X-Received: by 2002:a9f:264a:: with SMTP id 68mr14452417uag.0.1605121088952; Wed, 11 Nov 2020 10:58:08 -0800 (PST) MIME-Version: 1.0 References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <840755cdaa0646468adf79604ce051b7@bayviewphysicians.com> <001201d6b858$e3dc8080$ab958180$@bayviewphysicians.com> In-Reply-To: <001201d6b858$e3dc8080$ab958180$@bayviewphysicians.com> From: Seth Blank Date: Wed, 11 Nov 2020 10:57:57 -0800 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000054334605b3d96026" Archived-At: Subject: Re: [dmarc-ietf] On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 18:58:12 -0000 --00000000000054334605b3d96026 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The ticket in question is https://trac.ietf.org/trac/dmarc/ticket/68 (as an individual) If we go the tree walk route, I believe the realistic hack needed will simply be to add a max depth for the walk. The longest PSL suffix is only 4 labels deep, so a max depth of 10 seems generous without opening crazy abuse vectors through maliciously long and well constructed domain names. (as Chair) let's hold on ticket 68 until we come to consensus on whether this work should be done in a separate document, and if so, who the editors are. Seth On Wed, Nov 11, 2020 at 10:31 AM Doug Foster wrote: > I was trying to address the tree walk objections and denial-of-service > objections by starting at the upper end of the tree, so that an evaluator > cannot be tricked into trying 100 possibilities for a single email messag= e. > > > > An additional protection would be to specify a few TLDs, (particularly > .COM. .EDU, .NET, and .ORG) which will never be used for PSD DMARC > entries, so an implementer MUST NOT look for a DMARC entry there. Thos= e > TLDS would be the ones at most risk of performance problems if saturated = by > a DMARC TXT lookups during tree walk. A short don=E2=80=99t-look-here l= ist is > much more sustainable than what we have right now. > > > > DF > > > > *From:* Murray S. Kucherawy [mailto:superuser@gmail.com] > *Sent:* Wednesday, November 11, 2020 12:02 PM > *To:* Doug Foster > *Cc:* IETF DMARC WG > *Subject:* Re: [dmarc-ietf] On splitting documents and DBOUND > > > > On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > > Can we eliminate the PSL problem simply by adding some DNS queries? > > > > Isn't there a maximum depth to the PSL, so that the evaluator can simply > walk up the top N levels of the domain tree to find either an > organizational DMARC entry with sp=3D or a PSD DMARC entry with sp=3D? = It > looks like currently, n=3D4, because the published suffixes appear to ext= end > to 3 levels. > > > > That's been proposed, and I think it's a future topic for this WG. (A > ticket might be open about it already.) > > > > As John just said in another thread, the DNS crowd has been largely > allergic to the notion of a tree walk in the past, but the last time this > was given serious consideration was when DKIM was young (2007) and it mig= ht > be ripe for revisiting now. It certainly would make our lives simpler. > > > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000054334605b3d96026 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The ticket in question is=C2=A0https://trac.ietf.org/tr= ac/dmarc/ticket/68

(as an individual)

If we go the tree walk route, I believe the realistic = hack needed will simply be to add a max depth for the walk. The longest PSL= suffix is only 4 labels deep, so a max depth of 10 seems generous without = opening crazy abuse vectors through maliciously long and well constructed d= omain names.

(as Chair)

l= et's hold on ticket 68 until we come to consensus on whether this work = should be done in a separate document, and if so, who the editors are.

Seth

On Wed, Nov 11, 2020 at 10:31 AM Doug Foster= <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
<= div>

I was trying to address the tree walk ob= jections and denial-of-service objections by starting at the upper end of t= he tree, so that an evaluator cannot be tricked into trying 100 possibiliti= es for a single email message.

=C2=A0

An= additional protection would be to specify a few TLDs, (particularly .COM. = =C2=A0.EDU, .NET, and .ORG) which will never be used for PSD DMARC entries,= so an implementer MUST NOT look for a DMARC entry there.=C2=A0=C2=A0=C2=A0= Those TLDS would be the ones at most risk of performance problems if satur= ated by a DMARC TXT lookups during tree walk.=C2=A0=C2=A0 A short don=E2=80= =99t-look-here list is much more sustainable than what we have right now.

=C2=A0<= /span>

DF

=C2=A0

From: Murra= y S. Kucherawy [mailto:superuser@gmail.com]
Sent: Wednesday, November 11, 2020= 12:02 PM
To: Doug Foster
Cc: IETF DMARC WG
Subje= ct: Re: [dmarc-ietf] On splitting documents and DBOUND

=C2=A0

On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster <foster= d=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:

Can we eliminate the= PSL problem simply by adding some DNS queries?

=C2=A0

Isn&#= 39;t there a maximum depth to the PSL, so that the evaluator can simply wal= k up the top N levels of the domain tree to find either an organizational D= MARC entry with sp=3D or a PSD DMARC entry with sp=3D? =C2=A0 It looks like= currently, n=3D4, because the published suffixes appear to extend to 3 lev= els.

=C2=A0

That's= been proposed, and I think it's a future topic for this WG.=C2=A0 (A t= icket might be open about it already.)

=C2=A0

As= John just said in another thread, the DNS crowd has been largely allergic = to the notion of a tree walk in the past, but the last time this was given = serious consideration was when DKIM was young (2007) and it might be ripe f= or revisiting now.=C2=A0 It certainly would make our lives simpler.<= u>

=C2=A0

<= div>

-MSK

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


--

Seth Blan= k | VP, Standards and New Technologies
p: 415.273.8= 818


This email and all data transmitted with it c= ontains confidential and/or proprietary information intended solely for the= use of individual(s) authorized to receive it. If you are not an intended = and authorized recipient you are hereby notified of any use, disclosure, co= pying or distribution of the information included in this transmission is p= rohibited and may be unlawful. Please immediately notify the sender by repl= ying to this email and then delete it from your system.

--00000000000054334605b3d96026-- From nobody Wed Nov 11 11:24:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F9A3A0E83 for ; Wed, 11 Nov 2020 11:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=S6mC2g5B; dkim=pass (2048-bit key) header.d=taugh.com header.b=Mye2zaQF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs0PE56G2ejJ for ; Wed, 11 Nov 2020 11:24:33 -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 88E253A0DE7 for ; Wed, 11 Nov 2020 11:24:33 -0800 (PST) Received: (qmail 25511 invoked from network); 11 Nov 2020 19:24:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=63a2.5fac3a6f.k2011; i=johnl-iecc.com@submit.iecc.com; bh=/Ff/Jw054OJvQ9VZhLIL+/12+ISCUfjqIAmDQT9MGcE=; b=S6mC2g5BDT8gErgn0f1yEljcNrwaUjY4om2CTuBO9NshNMWm53sGinGH2WFmYjxze1EQUCU2xPR4QK0gHkyCI66SVcTILeyN5yKXyVQWim59XOQH8cZcqhPnneO9ooeaapJ7l4vdj2ATkwxqJUDVP7QpRPlZFtGqB0pRUPqZgCmy0ie3dls6zBNHdSnCiQqq+98r0mQezrWGTwZK3Xt7fKz44umia671m1hEqL4NuCxZlX0fnKcxPgDu/UMhg+w3w/g2UamNVwE2TOuUQjKsTfu4Av36mgBn/tNXHIVkCc26lbR+dhEicxWgxJ5Q44FKk2pXEZQ5bZVNWUVTzPhZHg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=63a2.5fac3a6f.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=/Ff/Jw054OJvQ9VZhLIL+/12+ISCUfjqIAmDQT9MGcE=; b=Mye2zaQFsT/zxlIH6ueM83VxND7HC3ZlN9owy/mEyOnGK0kKmTvya8J5oVT+7yRkN5oY7sC/KLsBLkxHYMxTJMF9RojFvBiszAmvTOU7t/DVDWBXgFh6j52irCAAf/F7E3IF7Upa2T20iUTaXSPsyJRilOlq11g3cKElQJinKrzhe0BI2nsxEijxkoi0YjAhR395xAY9Xei1EuV/KK6KGa+BvoKzs+T0UM19y6euUwZ9WqbxWl+hMN9p4GenBZf8LvpP4zNIFpIDAZZLjwCqEfacDE6COllH0MbMGT7JbPqkqcJxAHU/EN6Lch5Et21leOcbq/SNW2IrfJ/cwK3P9g== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 11 Nov 2020 19:24:30 -0000 Date: 11 Nov 2020 14:24:30 -0500 Message-ID: <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: References: <20201111181837.79128262943F@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 19:24:37 -0000 >> "Parent default" or something like that. There's no claim that it is >> or isn't in the same organization, just that it's a parent name of the >> target name. >> >> For Scott's _dmarc.BANK. thing it would deliberately*not* be the same >> organization. > > Where is such generality discussed in DMARC? I don't recall seeing it. That's draft-ietf-dmarc-psd > DMARC has had a consistent construct, which is 'the domain name that is at > the top of the organization's administrative hierarchy". Hence, > Organizational Domain. Nothing in the term requires that it be up the > 'current' domain name chain. I think a lot of people would be quite surprised to hear that the Org domain might not be a parent of the original domain. I sure would. I realize you could fake it with CNAMEs but that's different. 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 Nov 11 13:21:04 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3063A1124 for ; Wed, 11 Nov 2020 13:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YvZfgja-dXn for ; Wed, 11 Nov 2020 13:21:01 -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 477083A1119 for ; Wed, 11 Nov 2020 13:21:01 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ABLOTGd011835 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 11 Nov 2020 13:24:30 -0800 To: John R Levine , dmarc@ietf.org References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Wed, 11 Nov 2020 13:20:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 21:21:02 -0000 On 11/11/2020 11:24 AM, John R Levine wrote: >> DMARC has had a consistent construct, which is 'the domain name that >> is at the top of the organization's administrative hierarchy".  Hence, >> Organizational Domain.  Nothing in the term requires that it be up the >> 'current' domain name chain. > > I think a lot of people would be quite surprised to hear that the Org > domain might not be a parent of the original domain.  I sure would. Just to invoke a bit of ancient history, here, you are saying that if there was the domain name: engineering.sun.com people would be surprised that the organization domain is oracle.com ? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 11 13:30:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290813A1139 for ; Wed, 11 Nov 2020 13:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=X90kFKs2; dkim=pass (2048-bit key) header.d=taugh.com header.b=BCwZxng8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kaef8FCgS38T for ; Wed, 11 Nov 2020 13:30: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 829A63A1137 for ; Wed, 11 Nov 2020 13:30:42 -0800 (PST) Received: (qmail 67035 invoked from network); 11 Nov 2020 21:30:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=105d9.5fac5801.k2011; i=johnl-iecc.com@submit.iecc.com; bh=Zd+5h1h3boPZifjASmFoaXuOga4wMvMIJV5tom7WUFw=; b=X90kFKs2Wx/3z9nxpSxNb+1HqT/6oOi43mMaxgdJbhRkQJRxLbJc1CAUdFSxPmqjt9xxNpnfmJNug54O+CSiFZiexfPpEqlgDFvOcwijLmu/YGVyPfRZs+EZBgVp9Ls02E/Xz61q26WMqsobzCg/zi3IZbHNJN0YQR4F8miAej6kpIsz1Rv85r6BdwmjVYnvpPpXtpBMfztKGaUgBCNXkDl6v9fYmSRB/pc1aJyAn+k39/A2qiQbI7W50ZnvTdX0Ei34fC/g4C43In/cEaqP6qmrY1z85tfavh/ONZ6QSFLggfbRBJkPj/G6UUAy3BOtu/QSa4YJ6GOypeU1XR55dw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=105d9.5fac5801.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=Zd+5h1h3boPZifjASmFoaXuOga4wMvMIJV5tom7WUFw=; b=BCwZxng8dP8gmyesA5Th/greP2EeEiH9zMj1CSxESIVe8B3QZv/xIB87I5ID5BnABscMOpNtyhtKZrOfHBjvnThZ2XB816l8lObSQGYPpqp2igWxTZYsI5SFhT7u71srnMUpc+A5Q4YWyRfmGiINLQaSCfQlc7xJ7wruaGcsxfvfntU1RVQftR1aN3wOSkveUsHM0ZkN1o1HubOojnjcUuexPu8RDakaHt1BzpsbmyzXtPKdIvi0FGnwKcO/USTFgEd2jcXs4Kw/wFtErlaQkml56viQ1R2/OTK8HtSyavcnIX9JVgYgksD5Py6ftRQvG8E5tYcYPli9Jw2VegQmHg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 11 Nov 2020 21:30:40 -0000 Date: 11 Nov 2020 16:30:40 -0500 Message-ID: <4a504ea9-f634-191f-ae33-349d9cac8d20@taugh.com> From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 21:30:44 -0000 On Wed, 11 Nov 2020, Dave Crocker wrote: > Just to invoke a bit of ancient history, here, you are saying that if there > was the domain name: > > engineering.sun.com > > people would be surprised that the organization domain is > > oracle.com In a DMARC context, that would be quite surprising. I am aware that Oracke bought Sun quite a while ago. 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 Nov 11 13:34:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF93A11CC for ; Wed, 11 Nov 2020 13:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaysaQ_Ev6mg for ; Wed, 11 Nov 2020 13:34:04 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 1643D3A11A6 for ; Wed, 11 Nov 2020 13:34:00 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id i62so836188vkb.7 for ; Wed, 11 Nov 2020 13:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DyAlrDflFMwPrr5W6oDGgA8z/UX/eidrPyk2UnnzEts=; b=FqhZtSZCLjtqLnkacAjfXaFTVSF6p++Fv8taW7wt6pw9WhsF2lQgZ0eLupSC85Eqgn 6nsyUohTbUfgSNnrpjcmyMZJfCXIgkguQYccm2OxgpXPw0rugS3MnPPHxamomHmm2cn0 1QPMZA+YzMjR3UmMSBLk+4zcT5aPyditfJsWkCOYnSOAS4ItsVS4oTNbKTDQLKovFrN+ 4yYocxKkI/aMJv83GSgzOEjgW873zM+285geLujJiC8dx7XxzquZ+f4LXpWyl3B65CGV xpB6I2eCap7ysn9Oh5FgSUckXrwtKOv9FrBp051LDuTjXAYgIWaKxXbEtkaIbxiNymR1 wZ+A== 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=DyAlrDflFMwPrr5W6oDGgA8z/UX/eidrPyk2UnnzEts=; b=DGHzkOg0GAy3Ich/U8VtIjpgaG8mbVdk3GWkmSUh2AoSjCWOHPNlSlLSNA/wNx+0kK 1FJDOq6SVXhyVAHT5SEaGkrTk5/Hu4vHZ/no4g865z6b7yeTUXvkBJ5Vr/VWwKhcyrl9 GoIFdSCuIOw5wJdJgl8+h1ngF/OIOZejvknNsIhxPmXhZJ7DAMxzpLg1Mr+EK7zpWvHQ tkvIURxOAHJ5zSSEua3RA9BcCcHAOGB1W//GjzsvLD/Eq2NfcaXRhWslCPrttlexDSNr 2pM/MiIk1OfmFkmjI9+W009/T6Bdl9lHR8JDiDnm64RuvT7FTLPm841WOqCz+isXjvtf aCPw== X-Gm-Message-State: AOAM531XarApUNcSpWf+Enop6qivb4J0ZJdJ0cHQjqQGz1jEeNqyLia+ TLpn70HTSwNxaVQHTDzDrBBB9das/Kt9Jyt5vnGUqkzsdxgz7Q== X-Google-Smtp-Source: ABdhPJxsEtGsGe4+bOVwagUttraslFOjiuFP/XbcrHBTQXf2eDGd/1GfFxfz8TtWPqU7IukVA5AjDDtfLFvuMyWUp34= X-Received: by 2002:a1f:ccc5:: with SMTP id c188mr14999351vkg.4.1605130438771; Wed, 11 Nov 2020 13:33:58 -0800 (PST) MIME-Version: 1.0 References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> <4a504ea9-f634-191f-ae33-349d9cac8d20@taugh.com> In-Reply-To: <4a504ea9-f634-191f-ae33-349d9cac8d20@taugh.com> From: Seth Blank Date: Wed, 11 Nov 2020 13:33:47 -0800 Message-ID: To: IETF DMARC WG Cc: Dave Crocker , John Levine Content-Type: multipart/alternative; boundary="0000000000009f1c9405b3db8d77" Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 21:34:12 -0000 --0000000000009f1c9405b3db8d77 Content-Type: text/plain; charset="UTF-8" This use case is actually the intention of (the extremely poorly worded) https://trac.ietf.org/trac/dmarc/ticket/59 To the earlier conversation, this is all simplified dramatically if we define organizational domain (or whatever it's renamed) discovery in a separate I-D that DMARC just inherits... On Wed, Nov 11, 2020 at 1:30 PM John R Levine wrote: > On Wed, 11 Nov 2020, Dave Crocker wrote: > > Just to invoke a bit of ancient history, here, you are saying that if > there > > was the domain name: > > > > engineering.sun.com > > > > people would be surprised that the organization domain is > > > > oracle.com > > In a DMARC context, that would be quite surprising. I am aware that > Oracke bought Sun quite a while ago. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000009f1c9405b3db8d77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This use case is actually the intention of (the extremely = poorly worded) https= ://trac.ietf.org/trac/dmarc/ticket/59

To the earlier= conversation, this is all simplified dramatically if we define organizatio= nal domain (or whatever it's renamed) discovery=C2=A0in a separate I-D = that DMARC just inherits...


On Wed, Nov 11, 2020 at 1:3= 0 PM John R Levine <johnl@taugh.com> wrote:
On= Wed, 11 Nov 2020, Dave Crocker wrote:
> Just to invoke a bit of ancient history, here, you are saying that if = there
> was the domain name:
>
>=C2=A0 =C2=A0engineering.sun.com
>
> people would be surprised that the organization domain is
>
>=C2=A0 =C2=A0oracle.com

In a DMARC context, that would be quite surprising.=C2=A0 I am aware that <= br> Oracke bought Sun quite a while ago.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion intended solely for the use of individual(s) authorized to receive it. = If you are not an intended and authorized recipient you are hereby notified= of any use, disclosure, copying or distribution of the information include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--0000000000009f1c9405b3db8d77-- From nobody Wed Nov 11 13:42:27 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CDB3A110F for ; Wed, 11 Nov 2020 13:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD186CDMUIlY for ; Wed, 11 Nov 2020 13:42:23 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8DA3A1101 for ; Wed, 11 Nov 2020 13:42:23 -0800 (PST) X-ASG-Debug-ID: 1605130941-11fa31480260e00001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Emn0wW8VMdYo2AE5 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Wed, 11 Nov 2020 16:42:22 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=mGdXlws5y+m5FTEBSuouBnk3c2DoFfRBn9ijtbaVAAo=; b=eiVJ7XR1Bqn8tVG6twbp0RN7fz9PsbJUl56Jwy9CTXRgs6oDbOWqKOivDSsM+39R7 CQwb+y2NgEvXKy05U45EKkD5UODk5kDlnjmN+lC3lVuEkrFHPS3bjmt7hC9h777ZG ZmX0uLYcHw5qU0vsSNuqotV8U146IFFuYs3cAaZXs= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 11 Nov 2020 16:42:15 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF DMARC WG'" References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> <4a504ea9-f634-191f-ae33-349d9cac8d20@taugh.com> In-Reply-To: Date: Wed, 11 Nov 2020 16:42:15 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND Message-ID: <007d01d6b873$85abffc0$9103ff40$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007E_01D6B849.9CD6E220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFquZdlQzSNia2SCi/iBDIzaFcj6gGLkE7wAniPB8IDJf80FgE1DsnnAu51HBqqQQafEA== Content-Language: en-us X-Exim-Id: 007d01d6b873$85abffc0$9103ff40$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605130942 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10710 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85808 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Nov 2020 21:42:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007E_01D6B849.9CD6E220 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It appears that these tickets are all related to this issue: =20 #24 objection to maintaining registry for all participating = public suffixes #34 Define the term "Public Suffix" referencing RFC8499 #46 Separate org domain definition from core DMARC #58 Add third lookup for public suffix domains #59 Add third lookup for organizational home #68 Do away with the PSL and Org Domain entirely; just walk the = tree =20 =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Seth Blank Sent: Wednesday, November 11, 2020 4:34 PM To: IETF DMARC WG Cc: John Levine; Dave Crocker Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was = On splitting documents and DBOUND =20 This use case is actually the intention of (the extremely poorly worded) = https://trac.ietf.org/trac/dmarc/ticket/59 =20 To the earlier conversation, this is all simplified dramatically if we = define organizational domain (or whatever it's renamed) discovery in a = separate I-D that DMARC just inherits... =20 =20 On Wed, Nov 11, 2020 at 1:30 PM John R Levine wrote: On Wed, 11 Nov 2020, Dave Crocker wrote: > Just to invoke a bit of ancient history, here, you are saying that if = there=20 > was the domain name: > > engineering.sun.com > > people would be surprised that the organization domain is > > oracle.com In a DMARC context, that would be quite surprising. I am aware that=20 Oracke bought Sun quite a while ago. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. = https://jl.ly _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc =20 --=20 Seth Blank | VP, Standards and New Technologies e: seth@valimail.com p: 415.273.8818=20 = =20 =20 This email and all data transmitted with it contains confidential and/or = proprietary information intended solely for the use of individual(s) = authorized to receive it. If you are not an intended and authorized = recipient you are hereby notified of any use, disclosure, copying or = distribution of the information included in this transmission is = prohibited and may be unlawful. Please immediately notify the sender by = replying to this email and then delete it from your system. ------=_NextPart_000_007E_01D6B849.9CD6E220 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

It appears that these tickets are all related to this = issue:

 

#24=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 objection to = maintaining registry for all participating public = suffixes

#34=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Define the term = "Public Suffix" referencing RFC8499

#46=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Separate org = domain definition from core DMARC

#58=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add third lookup = for public suffix domains

#59=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add third lookup = for organizational home

#68=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Do away with the = PSL and Org Domain entirely; just walk the tree

 

 

From:= = dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Seth = Blank
Sent: Wednesday, November 11, 2020 4:34 PM
To: = IETF DMARC WG
Cc: John Levine; Dave Crocker
Subject: = Re: [dmarc-ietf] Organizational domains, threat or menage, was On = splitting documents and DBOUND

 

This = use case is actually the intention of (the extremely poorly worded) https://trac.ietf.org= /trac/dmarc/ticket/59

 

To the earlier conversation, this is all simplified = dramatically if we define organizational domain (or whatever it's = renamed) discovery in a separate I-D that DMARC just = inherits...

 

 

On = Wed, Nov 11, 2020 at 1:30 PM John R Levine <johnl@taugh.com> = wrote:

On Wed, = 11 Nov 2020, Dave Crocker wrote:
> Just to invoke a bit of ancient = history, here, you are saying that if there
> was the domain = name:
>
>   engineering.sun.com
>
> people would = be surprised that the organization domain is
>
>  =  oracle.com

In a DMARC context, that would = be quite surprising.  I am aware that
Oracke bought Sun quite a = while ago.

Regards,
John Levine, johnl@taugh.com, = Taughannock Networks, Trumansburg NY
Please consider the environment = before reading this e-mail. https://jl.ly

______________________________= _________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


 

-- =

Seth Blank | VP, Standards and New = Technologies

e: seth@valimail.com

p: 415.273.8818

<= img border=3D0 id=3D"_x0000_i1025" = src=3D"https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl= 5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDx= YQansg8ChT2x5EcZV3rjz19-Dx9rESL">

 

= This email and all data transmitted with it contains confidential and/or = proprietary information intended solely for the use of individual(s) = authorized to receive it. If you are not an intended and authorized = recipient you are hereby notified of any use, disclosure, copying or = distribution of the information included in this transmission is = prohibited and may be unlawful. Please immediately notify the sender by = replying to this email and then delete it from your = system.

------=_NextPart_000_007E_01D6B849.9CD6E220-- From nobody Wed Nov 11 13:55:00 2020 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 106BF3A1152; Wed, 11 Nov 2020 13:54:55 -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: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <160513169495.16356.6565556939968267867@ietfa.amsl.com> Date: Wed, 11 Nov 2020 13:54:55 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 21:54:55 -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 : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Authors : Emil Gustafsson Todd M. Herr John Levine Filename : draft-ietf-dmarc-dmarcbis-00.txt Pages : 55 Date : 2020-11-11 Abstract: This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting. Mail-receiving organizations can in turn use these expressions of policies and preferences to inform their mail handling decisions should they choose to do so. This document obsoletes RFC 7489. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-00.html Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 11 14:37:02 2020 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F18163A119B; Wed, 11 Nov 2020 14:36:55 -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: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <160513421595.20344.12981805231107362355@ietfa.amsl.com> Date: Wed, 11 Nov 2020 14:36:55 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 22:36:56 -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 : Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting Authors : Steven M Jones Alessandro Vesely Filename : draft-ietf-dmarc-failure-reporting-00.txt Pages : 14 Date : 2020-11-11 Abstract: Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a domain owner can request feedback about email messages using their domain in the From: address field. This document describes "failure reports," or "failed message reports," which provide details about individual messages that failed to authenticate according to the DMARC mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-00.html 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 Thu Nov 12 01:40:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154A83A153E for ; Thu, 12 Nov 2020 01:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhIefNJD1s9V for ; Thu, 12 Nov 2020 01:40:21 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9453A153B for ; Thu, 12 Nov 2020 01:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605174017; bh=N9KvY0lOj1WNvCEnJ75Nz20PJNQm7Mrx6syB6HftrYQ=; l=714; h=To:References:From:Date:In-Reply-To; b=CUy3tWleEAJqg/X78RlUBbD1HkkZH0ZjJYYOn93k7Iqk/2UjCAhJtFDo/fRflX9ji Sn5Y+R6EtJuLRQc5De7qcXGjpBAQAAnygNKQKI/WQt7UkfT8wjWOtjDmb9qEOBzT28 EXCY8lqq0xkPn9GhY39La3g5jeuNVVEG29FdspKENVOkr8PEs8S8x26Jgfwu6 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FAD0301.00005E4A; Thu, 12 Nov 2020 10:40:17 +0100 To: dmarc@ietf.org References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> From: Alessandro Vesely Message-ID: Date: Thu, 12 Nov 2020 10:40:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 09:40:22 -0000 On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote: > On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: >> The proposal is, I think, to change the main document to leave a pointer, and >> the pointer can be changed much more easily than the actual method.  So the >> new DMARC document would say: "Determine the Organizational Domain.  The >> legacy way to do this can be found in [other-RFC], but other better methods >> are anticipated." > > wfm. +1, Perhaps we could say "Organizational Domain or a domain thence delegated" rather than anticipating unspecified methods. I think DMARC will require the (implied) consent of the interested domain for the foreseeable future. Best Ale -- From nobody Thu Nov 12 06:23:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82653A1102 for ; Thu, 12 Nov 2020 06:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9JQV3wppof6 for ; Thu, 12 Nov 2020 06:23:51 -0800 (PST) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 EDED73A1100 for ; Thu, 12 Nov 2020 06:23:50 -0800 (PST) Received: from pps.filterd (m0167073.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ACEMsHW009881 for ; Thu, 12 Nov 2020 09:23:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : content-type; s=pps01; bh=ISEGV47vtQaVbQx4e89tAytYguEasnmYx8KuCjbIm/U=; b=UkBKzrjA9cDnbTt5HM45fK0sB3JUwvm5KTVDoX/U2aBJsOTXJO/VnezIYl4e+2sze4pE mYqYKnIAYbjZ2m5NKzEwIVNguHzsyi/svg/8leg11ljDin6E7J+TB3sW3yF5ii76wYQs KSObQ83wbxPE7H4tOj1/956WUpZN+ohasbeqZcq+Mr9mSBJH5UmtMUJ1lFJky9Puy4lQ 5/DEjXd/WxwTR6Tx5FjffPeMiG1vBNLsqXpP38XIuxNFBp1Xm55oZB82MTi+c0X03oW1 4ftCU4HXjTMwIXqauq6IIK4O5yS1u7E5nxadRiGz/cpOgkKgYbK1RAIsU1dheV4rWm9P xQ== Received: from sendprdmail21.cc.columbia.edu (sendprdmail21.cc.columbia.edu [128.59.72.23]) by mx0b-00364e01.pphosted.com with ESMTP id 34nrbm8jna-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 12 Nov 2020 09:23:49 -0500 Received: from mail-il1-f199.google.com (mail-il1-f199.google.com [209.85.166.199]) by sendprdmail21.cc.columbia.edu (8.14.7/8.14.4) with ESMTP id 0ACENmX2033998 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2020 09:23:49 -0500 Received: by mail-il1-f199.google.com with SMTP id l8so4050251ilf.10 for ; Thu, 12 Nov 2020 06:23:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ISEGV47vtQaVbQx4e89tAytYguEasnmYx8KuCjbIm/U=; b=Zo5e2eErhaz8+qVvPZW1icpUF6m6bsTL6DndUAsOfhOpBYTXQwrjPqyawdBp1UNjoY Fg5EhtYsV3mMSwg03ARlaPxAEn1OOh2IL1wFxYx94HPwectFenoKfUN2HbiXiEY/WpP4 6WK5EDJz+kmYyOzIyqiIivv23aGk3/2oSrWvtWXhp+oMUfQ39/IsKxh6cBwvXYse3SQ3 6a9ndgn0hk0cG5KGp7IM+STQ1X7D8Hl9gcjOrVeXERai0o/VGyN6FzdSxaSdByQjS56P cToT0cNeX0F9k1+W9OGKgsD3/Qd7lW2oS2YyqDwXkrFQq6QVGM1Z9Z7g7Ru5FG5xOjRJ 9VGA== X-Gm-Message-State: AOAM532HRicJIE0SDwBbzIGPOJuSRHMXdsFPRU5noGAQTarikqiBTjSe JqKXCY9dci7wRtzC6QjyQTtw9iy4i3ZZ2ikuPh0aeDIIGAEvLgFXfNBl/KdXY5qgOvTHrtYO5Vj DreGFQ7mQYfkokTmmnNN3YeLiXGh5Pg== X-Received: by 2002:a92:ac0e:: with SMTP id r14mr24874052ilh.197.1605191027826; Thu, 12 Nov 2020 06:23:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJxHs5DuN9p1HRNMb2NknLXH75FwKMioV0ncUqtE8WTMN6cqXOetan/h6DydtqlZCecxEGEf6nIj8+PzSayqeis= X-Received: by 2002:a92:ac0e:: with SMTP id r14mr24874024ilh.197.1605191027386; Thu, 12 Nov 2020 06:23:47 -0800 (PST) MIME-Version: 1.0 References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> In-Reply-To: From: Joseph Brennan Date: Thu, 12 Nov 2020 09:23:36 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fc1a2d05b3e9a886" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-12_05:2020-11-12, 2020-11-12 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 mlxscore=0 phishscore=0 impostorscore=10 spamscore=0 lowpriorityscore=10 bulkscore=10 suspectscore=2 malwarescore=0 clxscore=1011 priorityscore=1501 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011120084 Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 14:23:54 -0000 --000000000000fc1a2d05b3e9a886 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: > > Just to invoke a bit of ancient history, here, you are saying that if > there was the domain name: > > engineering.sun.com > > people would be surprised that the organization domain is > > oracle.com > > As another case, would people be surprised that email for the medical center cumc.columbia.edu is a separate system managed by a separate IT group from columbia.edu, and that any authentication for one should not be applied to the other? I don't think this is unique in large decentralized universities. The real email world is a complicated place. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --000000000000fc1a2d05b3e9a886 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 11, 2020= at 4:21 PM Dave Crocker <dhc@dcrock= er.net> wrote:

Just to invoke a bit of ancient history, here, you are saying that if
there was the domain name:

=C2=A0 =C2=A0 engineering.sun.com

people would be surprised that the organization domain is

=C2=A0 =C2=A0 oracle.com


As another case, wo= uld people be surprised that email for the medical center cumc.columbia.edu is a separate system managed by a= separate IT group from columbia.edu, a= nd that any authentication=C2=A0for one should=C2=A0not be applied to the o= ther?=C2=A0 I don't think this=C2=A0is unique in large decentralized un= iversities. The real email world is a complicated place.


--
Joseph Brennan
Lead, Email and Systems Applications<= /div>
Columbia University Information Technology


--000000000000fc1a2d05b3e9a886-- From nobody Thu Nov 12 07:04:04 2020 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3AA3A11A1; Thu, 12 Nov 2020 07:03:53 -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: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmarc@ietf.org Message-ID: <160519343357.14140.12963039273205066404@ietfa.amsl.com> Date: Thu, 12 Nov 2020 07:03:53 -0800 Archived-At: Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 15:03:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF. Title : DMARC Aggregate Reporting Author : Alex Brotman Filename : draft-ietf-dmarc-aggregate-reporting-00.txt Pages : 14 Date : 2020-11-12 Abstract: DMARC allows for domain holders to request aggregate reports from receivers. This report is an XML document, and contains extensible elements that allow for other types of data to be specified later. The aggregate reports can be submitted to the domain holder's specified destination as supported by the receiver. This document (along with others) obsoletes RFC7489. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00 https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 12 08:02:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7863A1507 for ; Thu, 12 Nov 2020 00:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 JUR4oxYaERS1 for ; Thu, 12 Nov 2020 00:49:32 -0800 (PST) Received: from www210.your-server.de (www210.your-server.de [78.46.0.150]) (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 43F983A1255 for ; Thu, 12 Nov 2020 00:49:31 -0800 (PST) Received: from sslproxy02.your-server.de ([78.47.166.47]) by www210.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1kd8IL-0002tP-Rf for dmarc@ietf.org; Thu, 12 Nov 2020 09:49:29 +0100 Received: from [109.190.207.208] (helo=[192.168.1.60]) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kd8IL-000G5k-Ni for dmarc@ietf.org; Thu, 12 Nov 2020 09:49:29 +0100 To: dmarc@ietf.org References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> <4a504ea9-f634-191f-ae33-349d9cac8d20@taugh.com> From: devel2020@baptiste-carvello.net Message-ID: Date: Thu, 12 Nov 2020 09:49:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Authenticated-Sender: webmaster@baptiste-carvello.net X-Virus-Scanned: Clear (ClamAV 0.102.4/25985/Wed Nov 11 14:18:01 2020) Archived-At: X-Mailman-Approved-At: Thu, 12 Nov 2020 08:02:47 -0800 Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 08:49:34 -0000 Hi, Le 11/11/2020 à 22:33, Seth Blank a écrit : > > To the earlier conversation, this is all simplified dramatically if we > define organizational domain (or whatever it's renamed) discovery in a > separate I-D that DMARC just inherits... Let me point out, though, that sending reports to "organizational domain" or to "ancestor domain" have different privacy implications. Which is an argument for defining at least the semantics (and name) of that domain in the main document. Cheers, BC From nobody Thu Nov 12 08:31:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD28D3A0FB1 for ; Thu, 12 Nov 2020 08:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=cKvWqj+f; dkim=pass (2048-bit key) header.d=taugh.com header.b=PvO5vlh+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEyI7M9TOWB1 for ; Thu, 12 Nov 2020 08:30:58 -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 54B883A1391 for ; Thu, 12 Nov 2020 08:30:57 -0800 (PST) Received: (qmail 73035 invoked from network); 12 Nov 2020 16:30:56 -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:cleverness; s=11d49.5fad6340.k2011; bh=4lFfCH2qoA3Y8Z6Gvk1E5SB+TPSJCWmIcT30VSUDSzM=; b=cKvWqj+fGDfVjd0O0Sb5AYry31fsuEMBOCXwQy5EU3EXofqrQIRguU6GUlTJaM82aZDZ7DbBB1ssnOY4pjKwxNM5BzD0eYLPlCl8DpRvzS8RPxrKX7XddCPLC68AYsb4OoMc3P86HwZS1OL3wK5sldLYp7QLNTQOWP5HxeX2dPX+YKk4pRZwjwcbk88EwhoOCtfEm1dmt6V+mXzytvkFlb5L8DETJonJfQfIVR8xiOo3yIPKRCQ5SWTzsS6Yw3rso6oOjcCr1APiwRhdUapsVPp6j9+ApYbt86jwWr7i4RqH3+F897jTRYL94d8wH4dNOi9kUeZWMie2FVpDOeoyhg== 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:cleverness; s=11d49.5fad6340.k2011; bh=4lFfCH2qoA3Y8Z6Gvk1E5SB+TPSJCWmIcT30VSUDSzM=; b=PvO5vlh+2Y4XjtfO01vsdMshR86sr2YQDxTUR80zo092YWdJ9f0+41598cyyS9HevjKm96ZNu8o8rUxUzad/45rYTMOBXJuTOnopq6X5fblxQPrSRf6WJHbIrKhbvOSq4tXhoh2Ph2f6lLyK7nbu/iGlyr2OgiwacR3Zchu0Bx1SPBQN03C51vPO43keAji5wVcV7TOnLTpLFyqqe92//HrB2r2TaSjAW29uMbUn8dsQQOzrhbrtzBtBBT4BfYpbox/0WCgPbGDmc0tzPv7RrQQujKfwtjrPukBBvKcDrjedJLd2vLVOiYSpZNMkrwiKeolI61dU87Al0Me7DiLSsA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 12 Nov 2020 16:30:55 -0000 Received: by ary.qy (Postfix, from userid 501) id E3FA22634C27; Thu, 12 Nov 2020 11:30:54 -0500 (EST) Date: 12 Nov 2020 11:30:54 -0500 Message-Id: <20201112163054.E3FA22634C27@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: brennan@columbia.edu In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 16:31:00 -0000 In article you write: >As another case, would people be surprised that email for the medical >center cumc.columbia.edu is a separate system managed by a separate IT >group from columbia.edu, and that any authentication for one should not be >applied to the other? I don't think this is unique in large decentralized >universities. The real email world is a complicated place. Good point, and those aren't boundaries that the PSL et al will show. On the other hand, if you don't want your nominal parent organization stealing your reports, you can fix that by publishing your own dmarc record regardless of how we find the org domain. I asked in DNSOP about tree walks and my take on the response is that they are OK, perhaps with some advice about how to limit the effect of long malicious domain names. The CAA record has required a tree walk since 2013 and the sky hasn't fallen in. I guess if we're planning to consider a tree walk, it could make sense to put the org domain stuff in a separate rather short draft. By the way: >> engineering.sun.com >> oracle.com _dmarc.sun.com. CNAME _dmarc.oracle.com. Since nothing else is going to be at the _dmarc label, CNAMEs work fine for cross-tree references. From nobody Thu Nov 12 08:42:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5273A13FF for ; Thu, 12 Nov 2020 08:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U59pYDAJU284 for ; Thu, 12 Nov 2020 08:42:43 -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 423DB3A13FC for ; Thu, 12 Nov 2020 08:42:43 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ACGkC2a032751 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2020 08:46:13 -0800 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 12 Nov 2020 08:42:36 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.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] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 16:42:44 -0000 On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: > So the new DMARC document would say: "Determine the Organizational > Domain. The legacy way to do this can be found in [other-RFC], but > other better methods are anticipated." Then when something better > than PSL (maybe a tree walk, maybe something else) comes along, the > IETF publishes that specification and DMARC implementations and > operators switch to that method. The base document doesn't need to > change at all. On 11/12/2020 8:30 AM, John Levine wrote: > I asked in DNSOP about tree walks and my take on the response is > that ... > _dmarc.sun.com. CNAME _dmarc.oracle.com. Tree-walking is unacceptable. Tree-walking is now acceptable. Use CNAMES. Don't use CNAMES. The issue is not whether a bit of mechanism might work, but that this realm of activity is both complicated and has a history of controversy, as well as a history in the PSL case of not working all that well. All of which should strongly encourage isolating this topic from DMARC as much as possible. Make sure that changes to this do not require changing the core DMARC spec. Murray's proffered text does this nicely. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 12 08:45:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427F13A128E for ; Thu, 12 Nov 2020 08:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NB2gNz4gA7r for ; Thu, 12 Nov 2020 08:45:00 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEAE3A13F3 for ; Thu, 12 Nov 2020 08:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605199497; bh=2sRwQn4vQlLutEgRTiM0yw6pxjOHrx+48MPIu4emEs8=; l=812; h=To:References:From:Date:In-Reply-To; b=C3nKQBjlpNGhuH61ZfQqcZ/fKK4n0VBifqQlafQ4eD5g8YMrhMZSTBhL9wYn9iMpb h/GBdIcrMz32Za3BkGx9A7NBFrBcbZqxXpE4I4cIeJXDmXEtG5dGpq2lOjrT8LRsLG 9IhDamqnGsaGtSuSo82FMtdhfy7G5EZX8EAUc/NKXOz1rgli+6BubaukzkvxT Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FAD6689.00000F9F; Thu, 12 Nov 2020 17:44:57 +0100 To: dmarc@ietf.org References: <20201111022444.AF87925EE227@ary.qy> <8859f121-f9da-3017-5c51-063552ff4e2a@dcrocker.net> <11adfbd2-e06e-2cf-7a25-53f256aa30c@taugh.com> From: Alessandro Vesely Message-ID: Date: Thu, 12 Nov 2020 17:44:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 16:45:01 -0000 On Thu 12/Nov/2020 10:40:17 +0100 Alessandro Vesely wrote: > On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote: >> On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote: >>> The proposal is, I think, to change the main document to leave a pointer, >>> and the pointer can be changed much more easily than the actual method.  So >>> the new DMARC document would say: "Determine the Organizational Domain.  The >>> legacy way to do this can be found in [other-RFC], but other better methods >>> are anticipated." >> >> wfm. > > > +1,  Perhaps we could say "Organizational Domain or a domain thence delegated" > rather than anticipating unspecified methods.  I think DMARC will require the > (implied) consent of the interested domain for the foreseeable future. Oops, s/interested/concerned/ From nobody Thu Nov 12 11:29:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A873A005C for ; Thu, 12 Nov 2020 11:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtLE0lUzhUcY for ; Thu, 12 Nov 2020 11:29:13 -0800 (PST) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 E7C333A00D8 for ; Thu, 12 Nov 2020 11:29:12 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2050.outbound.protection.outlook.com [104.47.44.50]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QJP01VHA72Z5D00@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 12 Nov 2020 13:21:00 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.12.191218, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.10.22.5770001, SenderIP=[104.47.44.50] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D9ZTQeBUm8fOBuxF/hxMDUDlvppAc3xaY/O9XDrOHxo+qr/1uClsfJq29Y+x6q/lZVmeOg4/ZzL5qoupBep/uHJ4DSb+HtheQOeAM1FH8QsgmoX/TdeCS6Fd4k11jjfrrWMC7P327poFovNQpZZNKJsTa4n2hwIpwCepeugTJZm8j3MDLnSUGwcg5pI7dluUfixRieBcHsYw3Wuj/4yDWBfxJdnRPgPCtAAB6k9AoZlWkf9zwXzEk7jkYIXcIlSXGVlgz6W/VqXEd/zeHqOWLl6o6lMOztryVO2JFqusw0EGbcTBWQ5+MbIvopv08073vUAQPUfNenABDFQ8uZ0tqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rk5uEWiDTcdJPR+lsV7B+zCd+z6FO5N6I/CFkRRiQJQ=; b=mdpqCX/Vz+QPq4DvUso4P2v9GGpOVI4Oq+3+/cqq6bZM4wDTns7LicMz6eoHI0WI4B+pWI0an77ZbBKRCdCIKyqt+DTnHye1FdftLDOin4frRWaccHtagFeW+3muLx6+zwnNsT4Xa+ePNQLVWVdsTRdKPHkcPn6Zf5M7mwHczp/dtbkXD2UKYnpzDNcSs5BB5Yxuwmxmv2qK5Kv2DlssNFnCgtw64BcP+Mqz764Cnk/VVts45YgX8oca3vAHe8BJXAL8idLINI2+OkH75fcLE3BGzPc8HNHyhZUoyZFqQBG5vrdcx4M+13I1nqRVHpboMK7kn7jhGxCkomfTmrKw+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rk5uEWiDTcdJPR+lsV7B+zCd+z6FO5N6I/CFkRRiQJQ=; b=q/hANfDp8oka+vXGOKsKHeBjqNt3JfWW1ddxbuzmzSPo2AKqbMIV+sI9s073eZESfFuGGOLQRn6JF+/UvTmBnbIRCRY5fwcNnLs+QBuEMyZIfxwQf4Oq/8njf36y531RHHCDjcwOq8s+dhz4CbmeMz12hIg8972A8aku0UK8u1w= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7062.namprd06.prod.outlook.com (2603:10b6:510:26::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 12 Nov 2020 19:20:59 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98%7]) with mapi id 15.20.3499.032; Thu, 12 Nov 2020 19:20:59 +0000 To: dmarc@ietf.org References: <20201112163054.E3FA22634C27@ary.qy> From: Jesse Thompson Message-id: <5bc82960-70a4-3ce2-4e3d-a39dd974334c@wisc.edu> Date: Thu, 12 Nov 2020 13:20:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 In-reply-to: <20201112163054.E3FA22634C27@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH2PR02CA0010.namprd02.prod.outlook.com (2603:10b6:610:4e::20) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR02CA0010.namprd02.prod.outlook.com (2603:10b6:610:4e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Thu, 12 Nov 2020 19:20:58 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 13248e0f-ff62-4529-e707-08d8874015d7 X-MS-TrafficTypeDiagnostic: PH0PR06MB7062: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GvFAajL1WVj36LogBwoLbT+RkxmO15GU16PbsqIYdYCbG8OaOtVSesRat5ZRLZe65O86GBkKAOll8xAJhSprHLPZc0Skzn5cUVfWJqNnHIYfFDyQnES+yrEK0ACLP+saPmfla18ULDjOboz9U1HhmMRG1nhOEOx7pYa3RXhkET8CkNLD6GlI1ONSwmkCF9PvTX44zUW7q/YadXtRE+1nT1d7grH3YSWcxs+p3A1fRMsKnRvNSF+OoY6bzCFKZjXs0dRxPH8GfOYqXQdgMgQuglrkqaej+vjwAh42cAV9LSdYi9qyKVnAtIVYIfU/CF6B7yumgf3UCju2QambBHnCyy7f0iNbAiTpiKmcxiJZ37R2ee7BZJ1cFMkeB38KHoB84teW6LgzoMS6lLYYV99VNOeEckkmUgbzcV8nPhvRsbc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(396003)(376002)(39860400002)(346002)(44832011)(6706004)(8676002)(66946007)(86362001)(16526019)(316002)(31686004)(16576012)(786003)(478600001)(53546011)(2906002)(6916009)(75432002)(66556008)(5660300002)(36756003)(6486002)(6666004)(31696002)(956004)(26005)(2616005)(8936002)(66476007)(186003)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 5vcMoTovqgD3U8JSDoPQPG+cTqkdhHYohZ5KyQ/B8dxEW9QEN5CafKR00rx0XAYfe2X8+yiByyvT8X3GiAPhgiMF5L+W1pjsYaA9RcgPQkWnPooMHkibcsETsNAs9lJJ+GlBvbSV3S0BagHr7zUIozStvgsJoEvAzHrJLYu7j/NWpvKI9BY5cr+rtxHh5WC1px6CbmzNpC4mnvTKwVmxc3f3Zvsg5G5o69Ma+uIHMU826+m4yNIfxMFCizMF43kmxPCeVrnfpZdyxrWc3yxRP02Q/nL07gf5RCkpuSro0gPgVAB4RIP1axITX0HrHhTlI2QKAm6br0GbdF9SyeyTOjtCrBw9eG3G1MgLNC9bAzQBvtNiuTj/wBVJhBIHTLmHzlTKTUmQlERVYwDPE9GRzKiYW7lp/Vqg1qovAFuZXxmpjx9bACwcU6ptGvGaXrZEpjb6ZS4sATWsg2mYr3Z/oU0b4CNPKAP3IAGGe+36c2k8G9BUYxkZc1bulTginbhkNEKBFgCPcfPzxriu93SIzJVr5r8mgGSZdAJRmCZOWpsFEeUt3BwsJuAdpt1clctIPEoe1MDpH1o78rC3xUW+AWTkGVT3UNFCO519gZHGzfDn70ozOVn9O1c5FseMok26aijI1cWX/dmOPOSE4dAfIg== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 13248e0f-ff62-4529-e707-08d8874015d7 X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2020 19:20:58.9004 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JVS2Xy075/3dGdfdA0dFu3RtV4Cv4cqStZ78gk3Bf7KA2rr9I7hfypzsiTIjzLRhC6ncWMQhoQTexqmPlUa5kQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7062 Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 19:29:14 -0000 On 11/12/20 10:30 AM, John Levine wrote: > In article you write: >> As another case, would people be surprised that email for the medical >> center cumc.columbia.edu is a separate system managed by a separate IT >> group from columbia.edu, and that any authentication for one should not be >> applied to the other? I don't think this is unique in large decentralized >> universities. The real email world is a complicated place. > > Good point, and those aren't boundaries that the PSL et al will show. > On the other hand, if you don't want your nominal parent organization > stealing your reports, you can fix that by publishing your own dmarc > record regardless of how we find the org domain. Assuming this is obvious - it's also a challenge for sp. It would be nice to get to the point that we could publish more than sp=none at our organizational domain. Without tree walking, or some other ability to define sp for 3rd-level domains (such as the one that is the parent of our high throughput compute cluster of 4th level domain named machines that send email - shocker, I know), we'll never achieve any meaningful org-level sp due to the complexity of our organization. If tree walking is a thing that comes to fruition, what does it mean for a domain to be an organizational domain (in reference to the idea that the DMARC spec will just point to another doc to determine the org domain)? Aren't all parent domains org domains of their children? Or is there something special about the "top" org domain that I'm not understanding? Jesse UW-Madison From nobody Thu Nov 12 13:26:03 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE763A0D94 for ; Thu, 12 Nov 2020 13:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=EBCL5LKu; dkim=pass (2048-bit key) header.d=taugh.com header.b=Umllo5AO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFzo84dw_ZrP for ; Thu, 12 Nov 2020 13:25:56 -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 31DED3A16E9 for ; Thu, 12 Nov 2020 13:23:24 -0800 (PST) Received: (qmail 45764 invoked from network); 12 Nov 2020 21:23:24 -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:cleverness; s=b2c2.5fada7cb.k2011; bh=3gXvMkR5Lv4hifTUdUkDaARqJqnUqtbcnQnuLsyWZfA=; b=EBCL5LKuQwJRS27lAumsQTBHJSi+X2H33NraXmA46C4CXAclY/VdifPakTHe0jJM/WnBoulWdTwUrX6HYr88asPPk9NkvzJc2I8s/KXHizemPg/UneO9q/5/cVkGjxwBFtif1CSr8IBTdlZJ6JhvDpEZyjStVQzSUhFszoS6QILSr9E5h4tSAprvyplR/0GhdiKfv1qe3zE10c0hd50CeSX8bt6ixoSMz/WPyJj7uuxlAJkL/LzEQs4e6paqDPmm6XN+nN9dC+4NP59gjPX/T5+/G+84ZeRxQfSqv0DG9NBO/LyP6YoTR/PLVCCN0QqFzTSy8YH3mcbq2F09TDc4ww== 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:cleverness; s=b2c2.5fada7cb.k2011; bh=3gXvMkR5Lv4hifTUdUkDaARqJqnUqtbcnQnuLsyWZfA=; b=Umllo5AOjjHF/T27B9mvIJ3HZm2jI4rgXuzoa6RohPrBb391p1vOqMRSxRBZAw0qpND0gRxbOf9g+KOm3It9JaTtEn27Fj/3EsGVZCidHUZd1Ref4d7mmUAZqvTkSPvxxdnNhgRcy8r3KgRu5dI/9nxbjT5x5BqRmxQzpxHkBI3kOyZUHW2PBY96olysxuxwrCXWFphONcfdT2H5ahxBoJJi7FaUK2//Oxjr0ad1p+L7hi0qHpbMl2p/kOHdkmN18Dw8EZBC2/KRHOpSNdUhSO5aXSYAjMcgzz6Y6/WzDsnb9uR9YHf6UgTIObNdNMUXZOJ+nAaalR0yQcwoeQJ8gQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 12 Nov 2020 21:23:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 1023C2639B17; Thu, 12 Nov 2020 16:23:22 -0500 (EST) Date: 12 Nov 2020 16:23:22 -0500 Message-Id: <20201112212323.1023C2639B17@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu In-Reply-To: <5bc82960-70a4-3ce2-4e3d-a39dd974334c@wisc.edu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 21:26:02 -0000 In article <5bc82960-70a4-3ce2-4e3d-a39dd974334c@wisc.edu> you write: >If tree walking is a thing that comes to fruition, what does it mean for a domain to be an organizational >domain (in reference to the idea that the DMARC spec will just point to another doc to determine the org >domain)? Aren't all parent domains org domains of their children? Or is there something special about >the "top" org domain that I'm not understanding? If we switch to a tree walk I would expect that rather than a formal org domain we'd call it parent default or something like that, meaning the next name up the tree that has a DMARC record. The semantics are definitely not the same. You now can put a DMARC record on a name below the org domain to shadow a subtree, but I don't think that is a problem that needs to be solved. From nobody Thu Nov 12 13:31:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF023A09E5 for ; Thu, 12 Nov 2020 13:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vVqzQ0iagFs for ; Thu, 12 Nov 2020 13:31:34 -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 6BAA53A0E55 for ; Thu, 12 Nov 2020 13:31:34 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ACLZ154032157 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2020 13:35:04 -0800 Reply-To: dcrocker@bbiw.net To: dmarc@ietf.org References: <20201112212323.1023C2639B17@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <85b5b3ac-1072-3f8f-b473-e688f5885dd5@dcrocker.net> Date: Thu, 12 Nov 2020 13:31:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201112212323.1023C2639B17@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] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 21:31:40 -0000 On 11/12/2020 1:23 PM, John Levine wrote: > The semantics are definitely not the same. You now can put a DMARC > record on a name below the org domain to shadow a subtree, that's why the group should first focus on the semantics it wants/doesn't want, independent of how the semantics are achieved. The statement of what is wanted should be administrative/authority language, not technical language. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 12 14:58:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6AC3A0E9B for ; Thu, 12 Nov 2020 14:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5clp_daeRAt for ; Thu, 12 Nov 2020 14:58:06 -0800 (PST) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 B34693A0E99 for ; Thu, 12 Nov 2020 14:58:06 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QJP03IVKGN22I80@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Thu, 12 Nov 2020 16:47:26 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.12.223917, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.10.22.5770001, SenderIP=[104.47.59.177] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HzB0/8t5/9X3ZTOyypiMkwzhfFlZBE3qJ8oSaddM3fWAzVvnxKEelTRBDazFwQ99E8MTZbNA81UnJAd/1BEFvEo/DPOEsh9vYJjPQqs13VARbPC7A9YlOAfuaUgElVBNt7jGAxk379nPEAGvJaoyXCoLJ0T3cNSi81s+R05VFX0HkGJoNcVA5BwZYgYQktcYWpdhaB4bxp/yJycviCG4AxCUSxNPY4+j1V8HB+Zx2SchJjKTJzDkSOtwynMyvYWV4mDnSmFF3E8u9hX/vC4yscQpdlBEZcWkcIttTA6I91kooffriiOuSyJTRqsqvYtyC2OWcJCeLfhIESwE8RNodA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZOR2zWSpEn9q6a9WagOilNxnVNlHjD2j4VlKIcPpHGc=; b=nKoMp33k2svCP9cZX9JIwo0yXZ1MVhOnlLZB3vmPF79oM7dFFpCb5C19HwSfJAb2x4n0YW0b+Xae820IjLIAsg9OvZ1E3+sVMeqx2DCZHMzz1zgorgKrEkeKkaDruKkNtHOKQgtEoUJVHi+MSvmBee+p1ch6byVacQwOhyT0BU50XE65kPGL+w73M2Goq+uZ2Zxv0I5X3HaKp2WYplcsqDEW05DMdPD6eGLa3uHWJU+BiPNcDNhEjK00brR1sbG1T3pLYGk/MjwuFkJfyIGwWOU/x1kWY07MZ+2fa4tPS2BV8npWlPeMdkGFLX/ppFw2ciXpMkXbg+/UMGJOjLcIsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZOR2zWSpEn9q6a9WagOilNxnVNlHjD2j4VlKIcPpHGc=; b=UDClagoy1zQo2/Vqo5DFPMfzmMNCsDGZimOUvU9DmEefgNjC4YipuPSUXwt2zEv0cNAZaUB5fGNzAzmkn4OuaqzAWNvgXcHLU/oGbw+66MMopo790ECZZ7tnqNMvBYqDnhCeWQhJqgo97PMThrJFy/Th+bPo7kugFXTRPDi3Reo= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7350.namprd06.prod.outlook.com (2603:10b6:510:5b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Thu, 12 Nov 2020 22:47:25 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98%7]) with mapi id 15.20.3499.032; Thu, 12 Nov 2020 22:47:25 +0000 To: dmarc@ietf.org References: <20201112212323.1023C2639B17@ary.qy> From: Jesse Thompson Message-id: <4266a992-7064-d8cd-660b-a3d1d4098161@wisc.edu> Date: Thu, 12 Nov 2020 16:47:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 In-reply-to: <20201112212323.1023C2639B17@ary.qy> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH2PR08CA0026.namprd08.prod.outlook.com (2603:10b6:610:5a::36) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR08CA0026.namprd08.prod.outlook.com (2603:10b6:610:5a::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Thu, 12 Nov 2020 22:47:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 093f0865-e47a-440f-ba2f-08d8875cecc5 X-MS-TrafficTypeDiagnostic: PH0PR06MB7350: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8Aa1RMnZpe1wE++NXOXpUYBytYyzNoMm9GXJ6HNUkbKfYnKx0QUUrqjdLooC8G3NYPtyQK3oqqW1Ib5XlFVTxp5Tc0/uPV0nhRmoZGkh2Oxs8Ifz7IHFMPFCpGDqRfOKJZ7RUPgXoAHMZ6ylWRVxQRYha+DYqJQHh7OeVRNOC7w4WbWWcCj30OeonzEuMMSAfvfdrxuORKs9mhMNomh5Zk/kPIFIi5h7k7F2Fx5U/XeWFPlBo4WX3lijn42zTyBsqver0Tqtqz1ySaI1MNXThNIaqiuP645+yyZO8k1439XVZzsw+Pg9KXH2mJGDrGDEgd+jGyExWPVpfErM2sBS3SuUNMg9u2L0n5bzAieVa1VdblCGb0sRIJqlbP/LDrzidiCXpaweVM6pj2W3t5QZe8oQwQX4r1ZQrzi+m73aBzE= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(366004)(376002)(136003)(396003)(8676002)(83380400001)(6916009)(2906002)(86362001)(66946007)(5660300002)(8936002)(26005)(66476007)(6486002)(53546011)(316002)(186003)(16526019)(16576012)(956004)(31696002)(44832011)(786003)(2616005)(6706004)(36756003)(31686004)(66556008)(478600001)(75432002)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: pBSagB7sATZnRiDVnfpbjtOKK3WjzNn77tjCIDyGCmJcjZhqyTxTklDqpuNq27l0vYa4psQEK2WURBrO1ufhS3x/pGW12Mw1oCuIYW3Sl61gizLm2r0AnZCI47mr0D/ahvnH++4zy935h2QS8Yw0w5vi4tprKd2j8mXt9UiSGsZWrbZ93OXf9pIVeq06qc65vOJztFxyB2L+7J2rMDQOrIwvmyt7NB5BevXZLQ/s4XMAyuD4TcVdzDvh40JF4QMZJKzNH6qGlRgUOservO6JGB+ejCPeZM9Ds2PT9Mr34eE6m7M7nA7GfLasR2E/1pUM5HO3JQEiCiEaL9Xw6TZDi/ktQ8ZeJmlIIQSK4Gn8xqecJfUrxaNPuRtSE0bRB9AxaA+Mvzx9lcP4dDD7w9bXf72ymqqo6nm6OcjmhhChns+cLT3cD1/n4J3j32gP7cmkyER7xmo0QHPT0Wrz2emH7/sN1TO7/3C04qaHvA0i07lrXt1xqXQ71bxlQNqHeZomJA+5e2Ue/nWfHD2jCdOlbaFsC3Wxhw0O1WHrK6VwwrXUU6T92qk2mgko0AXQaG/5YXfjW5LFTrd4zGDPWadKBCTceZnpcuZfOO5bZozovoLD+ZwgRfSR1uN+OhoRRetjRcG2QnDUl9j1NPxJ3XdJug== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 093f0865-e47a-440f-ba2f-08d8875cecc5 X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2020 22:47:25.4038 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: wsxOrkgVbrLeqwiYo1TqQ4eD0eqIjBD3IFfzruy6hPwuliXD4TL7aeVwCU2xK5nuo5Kv7Gy1ZNevYGPPUcnn3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7350 Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 22:58:09 -0000 On 11/12/20 3:23 PM, John Levine wrote: > You now can put a DMARC > record on a name below the org domain to shadow a subtree, but I don't > think that is a problem that needs to be solved. I'm confused by this statement. Are you saying that you can "now" do subtree shadowing with sp? as in the following language is being changed "now"? "Note that "sp" will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism described in Section 6.6.3." Or that you meant to say "not" instead of "now" - which is more accurate to current state, I think. I would assert that for "sp" to be realistically achievable (i.e. the policy coverage for the non-existant and long tail of domain/host names that *shouldn't* be sending unauthenticated email) for a complex organization this is a problem that needs to be solved. To further clarify the use case for walking the tree: it allows us to put sp=reject on the org domain (backstopping the problem) and contain legacy environments to solve through reconfiguration/attrition by setting sp=none on the applicable 3rd/4th-level domains. Jesse From nobody Thu Nov 12 15:06:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60373A0EB3 for ; Thu, 12 Nov 2020 15:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOezDf0xa1-e for ; Thu, 12 Nov 2020 15:06:13 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605CE3A0EBA for ; Thu, 12 Nov 2020 15:06:13 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id z2so6816148ilh.11 for ; Thu, 12 Nov 2020 15:06:13 -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=NFHHy4bszMeb0Lqq0mBPIGnrPvNSz+X56oveQu/XdOc=; b=LjwiCjcp5pyK1bkFtjEKZZl2kBe+Di8oP0Z97b7dvj6EWxwJzeCKumQi9l/HeDvbdS zMgPqaPrMG84Z1MfVtd9SMJOiupoRy2RPXc2yBOeoXIJ4cLq3z7+mdwxLjDGl8oKpF6O GSFI8H7WZhjQMk6wPyvO3F1ZZswqVaWMHtJtQ= 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=NFHHy4bszMeb0Lqq0mBPIGnrPvNSz+X56oveQu/XdOc=; b=jLhl1SHk+tkImOM5GDwev0JHQ0Wrd8+LIVFn+SICeKALhnRcS/lxK4qtTCRJMP+6Bx hx0fX4NLJDOI8mZnkih7vGrCxFSdZ3km95cM3qSKTKbAy/NR1aDNZa2EPpk2rwvY2Dvi vwknCNuygRZnLx+QgRmq9tqa5hR35z9wd6HM0PrsZf1eyaYhZs4kt3TOzxZuLe/qwK/T FPcc18qOBLRnuOhYeixKBE0nhmx87q7HUlm8Us3pWtAKfHnuHtyKHRIa2jCYOAywKEsO RmlcEqQZWUMHM+8+LD64FrfQUCN5HZOz0NJEbC1jinf6Yxtf56Ydsd/nsYrLr5AnruR2 +gtQ== X-Gm-Message-State: AOAM532pqPoceQofhxMYXa95URhYIyANHMyl8ETaaiwPFxzQfn6YlKcK 5RgFAGomq7KeSfswf7w5qADKOP7R1HXoVCbnZlidKA== X-Google-Smtp-Source: ABdhPJxnGXbx4kJS1gzQfyYUIiDkSyEuUKr9ZmBLtGeYy0BcJrlZuH0+mfziBQ1BsjEqIyPlFOeDhLRsxHIYuPD2JDE= X-Received: by 2002:a05:6e02:481:: with SMTP id b1mr1481944ils.104.1605222372368; Thu, 12 Nov 2020 15:06:12 -0800 (PST) MIME-Version: 1.0 References: <20201112212323.1023C2639B17@ary.qy> <4266a992-7064-d8cd-660b-a3d1d4098161@wisc.edu> In-Reply-To: <4266a992-7064-d8cd-660b-a3d1d4098161@wisc.edu> From: "Kurt Andersen (b)" Date: Thu, 12 Nov 2020 15:06:01 -0800 Message-ID: To: Jesse Thompson Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004a858b05b3f0f551" Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 12 Nov 2020 23:06:15 -0000 --0000000000004a858b05b3f0f551 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson wrote: > On 11/12/20 3:23 PM, John Levine wrote: > > You now can put a DMARC > > record on a name below the org domain to shadow a subtree, but I don't > > think that is a problem that needs to be solved. > > I'm confused by this statement. Are you saying that you can "now" do > subtree shadowing with sp? as in the following language is being changed > "now"? > I think that John was referring the potential future state where tree-walks were being done, but even then I don't think it would work quite that easily. A record at "a.b.example" would not shadow "x.y.a.b.example" if "x" or "y" chose to express some policy. --Kurt --0000000000004a858b05b3f0f551 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 12, 2020 at 2:58 PM Jesse Tho= mpson <jesse.thompson=3D40w= isc.edu@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 11/12/20 3:23 PM, John = Levine wrote:
> You now can put a DMARC
> record on a name below the org domain to shadow a subtree, but I don&#= 39;t
> think that is a problem that needs to be solved.

I'm confused by this statement.=C2=A0 Are you saying that you can "= ;now" do subtree shadowing with sp?=C2=A0 as in the following language= is being changed "now"?

I th= ink that John was referring the potential future state where tree-walks wer= e being done, but even then I don't think it would work quite that easi= ly. A record at "a.b.example" would not shadow "x.y.a.b.exam= ple" if "x" or "y" chose to express some policy.

--Kurt=C2=A0
--0000000000004a858b05b3f0f551-- From nobody Thu Nov 12 17:26:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5433A11D9 for ; Thu, 12 Nov 2020 17:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=GsvvoQfW; dkim=pass (2048-bit key) header.d=taugh.com header.b=HDNx3wSD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6J-9lVh09rM for ; Thu, 12 Nov 2020 17:26:36 -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 B19953A11DC for ; Thu, 12 Nov 2020 17:26:36 -0800 (PST) Received: (qmail 92992 invoked from network); 13 Nov 2020 01:26:35 -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:cleverness; s=16b3e.5fade0cb.k2011; bh=0qiHO7Y4/KFXCuI325/zhxOQBxBjj7VrDZeQVAZz6+4=; b=GsvvoQfWFWQFrXa2E++CMlUcyA0SoZX8+Q1BLIbtPvM21X9nzCFvTUEKOcR0IaEgDQa9ifhvZpDZORgalsM9Ij/jusAIJlgPEjOE+hhONtbqkJBs3ROSsdzvqDwlUxTa3FQTEJC2s7FJ6NJEmjF785kTWwj0BQfgerHgYwDIqTaeHHVkRPz5cpU374P97oRzZIaLk419NnzCw8Yhf3f+FhQ6xRYFyYtnGZoS6AJjiLf0ENasyM5Cp6ltt41AY1CkXmaku3NNLnQ0Qej2HtALvrO35cmUD7oi1yg/NlvWkfzu9RYBdLUoqRgHRMIhABxYAvRRL9EwV0TVfR7mzSnvtQ== 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:cleverness; s=16b3e.5fade0cb.k2011; bh=0qiHO7Y4/KFXCuI325/zhxOQBxBjj7VrDZeQVAZz6+4=; b=HDNx3wSD7KDCTLFRV+6IaRuohKtjDkrhgq4RbOOTTWdCvVI/k61GQl3/1k1a/ibkhYPb0y1Fm9RyNQ0pVjWtHs/yjxCrPrYf2ljcCemrQg2rTq/FOlwsfwpyDmz7JAbWW5tnCeLhN35F4CCmSwVaEtuvAAhUUzSsjo/mNJ6bIkK1fvFzim88etDsKK9OCccI2SUxSm4kv7izE2Y/ppvh4VFKXDMvgxaTWYS+xThAjBN3Jzgao3xYbG+bAYcRMB8M2cbFg+sELOVC88tDYKEFH6aUGawt9cYzF7B4PIC71f43zv9nibxStCls1fFNTPJc6B/uhpxVboGwdhe3GLRjxA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Nov 2020 01:26:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 77FDA263BF02; Thu, 12 Nov 2020 20:26:33 -0500 (EST) Date: 12 Nov 2020 20:26:33 -0500 Message-Id: <20201113012634.77FDA263BF02@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu In-Reply-To: <4266a992-7064-d8cd-660b-a3d1d4098161@wisc.edu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 01:26:39 -0000 In article <4266a992-7064-d8cd-660b-a3d1d4098161@wisc.edu> you write: >On 11/12/20 3:23 PM, John Levine wrote: >> You now can put a DMARC >> record on a name below the org domain to shadow a subtree, but I don't >> think that is a problem that needs to be solved. > >I'm confused by this statement. Are you saying that you can "now" do subtree shadowing with sp? as in >the following language is being changed "now"? Poor choice of words. "now" -> "if we switch to a tree walk" R's, John From nobody Thu Nov 12 18:13:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041573A12C3 for ; Thu, 12 Nov 2020 18:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIxgBeMX-Alr for ; Thu, 12 Nov 2020 18:13:24 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 620C53A1385 for ; Thu, 12 Nov 2020 18:13:05 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id y197so7576722qkb.7 for ; Thu, 12 Nov 2020 18:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zrNGZFJ+sNJ9IlpOr7db7l51jOCf8bvGSsHQEmNyslQ=; b=Q+Rk+r2SEh45HqZRF9c8N3oGNvhw3GUp0RocHWuhlx6o3Ey0IU3QMVc7RJItVHWZ4Y k/Qr+JmbGBGltrTvwqmH2w706Z4EKYIUCtZ5aCMA8HYLHG4c+vKZlQzbIYzmk87wSLFX /rWdueaYi4ci9NRCHYDR6/Xv3mL4leayUUQ4kGkPI5aGpgd2SF/aqCDe/+L6GoyIbKa+ i9px2ZBwQM4XgSFxNrlmaBsjiE35RvSObwEwWeTwLocfXQEsN242Rx3apVORUsIdNFIq f6FDZ3KNdOXkw4NrZHTgmV0HL6JHr0wGA2D8OhLJ8b2Facd9B/q+HIBynXbw1NLagvCg QpSQ== 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=zrNGZFJ+sNJ9IlpOr7db7l51jOCf8bvGSsHQEmNyslQ=; b=BfbdYzws4fR3KM8QRhYoNDsWwc2TIbsPtKknZehIG+X85/DlDalTD5puAapHrgg0Fh BZLJNC+ADa5FX8Nrk9zb5ijmjxonppsUqWMnyiFdXLx2P+h2dg0WPg/h4CizsQ06SFaw 1pBXCATzQP8YPHjr4HuqraBxRA7bnn4DfB7QbrSgC0yMopVQde7gwoVZOpP+/1g0p6St aPgUVJ2LY2yo1vruJlBBeHjTDc9JA+ihszGtLgF5P74+BE2ov2XEKxbHyGWD+FPntgco 2kNAJDJNoxy3IC/My9jge2Hgd1Ke7pun6WlpSOdQc35xc4qQONecq51HjqtBkqVlbTTc 1tcQ== X-Gm-Message-State: AOAM533sVh61kBjiWpOTanvzN0b7HSnMICkafZbBQe0KagupTubNmgF6 V5mQoLNEAUbxwrOOceUCbi47obDV3cJ87UPyDoc= X-Google-Smtp-Source: ABdhPJwqUzQjrfgJI/YUxRAtrYVLIHi5vbKUuZaiEmPmm0JumGY0PKbkUbyPDjqJ5ySuipFUXVPasQ52YxZ4l5vOxpA= X-Received: by 2002:a05:620a:1521:: with SMTP id n1mr35517qkk.187.1605233584372; Thu, 12 Nov 2020 18:13:04 -0800 (PST) MIME-Version: 1.0 References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> In-Reply-To: From: Dotzero Date: Thu, 12 Nov 2020 21:12:52 -0500 Message-ID: To: Joseph Brennan Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000094016105b3f39101" Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 02:13:26 -0000 --00000000000094016105b3f39101 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 12, 2020 at 9:24 AM Joseph Brennan wrote: > > > On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: > >> >> Just to invoke a bit of ancient history, here, you are saying that if >> there was the domain name: >> >> engineering.sun.com >> >> people would be surprised that the organization domain is >> >> oracle.com > > This just isn't that interesting. I would expect (hope?) that Oracle has enough of a clue to publish records for all it's domains. In my previous work incarnation we did that for roughly 6,000 domains. We also automated generating DKIM keys and signing of emails as well as SPF records. My point is that we are straying from interoperability into the realm of telling people how to do their implementations. Either they know how to do these things or they need to outsource it. It's one thing to to come up with something for subdomains. It's quite another to try and associate random domains (names) with each other. > >> >> > As another case, would people be surprised that email for the medical > center cumc.columbia.edu is a separate system managed by a separate IT > group from columbia.edu, and that any authentication for one should not > be applied to the other? I don't think this is unique in large > decentralized universities. The real email world is a complicated place. > > The simple solution is for cumc.columbia.eduto publish its own record. Done. Michael Hammer --00000000000094016105b3f39101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 12, 2020 at 9:24 AM Josep= h Brennan <brennan@columbia.edu<= /a>> wrote:
<= div dir=3D"ltr">


On Wed, Nov 11, 2020= at 4:21 PM Dave Crocker <dhc@dcrocker.net> wrote:

Just to invoke a bit of ancient history, here, you are saying that if
there was the domain name:

=C2=A0 =C2=A0 engineering.sun.com

people would be surprised that the organization domain is

=C2=A0 =C2=A0 oracle.com

This just isn't that interesting. I would expect (hope?) that = Oracle has enough of a clue to publish records for all it's domains. In= my previous work incarnation we did that for roughly 6,000 domains. We als= o automated generating DKIM keys and signing of emails as well as SPF recor= ds. My point is that we are straying from interoperability into the realm o= f telling people how to do their implementations. Either they know how to d= o these things or they need to outsource it.

It= 9;s one thing to to come up with something for subdomains. It's quite a= nother to try and associate random domains (names) with each other.



As another case, would peo= ple be surprised that email for the medical center cumc.columbia.edu is a separate system m= anaged by a separate IT group from columbia.edu, and that any authentication=C2=A0for one shou= ld=C2=A0not be applied to the other?=C2=A0 I don't think this=C2=A0is u= nique in large decentralized universities. The real email world is a compli= cated place.


The = simple solution is for=C2=A0=20 cumc.columbia.eduto publish its own record. Done.

--00000000000094016105b3f39101-- From nobody Thu Nov 12 18:23:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B53A1385 for ; Thu, 12 Nov 2020 18:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaxOi6KD0MNg for ; Thu, 12 Nov 2020 18:23:04 -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 5A6C23A12E2 for ; Thu, 12 Nov 2020 18:23:04 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AD2QXOC029477 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2020 18:26:34 -0800 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <1278d81d-3562-3692-c5d3-bd1478053f0d@dcrocker.net> Date: Thu, 12 Nov 2020 18:22:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.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] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 02:23:05 -0000 On 11/12/2020 6:12 PM, Dotzero wrote: > > engineering.sun.com > > people would be surprised that the organization domain is > > oracle.com > > > This just isn't that interesting. I would expect (hope?) that Oracle has > enough of a clue to publish records for all it's domains. ... > It's one thing to to come up with something for subdomains. It's quite > another to try and associate random domains (names) with each other. ...> The simple solution is for cumc.columbia.edu > to publish its own record. Done. +10 This goes to the heart of a very basic challenge, when producing standards: try to solve a narrow, clear, entirely pragmatic and immediate issue, versus try to provide a more general solution that covers appealing issues which might not have immediate need (or that can be satisfied with approaches that have less appeal, in terms of engineering aesthetics. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Nov 13 04:25:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875363A0799 for ; Fri, 13 Nov 2020 04:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2iXK1l7B0I0 for ; Fri, 13 Nov 2020 04:25:03 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5FE3A0121 for ; Fri, 13 Nov 2020 04:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605270299; bh=cvV07DveXf7DSlRcLpu5GeF6gAI/1a0A7hzVnouKIhs=; l=1035; h=To:References:From:Date:In-Reply-To; b=Ch5sqAq+lz3JqLTRNEdqH4IFXo8Y9+GtCPDrCApznsAwqwqAxYZ2PCNj17CTsJCqC Bh2FWAoDwkCKUvRs9y+1YNRvHOEMMbBPkC3NYjiXLy7CWkvl+X19RX9REDN3xXw42A Cp8J4gSARHOgBSxyQf4WcFlrBi/FC/p+GPO55YDR+D3KYRdlfh/9jdhReEEdd Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC083.000000005FAE7B1B.000040EE; Fri, 13 Nov 2020 13:24:59 +0100 To: dmarc@ietf.org References: <20201112212323.1023C2639B17@ary.qy> <85b5b3ac-1072-3f8f-b473-e688f5885dd5@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Fri, 13 Nov 2020 13:24:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <85b5b3ac-1072-3f8f-b473-e688f5885dd5@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 12:25:05 -0000 On Thu 12/Nov/2020 22:31:25 +0100 Dave Crocker wrote: > On 11/12/2020 1:23 PM, John Levine wrote: >> The semantics are definitely not the same. You now can put a DMARC >> record on a name below the org domain to shadow a subtree, > > > that's why the group should first focus on the semantics it wants/doesn't want, > independent of how the semantics are achieved.  The statement of what is wanted > should be administrative/authority language, not technical language. Agreed. And I don't think that a tree walk would match DMARC semantics. AIUI, the Organizational Domain must be a domain recognized by all "subdomains" as authoritative on policies. Of course, if every organization had the ability to generate DNS records for each domain, there would've been no need to use the PSL. SPF experience taught that even "smart" organizations may lack the ability to do so. Hence, the Organizational Domain must be such that its admins are entitled to generate those records if they wanted to. Best Ale -- From nobody Fri Nov 13 06:46:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8CF3A0D51 for ; Fri, 13 Nov 2020 06:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.468 X-Spam-Level: X-Spam-Status: No, score=-0.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZDHbgsi6QCh for ; Fri, 13 Nov 2020 06:46:37 -0800 (PST) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 04B0A3A0CDB for ; Fri, 13 Nov 2020 06:46:36 -0800 (PST) Received: from pps.filterd (m0167077.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ADEUiKb007179 for ; Fri, 13 Nov 2020 09:46:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=QNfUBeezBia+pntA9atw562droM8bmCBcBMOcfhdnYk=; b=X854eLfX+CTPJFDvId9dnGX1o9XKVjOsl8ZslDXgbRLL81s1JKSYQR2ZyU7GZ+pfg5pV ne8S/b4h/h8lsYOPulPNX0l6dK+FlmGX7Y2oyNYrobgb3PDvewBfM4HVFUEKMssBSXSp GpyEsIFJBoz28uHJ/kn4MDMUvinAPmgcJKz8RJHlAIh4jjP9upSp3YSdHYwZ31P73P0m Rx4YZ7iUjt0P70OIMJMfJX98VjMBG2g5LW9E46TITGqUEpYjk+agop2181cbfakdzjGl yJB1ypu8ragmnW3LgaYUnF9SU3JfE3xX1NWXuc775bTBq5iM2eDAMW8R6XDA/NqSLk02 /A== Received: from sendprdmail21.cc.columbia.edu (sendprdmail21.cc.columbia.edu [128.59.72.23]) by mx0b-00364e01.pphosted.com with ESMTP id 34np1y8phu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 13 Nov 2020 09:46:36 -0500 Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by sendprdmail21.cc.columbia.edu (8.14.7/8.14.4) with ESMTP id 0ADEkZFW031248 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 13 Nov 2020 09:46:35 -0500 Received: by mail-io1-f72.google.com with SMTP id c2so6503770ioq.7 for ; Fri, 13 Nov 2020 06:46:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QNfUBeezBia+pntA9atw562droM8bmCBcBMOcfhdnYk=; b=l8Wd0DlzFYAinnGgxCZ6x/UZZ4AskmLZZnq2cM8RhvW8p24qm4+7zZDb1zt+hcLQmN vXkj4/fntYhFwgLKy9HbLIYwbZXGlEQNhDy3vE5Jj/aYfk+Pj3z8bWtmNUzeHKOofNXJ JbycdU68bfzeJ6G5uwQitqe+jY63A/Vti9RlB60H02GxlPpb43Slpq6cTXZF9iDmTqxd qWm9HmufEMNBukaqD0GDFrqEt8tIKM5LU5Ig0RvMxeZ2qBTCrHPV1lM+Xpb6/3/RbM29 XZkpxDaZG8zW7axIP/rmT9/iy32rGqhAsDd6ZuioF4Y0anx4FROmpqcujktvuwT1N7hG ivQw== X-Gm-Message-State: AOAM533D0Ye+GXuBAlzT/B0/U2peRcOWk6Lw+TKPqliIUKUsxKkgmkfE XcmOpgjzkC6l9w2bKMrs+Hwa8AgPZ4PY/rAXShzzwyOQYE0muRVO9u28Cm+zaKWIEnwjRUbGEf0 ay7Zg1yQXZRzVJ3di4Wq6KnrubTGmCg== X-Received: by 2002:a05:6e02:1114:: with SMTP id u20mr140433ilk.226.1605278794766; Fri, 13 Nov 2020 06:46:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJyFt8XyRIVLpvyG/S1GiJQr7sneS5d4eL4Nil2drh2QmdUwdEf0EwGReFrqMaF5YppWbW4Q5Nsh4qvmHxxk8nk= X-Received: by 2002:a05:6e02:1114:: with SMTP id u20mr140414ilk.226.1605278794421; Fri, 13 Nov 2020 06:46:34 -0800 (PST) MIME-Version: 1.0 References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> In-Reply-To: From: Joseph Brennan Date: Fri, 13 Nov 2020 09:46:23 -0500 Message-ID: To: Dotzero Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004ead6b05b3fe18a9" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 lowpriorityscore=10 mlxlogscore=674 clxscore=1015 impostorscore=10 mlxscore=0 suspectscore=2 priorityscore=1501 bulkscore=10 malwarescore=0 phishscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130091 Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 14:46:39 -0000 --0000000000004ead6b05b3fe18a9 Content-Type: text/plain; charset="UTF-8" > >> As another case, would people be surprised that email for the medical >> center cumc.columbia.edu is a separate system managed by a separate IT >> group from columbia.edu, and that any authentication for one should not >> be applied to the other? I don't think this is unique in large >> decentralized universities. The real email world is a complicated place. >> >> > The simple solution is for cumc.columbia.eduto publish its own record. > Done. > > Michael Hammer > I don't think I have the right to force the owner of another domain to publish dmarc. The owner of the other domain may want to allow users in their domain to contribute to lists and groups without having their messages rejected, or mangled by well-intentioned workarounds. This is not simple. This is a real-world case with the domains ending columbia.edu. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --0000000000004ead6b05b3fe18a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


--=C2=A0
=
Joseph Brennan
Lead, Email and Systems Applic= ations
Columbia University Information Technology


--0000000000004ead6b05b3fe18a9-- From nobody Fri Nov 13 07:04:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640693A0D87 for ; Fri, 13 Nov 2020 07:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7tT_agK8gDi for ; Fri, 13 Nov 2020 07:04:27 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 B11A73A0D7B for ; Fri, 13 Nov 2020 07:03:48 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id 199so9004675qkg.9 for ; Fri, 13 Nov 2020 07:03:48 -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=0fBut46YAg8iVlrif4Qth68/9AKkGsDRSd72EsC6h+A=; b=f1nrQbStYednZOGY/2f8HGplzN3mRzfOi9k7ZAkob/vONheFze1XSRFCqsjDlyt4Qc oi6n6qARk2vlsyUiE1+a+fftq2jNaJkLqqd/t2tuUfxnROZwJtHyqmS9eTiGxT6mNyoF wTVClzIq+G1aLcbb5+ynD9X/5jQ7hWJ/jHcBJ8jtPgPi/TQnVThKe54qAYqx5Eulhbtu 91dGNLQIP5QRPcvTtrPNhoIKZzcmPa/yDGNm9NbV1IH8dfeQoRAu7kkgBSsrl4Tay4+y 9tRq8JCQQ2uFXVjVapkbZfrkQIDQKVuJ4GorogA/pS6QGVuU0XDlMMKSZCSPg7LEb/1j PYoQ== 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=0fBut46YAg8iVlrif4Qth68/9AKkGsDRSd72EsC6h+A=; b=ohIId6jibdSFjwmFw8AW6PXAcECqmLFp2nbfyuIsyJv9QQoGn5EmuSjJdtjaEh9Kz/ bhEmR4WI7SPkP3U5AgzCcZBqdNcK5JXaMR9YPUX43ZTKvf/sz3N/VgIqoJM5MJE1k1IX t7BixisLBNMtAaK5WShF1tWi0M9327g8ObnRqKGMZwjORFicR1u1jFD2qdja7lzp0pT5 n8o37SGEyVds8WTDH+Av43t9m2iHQ5Y1bFqbY0mrMvURp+3IcAFrAPL4u3F3x4pNyeYC hC66+v/HiWqxHmjFtp59nD5TfYz8i/l35I1bIO1mnrKqHSUR+g0O5X0Z5mzKJzuLZNy6 auyg== X-Gm-Message-State: AOAM5324Z/BuUso742bcSH5oSZ/BIU/qsmt952BpcQFD3AJfAQ7BQC7J qO2By8g+FnNyVcfBYPjjRw1JyjQwSkyh8j2yeBM= X-Google-Smtp-Source: ABdhPJxTn80R8xP/FUrDvCg6/dzk90xCiiKu9krXieuzOuN7jadem6LBhQNQnTDpVxDO3edHY5SGuB4w49+/gUnk6eM= X-Received: by 2002:a37:ef04:: with SMTP id j4mr2525864qkk.368.1605279827729; Fri, 13 Nov 2020 07:03:47 -0800 (PST) MIME-Version: 1.0 References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> In-Reply-To: From: Dotzero Date: Fri, 13 Nov 2020 10:03:35 -0500 Message-ID: To: Joseph Brennan Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e5a05605b3fe5560" Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 15:04:29 -0000 --000000000000e5a05605b3fe5560 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan wrote: > > >>> As another case, would people be surprised that email for the medical >>> center cumc.columbia.edu is a separate system managed by a separate IT >>> group from columbia.edu, and that any authentication for one should not >>> be applied to the other? I don't think this is unique in large >>> decentralized universities. The real email world is a complicated place. >>> >>> >> The simple solution is for cumc.columbia.eduto publish its own record. >> Done. >> >> Michael Hammer >> > > I don't think I have the right to force the owner of another domain to > publish dmarc. The owner of the other domain may want to allow users in > their domain to contribute to lists and groups without having their > messages rejected, or mangled by well-intentioned workarounds. This is not > simple. This is a real-world case with the domains ending columbia.edu. > If CUMC publishes a DMARC record for cumc.columbia.edu, how is it forcing another domain to do anything? As far as "owner of a domain", If Columbia University registered the domain columbia.edu, then CUMC is using the subdomain because Columbia University is allowing it to, presumably through some sort of written agreement. A technical standards body cannot address business and contractual arrangement in the manner you appear to be asking. If Columbia University stopped delegating the subdomain cumc.columbia.edu, would you turn to the IETF for redress? Michael Hammer --000000000000e5a05605b3fe5560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 13, 2020 at 9:46 AM Josep= h Brennan <brennan@columbia.edu<= /a>> wrote:
<= div dir=3D"ltr">

As another case, would people be surprised that email for the medica= l center cumc.columb= ia.edu is a separate system managed by a separate IT group from columbia.edu, and that any a= uthentication=C2=A0for one should=C2=A0not be applied to the other?=C2=A0 I= don't think this=C2=A0is unique in large decentralized universities. T= he real email world is a complicated place.


The simple solution is for=C2=A0=20 cumc.columbia.eduto publish its own record. Done.



=
If CUMC publishes a DMARC record for cumc.columbia.edu, how is it forcing another domain to do any= thing? As far as "owner of a domain", If Columbia University regi= stered the domain columbia.edu, then CU= MC is using the subdomain because Columbia University is allowing it to, pr= esumably through some sort of written agreement. A technical standards body= cannot address business and contractual arrangement in the manner you appe= ar to be asking. If Columbia University stopped delegating the subdomain cumc.columbia.edu, would you turn to= the IETF for redress?=C2=A0=C2=A0

Michael Hammer<= br>
--000000000000e5a05605b3fe5560-- From nobody Fri Nov 13 07:17:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54CD3A0D95 for ; Fri, 13 Nov 2020 07:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LifvAMY2_vO for ; Fri, 13 Nov 2020 07:17:15 -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 C05663A0D93 for ; Fri, 13 Nov 2020 07:17:15 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ADFKheU005481 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 13 Nov 2020 07:20:44 -0800 Reply-To: dcrocker@bbiw.net To: Joseph Brennan Cc: IETF DMARC WG References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 13 Nov 2020 07:17:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.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] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 15:17:17 -0000 On 11/13/2020 6:46 AM, Joseph Brennan wrote: > The simple solution is for cumc.columbia.edu > to publish its own record. Done. > > Michael Hammer > > > I don't think I have the right to force the owner of another domain to > publish dmarc. The owner of the other domain may want to allow users in > their domain to contribute to lists and groups without having their > messages rejected, or mangled by well-intentioned workarounds. This is > not simple. This is a real-world case with the domains ending > columbia.edu . I'm not sure how 'forcing' is involved here, but let's make sure we have the same foundation for discussion: A domain name falls under an administrative authority. Names above or below this domain name might fall under the same, or a different, authority. An administrative authority has the responsibility for setting policies for the domains over which it has authority. The discussion, here, concerns finding a domain that is the 'top' of an administrative authority hierarchy, in order to discern a possible, default dmarc record. While there has sometimes been discussion about whether that default in fact can override a specific domain's DMARC record's attributes, I believe the accepted view is that it is applied only in the absence of a specific domain's dmarc record, rather than being applied to selectively modify one. An administrative authority might set a strict default, such as d=reject. Any subordinate domain, within that authority, can override this by merely publishing its own record with a different set of parameters, such as d=none. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Nov 13 08:55:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8563A0F0E for ; Fri, 13 Nov 2020 08:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKNQQPtXTBG6 for ; Fri, 13 Nov 2020 08:55:36 -0800 (PST) Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 A18B93A0F0B for ; Fri, 13 Nov 2020 08:55:36 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QJQ003S6UV7IP00@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 13 Nov 2020 10:52:19 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.13.164217, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.10.22.5770001, SenderIP=[104.47.56.174] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+pjHX7+P/Foa/PjAWFrcCg7+ueLx0hmwiunBKzYXeWasPi6Ld0ryyV0mx3V3K0UpTEKUS3XDWTKrqFnGRrc8fb4cea7gFd3A4OQnvSwK4ieaa0PtIUdEFdCRedzDK/a91+iCx2SVKzV9ksnt0FqxnU3GOsEE1ftgCX5n95pybA9ip4z85dmlNcPHKVr0VxJxOCyhD35Dc1M2XdszLyuNiRJislSC9Yd1oItNXyJtLYMNIfYD1Y7JoXxTzgJXbaJ9uyHb3WaJoPoCB7fzX8abAooLtuG7nlEk9hMWel4ZJtK2gRTLdwYzJU8jMXMbFlhatAmdzkjpuOnaslTo/9e1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1wJ7rcn7GX3xz5MZqxy3Oz9tcU8aSJPiRTi2yW2g5l8=; b=IR0bOYGbL+iFyGELmv566i4p6ToT7/9BA50tavg/ACgBu3bVQWF1rougEEsqQ9ORPkJPxKiOJnm+qk/5/e2YAGbbhkRrSBkuoS9/lGuHnOGYsvJmGMrulLi1tZJg7AQvekjEqOotxQtSCWDQyJpyEPrbpIHhw4H42BhAFPVkGboEcuoazosiSz2r+vojhkh6rBBgfFeqMN8X+J9vpN7+SGD26E0to/lunBvUvMnqt0pr3BAJ1SR5NFsaECzFPfm5j+FVJ3aHSFsznbt4oPgs6B2xYpF7wXbgN3vGVOW/A5D8e9TixQ/sYHem2m+UZ6DiBugBX+v3Bt/qe77ycPVJ6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1wJ7rcn7GX3xz5MZqxy3Oz9tcU8aSJPiRTi2yW2g5l8=; b=ctqEptxnzJc8OQXigRTC49IBLA6KB5gja87j4AEn+xYFi1mLczYkf8cDZv+xoiW5H32vzuh56y/V+lFY8/T3yvX6cBBhQebTz+b/iPwfYAjo6qExCjQIEyxJ6WTXf8TbFLn3Rhal4fYuDoXleOCBFp+whsnWi9MHTNCYhXHa9Ic= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7543.namprd06.prod.outlook.com (2603:10b6:510:56::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Fri, 13 Nov 2020 16:52:17 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98%7]) with mapi id 15.20.3499.032; Fri, 13 Nov 2020 16:52:17 +0000 To: dmarc@ietf.org References: <20201112212323.1023C2639B17@ary.qy> <4266a992-7064-d8cd-660b-a3d1d4098161@wisc.edu> From: Jesse Thompson Message-id: Date: Fri, 13 Nov 2020 10:52:14 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:610:52::14) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR04CA0004.namprd04.prod.outlook.com (2603:10b6:610:52::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25 via Frontend Transport; Fri, 13 Nov 2020 16:52:16 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b24d018c-1b82-413e-d99a-08d887f47a95 X-MS-TrafficTypeDiagnostic: PH0PR06MB7543: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9CABsswyWtDxHD3Yytj4NWJacEoPUekZl5hG2g/3MvsIvJCO0yoR9QAoY1CWyIyPLLtPw2XCb6iUZ5BC00SxcOGOwjv+efexV4DIXFe86azNzmDNolyHIvUsus70Qo8nrBH8dLXiBcJ3P7lgC8OCmgA/akSDOd4MyseCUo9ivCNxKYc/UdhZBuxsB3PusZCxy9fEDOibSaE5PLWjJ6Vv730WBp7selPtNAcrLwre7nGHW5pIz07SFODs0swVXq6UCtvL43v9RZGnoIsST/AD6dTHrgb76PfEck5bOtbGXpY51njKHo2q5SklMes12fDh55Rtqg1WDdDl6UD3pCW2znGZokz8XwtEw1S91378W8k4xUnw/fDSjuSCWUszKYrF X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(376002)(396003)(136003)(346002)(66556008)(66476007)(478600001)(6916009)(4744005)(44832011)(36756003)(956004)(66946007)(2616005)(31686004)(26005)(186003)(53546011)(16526019)(86362001)(75432002)(8676002)(6486002)(316002)(16576012)(5660300002)(2906002)(786003)(8936002)(31696002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: iY+XsdpTvYRAlf7VzWq1EWSMaXKMDwxluuY5NIEV6ggh+H+nCQCwF/1T4WSpgFyS/Oj/kGZccMQDQWPsEQGTzH4uolZaxQOMOYusziiUUe4FTJqX+SdQPxLlctDPvTzMeru/dljc1YngvXc3iXT9SwsWHUe4w2qmMvoSd8IZGh2SptxyJbeFTJh+mouuaYx9EF8Hfd/IuIHi0D7om7aJuY8UMn8JleKghRcaCZFaxbGbQd8uOf1bB91VWdB3TzK63e8YZnwjHQekkTpSKKzF+iHZs39ZKhp83Q9fsMqD8So1kHhUmzIUiyFEMDS5Jb4ng4eloZmp7f//MAbHLt/+wz+znM76y2aGQ+31z96OfJeNeXkrC80/vMwb9K/E/wxwv5frBR2uYDhx+WHkyI8kqGwlA7AidBJmIbZE/4vKwoXvM2M6M41zzHx2Qyub2fUdTLvvdET9M4oom6tpYfRDU920ITVndr5qfdyUg6LVXwcbudZ73eGbwNiu4SHII2yDgpKOiMHFx8Buu378y9hfkBeYU5Fp6wTalo9DtZgqtraeJrTtFOpjpqb0l6RabEaVUeSqnxJfeN2CUWhn5c0dLlDjrkEtxTZkSifMvR4wYhSyrWC70j3YGuSRhWCgWkkZAK0GvvDQ20tx7KpFXkG7ag== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: b24d018c-1b82-413e-d99a-08d887f47a95 X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2020 16:52:17.4173 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 171uj3wjnRhiabXfV//glIEeBM+L8rod1/s4eJBi1meJFG0JHFAhgsjJafUf5NAQ7bX3tLw/tjOFAUkt6n1nRQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7543 Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 16:55:38 -0000 On 11/12/20 5:06 PM, Kurt Andersen (b) wrote: > On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson > wrote: > > On 11/12/20 3:23 PM, John Levine wrote: > > You now can put a DMARC > > record on a name below the org domain to shadow a subtree, but I don't > > think that is a problem that needs to be solved. > > I'm confused by this statement.  Are you saying that you can "now" do subtree shadowing with sp?  as in the following language is being changed "now"? > > > I think that John was referring the potential future state where tree-walks were being done, but even then I don't think it would work quite that easily. A record at "a.b.example" would not shadow "x.y.a.b.example" if "x" or "y" chose to express some policy. Yes, that makes sense for a defined policy to override any inherited subdomain policy. Jesse From nobody Fri Nov 13 09:10:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215013A0F74 for ; Fri, 13 Nov 2020 09:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2abE7saYgRw for ; Fri, 13 Nov 2020 09:10:37 -0800 (PST) Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 8A9983A0F5E for ; Fri, 13 Nov 2020 09:10:37 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QJQ003YQVNVIP20@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Fri, 13 Nov 2020 11:09:32 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.13.170018, AntiVirus-Engine: 5.77.0, AntiVirus-Data: 2020.10.22.5770001, SenderIP=[104.47.55.172] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cgYad6sHzJZUw+eCyS52AEvU0E+BIvDcSJJeTveHxpDqOEKuy8IQC0NzJySGrAI8oiqL+wxnMf2USHMLCm9vg5b9diqVlddhu/6YerAXiA0DiUL2sdXszib8L4GGhbqzO2f23kAh0jqw9xyK84XsGYw/RunXyswJ9KW/79f1ceVzxRw0UzeQJWYpLn4yKMVwJev8JJPSvysIxnaGxVawmnSdd6z4KvDnxOiFazQ2Y2vj79uh3sH+r1KgtHAxNKrXgoUYVs1yi9E5LcY8ApR92m50Y5zSR9Isp0H6cmX1WPoD0aUj1n6dxLL02TSPmbqTTKqTAKnr795rggnnMt/7DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u/pf5++V9gBl41Cx6RL5kI4STb/BhPSjvN/94ShfW3Y=; b=LsptdN7RfUxfsRFRyfRx5gJJEXQhyIuspASmJ3hgX4+X87pyjBPxrB2S2fiW6hjKuYg4AYXxEqU8cBwWPJsfH7Zizde6Pi+aBqqA2yIyCFwLr9bNn1wPhPn5epgqhIqLaEJFri3g/lpfngkBb5Xy+qFwq15KGvw52PAKNicKUnE1LMr3m6CQxpKWsNkbraGD7sFOIxr/u5da1Rj9cj78BT9WHS7y1QCTw5iNLZzGanPMiTErajI2GSxG6hIrB311CNA7DCZAXiV8zMlAAvUzTTk7CQA68buJBLA5ATtaDr6LVe8WcUZpC74fD+8VyxDpx+VPnSmFap3BW5xAIt68iA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u/pf5++V9gBl41Cx6RL5kI4STb/BhPSjvN/94ShfW3Y=; b=bD9MVj0uELFwWMA3WZtmTqHyO9Gn0ImgkT4A+GRMWO6p86Y8QaH+AGWgjge/Qto7ISPw6jyBusd4UEYxlA0XuiZQv2WQ3zXTVfydynmHAsAXiajamIxZjKIFF1cviGPN8w5f+f5A/UiAuDCsjwhsOvS5Cq5/LDTPv8nm0+ZZaUE= Received: from PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) by PH0PR06MB7559.namprd06.prod.outlook.com (2603:10b6:510:5c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Fri, 13 Nov 2020 17:09:30 +0000 Received: from PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98]) by PH0PR06MB7061.namprd06.prod.outlook.com ([fe80::2106:a617:3a39:fd98%7]) with mapi id 15.20.3499.032; Fri, 13 Nov 2020 17:09:29 +0000 To: dmarc@ietf.org References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> From: Jesse Thompson Message-id: <903acb7d-847e-c87c-f21b-dcfa698bfd89@wisc.edu> Date: Fri, 13 Nov 2020 11:09:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR05CA0058.namprd05.prod.outlook.com (2603:10b6:610:38::35) To PH0PR06MB7061.namprd06.prod.outlook.com (2603:10b6:510:21::8) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR05CA0058.namprd05.prod.outlook.com (2603:10b6:610:38::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.21 via Frontend Transport; Fri, 13 Nov 2020 17:09:29 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: fa38e7e5-82a7-45ca-feea-08d887f6e20f X-MS-TrafficTypeDiagnostic: PH0PR06MB7559: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /AzEyveMEzVVaUzRLTpYTkrQfxcBogI28Wd+xUYW8qN4yqCeK7p1DwjeBagzMeYwo3Yh1Ae0gFvMD9WXcMPDXlmg0unphgG9bzWLkyBxUvgvRJBjFDD1/S03weXSVIR8VSDpOctQmLqo0VWXk3kAyFLp2XMebJ9e3rTI85b7HJGXMR69saFQBOr6xes4aOg7Wc3S3XTzgYXFrRQEJlPGKDA5SYN0WQbB4NBI7bU58zIFobnpksiaT1MNbGgVub9oFQfhc+48eTGwVomNTN3og4hr1ZC+1/Y2ONMEKaIxie8PaME1UzjOyk0rp2MRQv+yU8cmoIMb2DnapV8xN04U8izh38XX+hr+BAJk5k6HwuRiuHM96AlMeCpM4LVOgar14vyabn6bAsy43ua1PrvIP6S9KEwWLhNL443mfPvwaU60B8Un5PRBghq/40g4g0RbmurFZc/7ydWPFZ4D8AeUVQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR06MB7061.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(136003)(39860400002)(366004)(376002)(66556008)(956004)(478600001)(2616005)(66476007)(5660300002)(31696002)(8676002)(6486002)(16576012)(66946007)(44832011)(6916009)(86362001)(53546011)(316002)(31686004)(786003)(186003)(16526019)(83380400001)(75432002)(8936002)(26005)(2906002)(36756003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: eBPKZc27xLjP1AIGe4YbDALDQF89gIAje8vhbh3ApIxxMI+G/hCpH/MycYEl2OB3uID0jdSzV4fM6R4/U8eIqLph+mVDLFj0R3ho/EW+uT0yjBY/dZN8s46SKnj3VexyOvjN6gGm1S+Y2cjeNaVx+8SjSUirP0LAFf5QU3FnwWPQbsdTyd4JY48SqeJ+ZQl4ZMEWQ+Mr49vZ3ZfI7+jIIQ/OQdqBZFVSG+7mO1xd+IJFTFQDrbfYs9QqW1rnGkypSNz36z896ar61uV6TnQ7RD0srxdpdkHpekE5YXUGUL+A061AJKbQhNRdx03EzmTnAdC2fObXgC15morXE4PCcyrTeunX3IkPFKHNxFzHXeJLl3vtvu9h/eR2P4tEAGBlWjz9NaQfJrCmwLxByIOB97xn5ClMheuI37qUxoxUpNv8qjopt04fPJ6ar7RjuBxBBGjeBlPScFvrNrKU2MJ7bv21qFcNlr7iCVAyenUkI+h86bPwdpJXa1GcjaOY1srIFHfgZHNEkF3QXoxbPgyTbJRMkLBkpNL8mZNZDr5EhQ7ZRBC92jxUVcdFm1pLdP/0VpK13ep7nJAdGwvrQg8rHDa8beJwyZ+ZdrjZBICvkK807ibHu7VkxZ00igWvRwRps9xiDny7so1tNb0HxR02sQ== X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: fa38e7e5-82a7-45ca-feea-08d887f6e20f X-MS-Exchange-CrossTenant-AuthSource: PH0PR06MB7061.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2020 17:09:29.8693 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JGEhg6Qbt26HsBX/iZzKwS81C33Z5iV8SuPMZ3SV81IIl4ONUsJPz5nDg5KxrzSC3WiqgHxVA1JuDMPxB/Hpeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR06MB7559 Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 17:10:39 -0000 On 11/13/20 9:03 AM, dotzero@gmail.com wrote: > > > On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan > wrote: > > > > As another case, would people be surprised that email for the medical center cumc.columbia.edu is a separate system managed by a separate IT group from columbia.edu , and that any authentication for one should not be applied to the other?  I don't think this is unique in large decentralized universities. The real email world is a complicated place. > > > The simple solution is for  cumc.columbia.edu to publish its own record. Done. > > Michael Hammer > > > I don't think I have the right to force the owner of another domain to publish dmarc. The owner of the other domain may want to allow users in their domain to contribute to lists and groups without having their messages rejected, or mangled by well-intentioned workarounds. This is not simple. This is a real-world case with the domains ending columbia.edu .  > > > If CUMC publishes a DMARC record for cumc.columbia.edu , how is it forcing another domain to do anything? As far as "owner of a domain", If Columbia University registered the domain columbia.edu , then CUMC is using the subdomain because Columbia University is allowing it to, presumably through some sort of written agreement. A technical standards body cannot address business and contractual arrangement in the manner you appear to be asking. If Columbia University stopped delegating the subdomain cumc.columbia.edu , would you turn to the IETF for redress?   You can't think of universities as single entities with central management authority. For the longest time our CS department owned wisc.edu and central IT had to ask them for permission to use it for campus-wide email. Yes, 3rd level domains should be encouraged to publish DMARC records for their domains to reflect how they are being used, and putting p=none not a big ask of them. The departmental IT who understand DMARC immediately ask: "How do I publish a subdomain policy? Oh, I can't? Well, you better not ever change sp=none at the org domain." Jesse From nobody Fri Nov 13 09:25:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874593A0FB8 for ; Fri, 13 Nov 2020 09:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-5ELUFtnf1c for ; Fri, 13 Nov 2020 09:25:16 -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 B2E5A3A0FB6 for ; Fri, 13 Nov 2020 09:25:16 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ADHSkxP017635 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 13 Nov 2020 09:28:47 -0800 Reply-To: dcrocker@bbiw.net To: dmarc@ietf.org References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> <903acb7d-847e-c87c-f21b-dcfa698bfd89@wisc.edu> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <0ea96604-49ef-489a-841b-8cb6e54e2c07@dcrocker.net> Date: Fri, 13 Nov 2020 09:25:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <903acb7d-847e-c87c-f21b-dcfa698bfd89@wisc.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 17:25:18 -0000 On 11/13/2020 9:09 AM, Jesse Thompson wrote: > You can't think of universities as single entities with central management authority. For the longest time our CS department owned wisc.edu and central IT had to ask them for permission to use it for campus-wide email. This highlights that the example that was provided was of a university that might be asserting 'global' policy under its domain that isn't really valid. That is, the problem with a component group's being affected by a higher-level domain's default record is, really, a problem that is internal to the organization, not one that should entail accommodation by, and the considerable costs of, a public standard. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Nov 13 10:31:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAFE3A1020 for ; Fri, 13 Nov 2020 10:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH15qjSRpmzj for ; Fri, 13 Nov 2020 10:31:47 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54CD3A1014 for ; Fri, 13 Nov 2020 10:31:47 -0800 (PST) X-ASG-Debug-ID: 1605292303-11fa3148027f990001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 0IJdXmviIxv3Ze34 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 13 Nov 2020 13:31:43 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=GPo3fKwg4bozukhNToDRv3xOdKhAJECRioBxvpbDAhg=; b=eADpNcSAZh86GxWQkeAshM0z1qbKssDYYt/zF+phwykUlD/2iehhC1xyoXLW44ag2 ra57RLJsB/CfQJF2zh4IXQ817E/ZovOjROyi+SFCMZbTU7vb3Ed9DYOgh+YIC3NqG ZzZzbPSJM1S7WJ+rO8Up57+ObmLjkSPU1OlqR2IuA= From: "Douglas E. Foster" To: "IETF DMARC WG" Date: Fri, 13 Nov 2020 13:31:36 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=d4a2c237d5e14e57891f75b65f232300 In-Reply-To: References: <20201111181837.79128262943F@ary.qy> <6fd681e2-cabe-2fb0-61f4-9019ce98458e@taugh.com> X-Exim-Id: b35710ccf8944ef99cc7a0d7b4e8c348 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605292303 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 13223 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85850 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 18:31:52 -0000 This is a multipart message in MIME format. --d4a2c237d5e14e57891f75b65f232300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I beleive that we can and should address the Columbia University problem. = Here are some thoughts: Policy Types ------------=3D--- We have three types of policies: - "p=3D" policy for a specific domain - "sp=3D" policy for subdomains that do not enumerate their own - "sp=3D" policy for non-existent subdomains Deploying a specific "p=3D" to every node will provide granular control for= subdomains that exist, but it does not solve the problem for non-existent = subdomains. Non-Existent Domains ------------------------------ In almost every case, the policy for non-existent subdomains should be stri= cter than the one for existent subdomains, so sharing one policy for both p= urposes is problematic. I created ticket #83 last night with a proposal t= o define a policy option for non-existent domains. Roll-up Policy ------------------ When rolling a security policy up from leaf nodes upward toward higher leve= l nodes, the weakest policy is the one that has to forwarded upward, unless= there is a mid-tree override mechanism. By allowing a lower-level subtree= to apply a different policy than the parent, we allow the stricter policy = to flow upward while the weak subtree retains its carve-out exception. If a subtree needs a weak policy and that setting can only be accomplished = at the top of the domain, then the entire organizaiton's security is weaken= ed for the sake of the problematic leaf node. This is exactly the situati= on that causes sp=3Dnone to persist indefinitely. Inheritance --------------- For subdomains that actually exist, one has to ask whether it is reasonable= to expect an organization to implement a DMARC policy at every node of its= domain tree. In the event that a reporting address changes, the organiza= tion has a lot of changes needed to propagate that change everywhere. W= e would benefit from providing an ability to inherit from an upper-level en= try using syntax like "inherit=3DN", where N is an integer number of domain= levels. The evaluator determines the values for sp, rua, and ruf at the= referenced domain, and uses the sp result for p and sp on the referencing = subdomain. Similarly, the rua and ruf values from the referenced domain a= re used to supply those values if they are not specified on the referencing= subdomain DMARC record. Since the flow is only upward, the maximum numbe= r of iterations is limited, even if nested inheritance is allowed. Howeve= r, nested inheritance could be limited to a maximum number or disaloowed co= mpletely. This approach allows subtrees to configure different reporting t= han the top-level of the organization. Inheritance provides a more efficient method of walking up the domain tree,= as compared to sequential iteration, for subdomains that actually exist an= d have an inheritance record defined.. QueryDown ---------------------- Walking down the tree has some possibilities as well. Assume that the top of the organization is located using the PSL, but as in= the Columbia University example, the sp policy at that level is not necess= arily determinative. A token of the form "querydown=3D1" instructs the = evaluator to accept the sp policy at this level as a candidate policy, but = to check the next level down to see if an override applies. If the token = is missing or 0, then this record is determinative and the search stops. - If the next level down is the original domain, then of course the process= stops because this domain has already been checked for a p policy and been= found lacking. - If the next level down produces a DMARC record, the sp at this level beco= mes the new candidate policy, subject to checking for another querydown tok= en. - If the next level down does not have a DMARC record, the search stops and= the last candidate policy is the effective policy. In most cases, this process will end quickly because it will either exhaust= the domain string, encounter a missing DMARC record, or encounter a DMARC = record with querydown=3D0 (or missing). If the querydown parameter is larger than one, the evaluator can jump down = that many levels, eliminating intermediate ones. Again, if this positions= the match at or below the original domain or below, then the search stops = and the last candidate policy is applied. Again, a limit on the number of downward iterations would be applicable. = If an "inherit=3Dn" token is being used to walk up the tree, then the quer= ydown parameter would be ignored. Hope this helps, Doug Foster ---------------------------------------- From: Joseph Brennan Sent: 11/12/20 9:24 AM To: IETF DMARC WG Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On = splitting documents and DBOUND On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker wrote: Just to invoke a bit of ancient history, here, you are saying that if there was the domain name: engineering.sun.com people would be surprised that the organization domain is oracle.com As another case, would people be surprised that email for the medical cente= r cumc.columbia.edu is a separate system managed by a separate IT group fro= m columbia.edu, and that any authentication for one should not be applied t= o the other=3F I don't think this is unique in large decentralized univers= ities. The real email world is a complicated place. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --d4a2c237d5e14e57891f75b65f232300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I beleive that we = can and should address the Columbia University problem.  Here are some= thoughts:

Policy Types
------------=3D-= --
We have three types of policies:
  • "p=3D" policy fo= r a specific domain
  • "sp=3D" policy for subdomains that do not enume= rate their own
  • "sp=3D" policy for non-existent subdomains
=
Deploying a specific "p=3D" to every node will provide granular contro= l for subdomains that exist, but it does not solve the problem for non-exis= tent subdomains.   

Non-Existent Domains=
------------------------------
In almost every case, t= he policy for non-existent subdomains should be stricter than the one for e= xistent subdomains, so sharing one policy for both purposes is problematic.=   I created ticket #83 last night with a proposal to define a policy = option for non-existent domains.

Roll-up Policy
------------------
When rolling a security policy up from= leaf nodes upward toward higher level nodes, the weakest policy is the one= that has to forwarded upward, unless there is a mid-tree override mechanis= m.  By allowing a lower-level subtree to apply a different policy than= the parent, we allow the stricter policy to flow upward while the weak sub= tree retains its carve-out exception.

If a subtree= needs a weak policy and that setting can only be accomplished at the top o= f the domain, then the entire organizaiton's security is weakened for the s= ake of the problematic leaf node.   This is exactly the situation that= causes sp=3Dnone to persist indefinitely.

Inherit= ance
---------------
For subdomains that actually exist= , one has to ask whether it is reasonable to expect an organization to impl= ement a DMARC policy at every node of its domain tree.   In the event = that a reporting address changes, the organization has a lot of changes nee= ded to propagate that change everywhere.     We would benefit fro= m providing an ability to inherit from an upper-level entry using syntax li= ke "inherit=3DN", where N is an integer number of domain levels.   &nb= sp;The evaluator determines the values for sp, rua, and ruf at the referenc= ed domain, and uses the sp result for p and sp on the referencing subdomain= .   Similarly, the rua and ruf values from the referenced domain are u= sed to supply those values if they are not specified on the referencing sub= domain DMARC record.   Since the flow is only upward, the maximum numb= er of iterations is limited, even if nested inheritance is allowed.   = However, nested inheritance could be limited to a maximum number or disaloo= wed completely.  This approach allows subtrees to configure different = reporting than the top-level of the organization.  

Inheritance provides a more efficient method of walking up the domai= n tree, as compared to sequential iteration, for subdomains that actually e= xist and have an inheritance record defined..

Quer= yDown
----------------------
Walking down the tree has = some possibilities as well.    

Assume t= hat the top of the organization is located using the PSL, but as in the Col= umbia University example, the sp policy at that level is not necessarily de= terminative.    A  token of the form "querydown=3D1" instruc= ts the evaluator to accept the sp policy at this level as a candidate polic= y, but to check the next level down to see if an override applies.   I= f the token is missing or 0, then this record is determinative and the sear= ch stops.  

- If the next level down is the o= riginal domain, then of course the process stops because this domain has al= ready been checked for a p policy and been found lacking.
- If th= e next level down produces a DMARC record, the sp at this level becomes the= new candidate policy, subject to checking for another querydown token. &nb= sp; 
- If the next level down does not have a DMARC record, = the search stops and the last candidate policy is the effective policy. &nb= sp; 
In most cases, this process will end quickly because it= will either exhaust the domain string, encounter a missing DMARC record, o= r encounter a DMARC record with querydown=3D0 (or missing).

<= /div>
If the querydown parameter is larger than one, the evaluator can = jump down that many levels, eliminating intermediate ones.   Again, if= this positions the match at or below the original domain or below, then th= e search stops and the last candidate policy is applied.

Again, a limit on the number of downward iterations would be applica= ble.   If an "inherit=3Dn" token is being used to walk up the  tr= ee, then the querydown parameter would be ignored.

Hope this helps,

Doug Foster

=


From: Joseph Brennan <brennan@columbia.edu>
Se= nt: 11/12/20 9:24 AM
To: IETF DMARC WG <dma= rc@ietf.org>
Subject: Re: [dmarc-ietf] Organizationa= l domains, threat or menage, was On splitting documents and DBOUND


<= /div>
On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker <dhc@dcrocker.net> wrote:

= Just to invoke a bit of ancient history, here, you are saying that if
th= ere was the domain name:

    oracle.com

As another case, would people be surprise= d that email for the medical center c= umc.columbia.edu is a separate system managed by a separate IT group fr= om columbia.edu, and that any authen= tication for one should not be applied to the other=3F  I don't think = this is unique in large decentralized universities. The real email world is= a complicated place.


-= -
Joseph Brenn= an
Lead, Email and Systems Applications
Columbia University In= formation Technology


--d4a2c237d5e14e57891f75b65f232300-- From nobody Fri Nov 13 10:40:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9543A1095 for ; Fri, 13 Nov 2020 10:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSGVX67LVE2L for ; Fri, 13 Nov 2020 10:40:47 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CC53A1094 for ; Fri, 13 Nov 2020 10:40:46 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id o25so11452044oie.5 for ; Fri, 13 Nov 2020 10:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vjpN/v6yzHgTry/aRSwm9DfsojgcL/+BR61WBA/Lwqo=; b=BG3SyjoRchyuxBKSN9uqZG+7k99Yk4UJxqEQQ5OB9haW15QBZGrx4kGs3ulawSYWaf z8jP35Qg2TTUbl9F7HynVJ+S95rzkxLPXOqLGrVVHjEaaAXS9ZEo+S9GBBLJNgtKyGLH a0bb8mugEKEXb9ruD+Vr0t+Uk+zwc35JuPPsEkig0oJ+4EFeNdIsdEQ5C2LkOwISlNW5 0fClpkwVX9W/0hf1r9ceRkC6Z5df+EgR2Y8Tb4aBYaT6nRsTL/QK5URQCsnhFicklZXv CpOiXsxCNJNY38tWnska8OBqt/EhoBsnMiYuYl/+rhL8Egi8Q5dVMjRxC3/foIPXfg+2 Bdjg== 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=vjpN/v6yzHgTry/aRSwm9DfsojgcL/+BR61WBA/Lwqo=; b=bO7+HimFz6aNrRv/+ShI8G47u1Gljo4gUiIs8+QfdOTzyxafhl5PH7yZ0EjXJiHJJx jBO4G1AsfnEV/E32/t6SQPX47MIUCou5eqMOIoesCcMBLa2AYk71g0aU8ecS2ygEOuXh QQYlIJ+IwqP8yKtFSjh97BqZLvV7eQxb0pTcal6izmGoq5undlTAu+ToXdikDJrZ4GMp DD5ki6FQS3Wg7KdDU0Ru+KVN8szigfYo9m7MmvnUPXNTFS7uCoqR+TfaNloLm0RFPxx9 6k8EVwcLsjzkfamUUroS/q+IQucXX4f+4jgrghK3OJqWHvaTldf2a1w3aylmxlQAc82q sJWA== X-Gm-Message-State: AOAM532XaqTZVg5MEc6geW0ghdozzFBmBrjEUnoyvXrE77aYbUBFlKb3 jJnba8+UghFIEZdeXtrAzCbU3XAPQqWulhLLbSfK8QeHV8Q= X-Google-Smtp-Source: ABdhPJw2gnfnlZDBbB7imP0yB8FJUpKDUjGOXX5JZUAlk1bTPTeVU/+ssvMa+VllzqG/aLBa7cD64tUHAIi9WDqXjsM= X-Received: by 2002:aca:3605:: with SMTP id d5mr2409284oia.45.1605292844716; Fri, 13 Nov 2020 10:40:44 -0800 (PST) MIME-Version: 1.0 From: Tim Wicinski Date: Fri, 13 Nov 2020 13:40:33 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c5174205b4015df2" Archived-At: Subject: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 18:40:54 -0000 --000000000000c5174205b4015df2 Content-Type: text/plain; charset="UTF-8" All During the chairs call this morning we were discussing the upcoming meeting. Now Seth has a conflict with the meeting time that can't be altered. Since work items have been progressing rather well recently, and the editors are in positing, we discussed canceling the meeting. We wanted to get some feedback from the working group. Here is a lightweight agenda Seth put together. Should we 1) have a meeting around these topics; 2) discuss other topics or 3) cancel the meeting and keep moving along. thanks tim ====== break out definition of org domain to a different document? = scope? - pct= = written, implemented, and understood differently = cause of lots of shenanigans = more damaging that it's worth? - aggregate reporting = ARC reporting = extensible reporting = NXDOMAIN reporting - failure reporting = slimmed down reports with minimal PII - policy discovery = tree walk? --000000000000c5174205b4015df2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= ll

During the= chairs call this morning we were discussing the upcoming meeting.=C2=A0 No= w Seth has a conflict with the meeting time that can't be altered.=C2= =A0 =C2=A0Since work items have been progressing rather well recently, and = the editors are in positing, we discussed canceling the meeting.=C2=A0 We w= anted to get some feedback from the working group.=C2=A0

Here is a lightweight agenda Se= th put together.=C2=A0 Should we 1) have a meeting around these topics;=C2= =A0 2) discuss other topics or 3) cancel the meeting and keep=C2=A0moving a= long.

tha= nks

<= /div>
tim
=
=3D=3D=3D=3D= =3D=3D

=C2=A0break out definition of o= rg domain to a different document?
=C2=A0 =3D scope?

- pct=3D
=C2=A0 =3D written, implemented, and understood differently
=C2=A0 =3D cause of lots of = shenanigans
=C2= =A0 =3D more damaging that it's worth?

- aggregate reporting
=C2=A0 =3D ARC reporting
=C2=A0 =3D extensible reporting
=C2=A0 =3D NXDOMAIN reportin= g

- failure reporting
=
=C2=A0 =3D slimmed do= wn reports with minimal PII

- policy discovery
=C2=A0 =3D tree walk?
--000000000000c5174205b4015df2-- From nobody Fri Nov 13 10:42:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A93A102A; Fri, 13 Nov 2020 10:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTpeqjjzFe0J; Fri, 13 Nov 2020 10:42:05 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8980B3A1026; Fri, 13 Nov 2020 10:42:05 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id 79so9808494otc.7; Fri, 13 Nov 2020 10:42:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=8fQQOvyD8vgAyfFDRs5FL7VfHkAqPypCIMUaTUHjGFI=; b=mfZF82r7kzdIE2qExoS3B7bQHqbjOdAU2U7s7nhc5lhjDnVcoxOxaFOaqzX9CupG28 JKckC98Rp55P5joruZg3z7NQ5dyWW9f8yuM3f+WHkZZmnC4qILUxcyZ8z0aaK2UMUKxH YVrIJuoLwFMM8XDIxrSvihNcHUoRrLCAuRlNTfllFsddt3DpmBuvJvSI6gX81c+z7ZZ/ MmNlCkQKiIRoeHcudX9m7SHc7+jvmcNVDEYB+yFL9HYPVeRZ+qZ2tWNEb59aPSC0bz5O SxJ01S8MAtPyluNJnS5ZYxIUTb0CcJ/ef2YHN3+2V5VthY3g3sZZzTHY+ntp7tSH7Uhn WzmQ== 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:cc; bh=8fQQOvyD8vgAyfFDRs5FL7VfHkAqPypCIMUaTUHjGFI=; b=t1O4SRO1N3NfOOPdkB9yPKd6FA6TOrPNHlXPWajNT0Hx/MyU3BmcElIhfPmEHp/x60 LC07nFvucsmOYzV9OWpO+NCnLj0V8USve5Y8fqcFxrKIRu80OGTQIdMMjO1BWAhEGR1t 3Nvz3ISMc5CZg0Tt4anT1zT0Ncuzdrb92AV+NxC8tS3A+nUNtPckb2zIpEW1KfFCiJNL V2GhqW0gXAkCbcVxUYR9NTyEEDv+E3TmE51zOwXL5k9tpNoSVXUSnfyIuRKajBc5ldL5 ssmilE9/4scnOmQa/d93unhMhCsn70orsjtE29dRq8ZHDQCnJU2xi/+AUs/wT4rsmEUY xfyg== X-Gm-Message-State: AOAM530V6bEtHzZ7StohUngt0yhwYFPVuqf+O0eBmlI+POFxHtGNhLc3 BhDUneZyoaGhxHtrsLP7e5FcvGRl69btgCxgwxuPeGywdP0= X-Google-Smtp-Source: ABdhPJwoZqYbvg2940HlBAG6/iHHnTfSgJg1A0rJd9mhBXNNcWx4S4jcQzKGnNoYKkvgVdZ2UwqQCJ66b0gBwCNLk7s= X-Received: by 2002:a9d:7392:: with SMTP id j18mr2549331otk.288.1605292924542; Fri, 13 Nov 2020 10:42:04 -0800 (PST) MIME-Version: 1.0 From: Tim Wicinski Date: Fri, 13 Nov 2020 13:41:53 -0500 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008722b405b40162e3" Archived-At: Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 18:42:07 -0000 --0000000000008722b405b40162e3 Content-Type: text/plain; charset="UTF-8" All During the IESG reviews of draft-ietf-dmarc-psd, there were several issues raised with some of the document. Most of them are editorial but the one big item was the description of the Experiment. The chairs sat down and broke out the experiment section into three separate experiments, and included language on how to capture the data to confirm how the experiment worked. It's enough of a change that we wanted to do a second working group last call to make sure the working group agrees with our changes. The diff of the current version with the previous version is here: https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 This starts a *one* week second working group last call for draft-ietf-dmarc-psd Please review the changes and offer up comments to the working group. This working group last call 20 November 2020 Thanks, --0000000000008722b405b40162e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">During the IESG reviews of = draft-ietf-dmarc-psd, there were several issues raised with some of the doc= ument. =C2=A0 Most of them are editorial but the one big item was the descr= iption of the Experiment. =C2=A0 The chairs sat down and broke out the expe= riment section into three separate experiments, and included language on ho= w to capture the data to confirm how the experiment worked.=C2=A0

It's enough of a= change that we wanted to do a second working group last call to make sure = the working group agrees with our changes. The diff of the current version = with the previous version is here:=C2=A0


https://www.= ietf.org/rfcdiff?url1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-ietf-dmarc= -psd-09


= This starts a *one* week second working group last call for=C2=A0 draft-iet= f-dmarc-psd

Plea= se review the changes and offer up comments to the working group.


This working group last call 20 November= 2020


Thanks= ,



--0000000000008722b405b40162e3-- From nobody Fri Nov 13 10:52:44 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2E3A1037 for ; Fri, 13 Nov 2020 10:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=jkBYWi/H; dkim=pass (2048-bit key) header.d=taugh.com header.b=eSuKI4iu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBQbEO6t7ikN for ; Fri, 13 Nov 2020 10:52: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 CA04E3A1036 for ; Fri, 13 Nov 2020 10:52:41 -0800 (PST) Received: (qmail 10332 invoked from network); 13 Nov 2020 18:52: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:cleverness; s=2859.5faed5f8.k2011; bh=+KbhIJuJxdpGZhfl13WZrMcFGVLLj0TJlbUwKHnyVdI=; b=jkBYWi/HCbRCQiheRUvJcJV7VyxkxBi32l6/cigJQ31S9PRxLfg29gRgKd8mG7qhWPp7nKBnK+rCugQ+9QN2Yb4JXHCgC+8lGIJHUCbHZrLyCZfFyeAXoa4OdAJzEMelocnmTK1ebDw7M/z9y6w6d2VzYUNmrJOYGvQwl6zSexZQMMawxxkdkM4dJRH6aXfI3ZcSr6YS0+EKCvVlDgM+HZkErPOyioypgOnsLNJe4rU6Ci5zDxviDSkpf6m/oZMgpnFFCus686sCAO+jZIBhayQijqZPQYVUaU9uUfbTcJVCykQeAp7Zo8/ojj8+fZGB6ZxS6plNZBH43uivSK9/mA== 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:cleverness; s=2859.5faed5f8.k2011; bh=+KbhIJuJxdpGZhfl13WZrMcFGVLLj0TJlbUwKHnyVdI=; b=eSuKI4iur2+R4QEmEojpsNob2OH+kjsFRgG4PNzdl7S7xiPRsB2JbTdWicbPpJ4BXLdZ5IWe3VNZUvChrQjBW5w53c2S7vrtvkX/NeIY7/AbppVBS1tizD2imEKR9O/EFoNRDBlXlzPqHArFAstewFjiEMJmTFS1lCIwwarrBJvqxbHazNtMQUI5suAWd8A5aIYcP82bf7WqXW/F4DRLlUVIVeI0qUyIuaqhW2hAzOHpqJeIoT3Yi75Zi6S9rbfLT5v21okE52DoIv3jv4znujp8xVBgKed/A+CyeAcrgCFqpPnX0L2oBW5HiCUaqz0eOlBDaEcHYGiAL4ApFOedvg== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Nov 2020 18:52:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 1400D270630D; Fri, 13 Nov 2020 13:52:39 -0500 (EST) Date: 13 Nov 2020 13:52:39 -0500 Message-Id: <20201113185240.1400D270630D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu In-Reply-To: <903acb7d-847e-c87c-f21b-dcfa698bfd89@wisc.edu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 18:52:43 -0000 In article <903acb7d-847e-c87c-f21b-dcfa698bfd89@wisc.edu> you write: >You can't think of universities as single entities with central management authority. For the longest time our CS department owned >wisc.edu and central IT had to ask them for permission to use it for campus-wide email. I believe you, and I am quite aware that UW is not the only university with a governance model based on that of the Holy Roman Empire. (I went to Yale which was like that, too.) On the other hand, whether or not we like it, the DNS is a tree, and if an organization's DNS structure doesn't match their management structure, there is no way to tell from the outside and it's up tp them to sort it out. R's, John From nobody Fri Nov 13 11:16:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D463A106F for ; Fri, 13 Nov 2020 11:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSs9lsMnM4dB for ; Fri, 13 Nov 2020 11:16:05 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4459E3A1070 for ; Fri, 13 Nov 2020 11:16:05 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id k1so9444305ilc.10 for ; Fri, 13 Nov 2020 11:16:05 -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=c60nfNMlOlhPR1lB1AaqvtI6oN++nQX41UvCAK5N0vg=; b=DOyiwelY8htOq+sChcCcp/iEql8vKJFZ/uCuwIwxOmIw++Du07TPm2TTeH1JO12hMV Yy7VTeVo1JebQyhADH1l0irED1jL9kmxtnM29F4/bOym9h6iLo5hfJKfJXCPoy7yBvDy fPW592xwmQ++jqFlszzPbQfTHlb1Y5u3dbG1o= 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=c60nfNMlOlhPR1lB1AaqvtI6oN++nQX41UvCAK5N0vg=; b=eJfoIGFLZyhVgqSEQnIQhbokqgyV/VXk8ibxY8zT/m3SIwyR4zEjUgz2Yf0wrtlSqC RhtXoMdf4y/cAOMuwmDPHrvwofOoi67SewN9eAvSsO9uKhw+r+CTo70Y1ERDzqY8jAJa w58nu+2UKDTEPrBB5niQYhWH9avkpkK6/8bOVTQBnxCEUeunfzxE/jM1kHOSuk+M4E1a Pqbg3NjkphUiVyOX44GFLigU95OWQ8H6ArwjhBYM4fQ5PiMbFFHj4HNJTFxYEp9JwgOR gENGKFGP8I00DYuaweOYjNp/L/Szo7imyrN4/ArQHBDV/Af5/rYTEoIqwuARrs/z0WjJ JppA== X-Gm-Message-State: AOAM5326Bowmdi9whNpfo4Nym5SbryTH73XYFpecNuUAMXJ7Pp17yITj JQp+hTmdGbdX/f497/GjvvV/pi6ka2z5ST+BvJ6qIw== X-Google-Smtp-Source: ABdhPJw9UQvtK96wMf9fZV3kC2TVLXe5DswYDywLGlZh4dpQD74XOjlyogbV055xXXPRKQMbzFhdIqmb/FOdzZKTVBY= X-Received: by 2002:a92:9815:: with SMTP id l21mr1040636ili.120.1605294964062; Fri, 13 Nov 2020 11:16:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Kurt Andersen (b)" Date: Fri, 13 Nov 2020 11:15:52 -0800 Message-ID: To: Tim Wicinski Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000017d42e05b401dc4d" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 19:16:09 -0000 --00000000000017d42e05b401dc4d Content-Type: text/plain; charset="UTF-8" On Fri, Nov 13, 2020 at 10:41 AM Tim Wicinski wrote: > > All > > During the chairs call this morning we were discussing the upcoming > meeting. Now Seth has a conflict with the meeting time that can't be > altered. Since work items have been progressing rather well recently, and > the editors are in positing, we discussed canceling the meeting. We wanted > to get some feedback from the working group. > > Here is a lightweight agenda Seth put together. Should we 1) have a > meeting around these topics; 2) discuss other topics or 3) cancel the > meeting and keep moving along. > I'd vote for 3. I think that it would be better to discuss/hash out these topics on the list. Perhaps we could start each one with a cogent summary of the issues related to the topic. --Kurt --00000000000017d42e05b401dc4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 13, 2020 at 10:41 AM Tim Wici= nski <tjw.ietf@gmail.com> w= rote:

=
All

During the cha= irs call this morning we were discussing the upcoming meeting.=C2=A0 Now Se= th has a conflict with the meeting time that can't be altered.=C2=A0 = =C2=A0Since work items have been progressing rather well recently, and the = editors are in positing, we discussed canceling the meeting.=C2=A0 We wante= d to get some feedback from the working group.=C2=A0

Here is = a lightweight agenda Seth put together.=C2=A0 Should we 1) have a meeting a= round these topics;=C2=A0 2) discuss other topics or 3) cancel the meeting = and keep=C2=A0moving along.

I&#= 39;d vote for 3. I think that it would be better to discuss/hash out these = topics on the list. Perhaps we could start each one with a cogent summary o= f the issues related to the topic.

--Kurt=C2=A0
--00000000000017d42e05b401dc4d-- From nobody Fri Nov 13 11:54:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF53A0141 for ; Fri, 13 Nov 2020 11:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Ftkmreoyv0 for ; Fri, 13 Nov 2020 11:54:50 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 5993F3A0147 for ; Fri, 13 Nov 2020 11:54:50 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id v20so1914073qvx.4 for ; Fri, 13 Nov 2020 11:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HpcjeRVl3rl4y5GUajLmEn4MZihVNXSGMOMP082H6pk=; b=XN3g1yR9e/hAlLQSTBE95CFvwEBOiKCbIR9wjq54xYmLNWY5MbTHSg570P8OhkNjn7 Tmx1rAWEJoPS86NUAgFH9jkQeQyADmj3POJout1CyO67KXIpSf7q9XweWtbl6Ymaul2Q kjI9+e2JEUqVQ0+qTMll6a32hcIPq/HRrCMhDmv0xCmi0IRO/25jD9pMXbBL5Icmex8M dsWF6Z6AyA/+ia8mddnWjLDWSMNyrWYXjxPgJ+9v/kJHIeuihFJo3nMvb78rgMDIEdCQ W79GfEfYvO3uVLBn5sdIAtL6TAOj5+L88GE86+PVySbB/onkkHAuDNemhGmRyY2r56NB 4ciA== 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=HpcjeRVl3rl4y5GUajLmEn4MZihVNXSGMOMP082H6pk=; b=jwJPqGIlN55FcV6R1yn2QOtTP7Hh9WBVrvpgxFTDNmw8+OfdHdFVpgSPQ3fgVTXB3D nQ5ZOPmXdXAMHd0k+oT35Xh/ZNG3L9Y5f+WR0h6+kEvljGLi8OpV8BNE16Qt6vOKPoh+ dbjIanrxRIyt/Ii/a7D259/8xeEWBOUz/Vuf5OC3SVKJGxdfQmUjZEJWscDkO65dwZ9h vsdptYhYrHoD9PJi74Ru3np7yotLcjjEYaW1tqULqde1NEKX5M8/3gwk+ZtpudayrGlb gmkwBL7B4V2zaZOUTXu6nwvlHgGTS2FqWl9I/TVqRdGm3atsWZiFFMKBV9yphtxel97o iORA== X-Gm-Message-State: AOAM530tKqf5RjZbWy/bBfZUz4cSPrRQtrTOKnRwM8C0NwgEVHUm9a6G wkKb6Bw+IVCOgj25yTeZpojn8RF/HYmxI90lNU+SmPfR4EA= X-Google-Smtp-Source: ABdhPJxS9oCy+WZs4YZhBBU4XQ1y+PcxG9IuyCPBz3sjP95WoJ++aE6hdwZfZCwMRS1WuMI0LQVzILvrArwLRz2KUCA= X-Received: by 2002:a0c:9b82:: with SMTP id o2mr4043840qve.44.1605297289098; Fri, 13 Nov 2020 11:54:49 -0800 (PST) MIME-Version: 1.0 References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: <160513169495.16356.6565556939968267867@ietfa.amsl.com> From: Todd Herr Date: Fri, 13 Nov 2020 14:54:33 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ad14ae05b40266b6" Archived-At: Subject: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.txt) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 19:54:52 -0000 --000000000000ad14ae05b40266b6 Content-Type: text/plain; charset="UTF-8" Hi. I wanted to call everyone's attention to how draft-ietf-dmarc-dmarcbis-00 differs from the existing RFC 7489. The key differences are as follows: - Section 7, DMARC Feedback, has been mostly removed except for a paragraph that mentions that reporting will be discussed in a different document (as per current plans) - Section 9, Privacy Considerations, has been removed (under the expectation that they'll be discussed in the reporting documents) - Appendix C, DMARC XML Schema, has been removed (under the expectation that it'll be discussed in the the reporting documents) - Remaining target references to "verifying-external-destinations", "failure-reports", and "aggregate-reports", which were anchors in the removed sections mentioned above, have been replaced by hand-wavy language referencing "The DMARC reporting document(s)" - The Abstract and Introduction section have been rewritten as an attempt to address issue #80 - *DMARCbis Should Have a Clear and Concise Definition of DMARC* Obviously the text applicable to the first four bullet points above will evolve over time, and it may not yet be the right time in the process to discuss those sections. However, the proposed new text for the Abstract and Introduction is certainly worthy of discussion at this time, I believe. On Wed, Nov 11, 2020 at 4:55 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : Domain-based Message Authentication, Reporting, > and Conformance (DMARC) > Authors : Emil Gustafsson > Todd M. Herr > John Levine > Filename : draft-ietf-dmarc-dmarcbis-00.txt > Pages : 55 > Date : 2020-11-11 > > Abstract: > This document describes the Domain-based Message Authentication, > Reporting, and Conformance (DMARC) protocol. > > DMARC is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting. Mail-receiving > organizations can in turn use these expressions of policies and > preferences to inform their mail handling decisions should they > choose to do so. > > This document obsoletes RFC 7489. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-00.html > > > 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/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ad14ae05b40266b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi.

I wanted to call e= veryone's attention to how draft-ietf-dmarc-dmarcbis-00 differs from th= e existing RFC 7489.

The key differences are = as follows:
  • Section 7, DMARC F= eedback, has been mostly removed except for a paragraph that mentions that = reporting will be discussed in a different document (as per current plans)<= /li>
  • Section 9, Privacy Considerations, has b= een removed (under the expectation that they'll be discussed in the rep= orting documents)
  • Appendix C, DMARC XML = Schema, has been removed (under the expectation that it'll be discussed= in the the reporting documents)
  • Remaini= ng target references to "verifying-external-destinations", "= failure-reports", and "aggregate-reports", which were anchor= s in the removed sections mentioned above, have been replaced by hand-wavy = language referencing "The DMARC reporting document(s)"
  • The Abstract and Introduction section have been re= written as an attempt to address=C2=A0issue #80=C2=A0- DMARCbis Should= Have a Clear and Concise Definition of DMARC
Obviously t= he text applicable to the first four bullet points above will evolve over t= ime, and it may not yet be the right time in the process to discuss those s= ections. However, the proposed new text for the Abstract and Introduction i= s certainly worthy of discussion at this time, I believe.
=

= On Wed, Nov 11, 2020 at 4:55 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Domain-based Message Authentication, Reporting, and Conformance (DMARC) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Emil= Gustafsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Todd M. Herr
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Levine
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-dmarcbis-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 55
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-11-11

Abstract:
=C2=A0 =C2=A0This document describes the Domain-based Message Authenticatio= n,
=C2=A0 =C2=A0Reporting, and Conformance (DMARC) protocol.

=C2=A0 =C2=A0DMARC is a scalable mechanism by which a mail-originating
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting.=C2=A0 Mail-rec= eiving
=C2=A0 =C2=A0organizations can in turn use these expressions of policies an= d
=C2=A0 =C2=A0preferences to inform their mail handling decisions should the= y
=C2=A0 =C2=A0choose to do so.

=C2=A0 =C2=A0This document obsoletes RFC 7489.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-dmarc-dmarcbis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/dra= ft-ietf-dmarc-dmarcbis-00.html


Please note that it may take a couple of minutes from the time of submissio= n
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/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--

Todd Herr | Sr. Technical P= rogram Manager
= p: 703.220.4153

<= br>

This email an= d all data transmitted with it contains confidential and/or proprietary inf= ormation intended solely for the use of individual(s) authorized to receive= it. If you are not an intended and authorized recipient you are hereby not= ified of any use, disclosure, copying or distribution of the information in= cluded in this transmission is prohibited and may be unlawful. Please immed= iately notify the sender by replying to this email and then delete it from = your system.

--000000000000ad14ae05b40266b6-- From nobody Fri Nov 13 12:23:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C693A0937 for ; Fri, 13 Nov 2020 12:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-O5CvZJu_d9 for ; Fri, 13 Nov 2020 12:23:44 -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 A87BE3A0929 for ; Fri, 13 Nov 2020 12:23:44 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ADKRBhq003048 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 13 Nov 2020 12:27:12 -0800 Reply-To: dcrocker@bbiw.net To: Tim Wicinski , IETF DMARC WG References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> Date: Fri, 13 Nov 2020 12:23:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.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] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 20:23:46 -0000 On 11/13/2020 10:40 AM, Tim Wicinski wrote: > During the chairs call this morning we were discussing the upcoming > meeting.  Now Seth has a conflict with the meeting time that can't be > altered.   Since work items have been progressing rather well recently, > and the editors are in positing, we discussed canceling the meeting.  We > wanted to get some feedback from the working group. > > Here is a lightweight agenda Seth put together.  Should we 1) have a > meeting around these topics;  2) discuss other topics or 3) cancel the > meeting and keep moving along. Four days before a scheduled, rare meeting, it's being canceled because one of its 3 chairs can't attend? Or because it has suddenly been realized that the meeting won't be useful? Really? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Nov 13 12:26:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121703A0975 for ; Fri, 13 Nov 2020 12:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_losjBRtSP6 for ; Fri, 13 Nov 2020 12:26:29 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 61F4A3A0962 for ; Fri, 13 Nov 2020 12:26:29 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id a15so10109895otf.5 for ; Fri, 13 Nov 2020 12:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AzpN7e4u6gu0fFHDhyDOukx/BVPHBpgnz7X7Yxa69cQ=; b=dyaXHs6uLWlsMmgXk5gPtKAd1rtK24yDTfxPi6goURGuhgngmfrJpRRbptYhi0U46v e2WEdzcaGUPtEm0TDYrkGvz/tZ3Mtxze6W41gYcvR6ry+nvnn+zrGnk//mfQH4GZvlLD P4JdHry77eLkm9mhhektn+W7zbfXeVGXVQQlXPexDvBoZ4mVSUazL/+Fmb5OaGqTsiFf 08hp1EbYkqr6ccRX0xoy+qX8EpfB97HVifhmfpPbyoCPzsBKxH2nmKc1wdsXru+sDuF7 M4B6nXVjb0F23fhinTXmu0a/VdGMIEXneb93OybFsEN9GRX4S6o0LJpYCH9smwKbwxL5 i6Og== 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=AzpN7e4u6gu0fFHDhyDOukx/BVPHBpgnz7X7Yxa69cQ=; b=WeChaLD44wMlhIxMFr7Zv+JRQd/xnnF0NbJVmwLR0+Y7hgiO4+InpzSd0ASTWMlx+m mJB/diTheSx15M/j+HPt4XBX2B8pagJ8n96lBVisf8JpQneCzuYtEsOgmulY4wWz0r+M 10Dr0TWJMoESJ9NAUmKIoEt8CPBFrzsLqr5FeJfKczR47JxQhKB0Ilkfb3WAtAIcsg03 rYO26F8IYQYyCprSb7CEc1FhYklGG2kCS8vN+nwtAfr+8/2TEHIPmjD65tFLpY452qCT wV1WqxNXUo/RVodI3zkh8rpKud2wZby/zB7w36zGr41yD9CbDoUpUAorPoVkhjhaUZTW aLhA== X-Gm-Message-State: AOAM531DtK3w9ryhNYILgt71o76xRCO49keA7+taxsrOJno01xk6Zof2 Cjikcn08mmQ9/RISE8e57gdf1xj4xIiU/SsWEJI= X-Google-Smtp-Source: ABdhPJxZ6qrHfM+lfK6oeGXzGJark8xsMRKYE2WXQ9uOmFVs3xMcUiLhPcdVPbOwFWV4RhOxtOcbYgYCIsuv1iE4h6s= X-Received: by 2002:a9d:4b81:: with SMTP id k1mr2885077otf.371.1605299188708; Fri, 13 Nov 2020 12:26:28 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> In-Reply-To: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> From: Tim Wicinski Date: Fri, 13 Nov 2020 15:26:18 -0500 Message-ID: To: Dave Crocker Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e6b9a305b402d749" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 20:26:31 -0000 --000000000000e6b9a305b402d749 Content-Type: text/plain; charset="UTF-8" Dave It's the latter. Alexey and I are quite fine with running the meeting, that was part of our conversation. tim On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker wrote: > On 11/13/2020 10:40 AM, Tim Wicinski wrote: > > During the chairs call this morning we were discussing the upcoming > > meeting. Now Seth has a conflict with the meeting time that can't be > > altered. Since work items have been progressing rather well recently, > > and the editors are in positing, we discussed canceling the meeting. We > > wanted to get some feedback from the working group. > > > > Here is a lightweight agenda Seth put together. Should we 1) have a > > meeting around these topics; 2) discuss other topics or 3) cancel the > > meeting and keep moving along. > > > Four days before a scheduled, rare meeting, it's being canceled because > one of its 3 chairs can't attend? > > Or because it has suddenly been realized that the meeting won't be useful? > > Really? > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --000000000000e6b9a305b402d749 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

D= ave

<= /div>
It's = the latter.=C2=A0 =C2=A0Alexey and I are quite fine with running=C2=A0the m= eeting, that was part of our conversation.

tim


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 13, 2020 at 3:23 PM Dave C= rocker <dhc@dcrocker.net> wro= te:
On 11/13/202= 0 10:40 AM, Tim Wicinski wrote:
> During the chairs call this morning we were discussing the upcoming > meeting.=C2=A0 Now Seth has a conflict with the meeting time that can&= #39;t be
> altered.=C2=A0 =C2=A0Since work items have been progressing rather wel= l recently,
> and the editors are in positing, we discussed canceling the meeting.= =C2=A0 We
> wanted to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.=C2=A0 Should we 1) hav= e a
> meeting around these topics;=C2=A0 2) discuss other topics or 3) cance= l the
> meeting and keep=C2=A0moving along.


Four days before a scheduled, rare meeting, it's being canceled because=
one of its 3 chairs can't attend?

Or because it has suddenly been realized that the meeting won't be usef= ul?

Really?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--000000000000e6b9a305b402d749-- From nobody Fri Nov 13 12:35:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AF83A0991 for ; Fri, 13 Nov 2020 12:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckYdzUIuSklH for ; Fri, 13 Nov 2020 12:35:11 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 577ED3A098D for ; Fri, 13 Nov 2020 12:35:11 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id k4so173476qko.13 for ; Fri, 13 Nov 2020 12:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yW9/pAWhlkO2ZU8+LtpYgJXO0QzN5fBEThuDX/0U4oc=; b=HTwWGU1GHNkucYUQfyzsVgwVGUfsdmvjI6BSoF5/yPxuq9CvoUziuhMRnJ2cj17m5v sMDfs3X4MH9Bb5DI9rAiF67qC9JVX1kyazbcuh4Lcf5jjl5HyTeAsUrhRcXk1fvXJ/d+ AgCYoGyZvMEWUsfVMA4+0lNRtIymSFbgtTursXX0cldkQes7mZ+7TK8TJgWtzAlOc325 4Lw8I91eaq3R3pwq/Cqm9RJmn+FXTXsCRQWNz+Zt/H+4GS+LjkPrhcT5QF+Tl5noTwsq zhC/SXyDwomDLO9Akaf+vnZ9PUlGowyRagPJgdQNIM4Xvrgn0C+faGUksZc9j3g4dSIi Cdpg== 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=yW9/pAWhlkO2ZU8+LtpYgJXO0QzN5fBEThuDX/0U4oc=; b=bU04pCsn7TO+pi6WrnSbBy+Nnb/ou4X8hhoxSgPrhAR5ITF6n2wOyf/uE9YmHhIge1 Z7zdw63zajveOSRlXkhKgJhDP1xRkdANktaZl7mzHazPwucXVHJrLso9w5Qi/N1tYpfA l4K21nr8XYtNYYkUS+baf1wrMcBdW8fuFwEI6I+M/s3HTEoAbomyaPTj/DV+1FKY1sdc ZKBCdZ1h6tQ7Zfn92shldEpd7yEg+9GdsgRUodqx52YyVYnQ9jiNaATIx/WhQoJSQ00j VMTZ8ClHu/UeZ81yvpub5tXbgGoFtRSdd/6GKjbngFE5jcoL+kmhiZMi+5yMeGjqJwzI lOvQ== X-Gm-Message-State: AOAM532ZlIZzRPIZNocKL3on3N5JF2HylP/VeG6UxLwIz/h8NupQKKFP Kb9sN9N+rZOwSXnCDAyKocvew6HhEytKkn7lfuUx6uH/BvA= X-Google-Smtp-Source: ABdhPJxZe2R4vYbVFj5anRnJJew1rGQpsX9sHBwIu+mq8xY86P9Wm8JRR18Fhy5hnsg5l6+z6s9yMpN4i9Miqy6D+5M= X-Received: by 2002:ae9:e702:: with SMTP id m2mr3757321qka.387.1605299709287; Fri, 13 Nov 2020 12:35:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Todd Herr Date: Fri, 13 Nov 2020 15:34:53 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ee41dd05b402f674" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 13 Nov 2020 20:35:13 -0000 --000000000000ee41dd05b402f674 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 13, 2020 at 1:41 PM Tim Wicinski wrote: > > All > > During the chairs call this morning we were discussing the upcoming > meeting. Now Seth has a conflict with the meeting time that can't be > altered. Since work items have been progressing rather well recently, and > the editors are in positing, we discussed canceling the meeting. We wanted > to get some feedback from the working group. > > Here is a lightweight agenda Seth put together. Should we 1) have a > meeting around these topics; 2) discuss other topics or 3) cancel the > meeting and keep moving along. > > [snip] > I vote option 3. There's quite a lot of meaty discussion to be had on these topics, and I can't see any of them reaching consensus or anything close to it during the 30 minutes or so each would be allotted. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000ee41dd05b402f674 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= /div>
All

During the chai= rs call this morning we were discussing the upcoming meeting.=C2=A0 Now Set= h has a conflict with the meeting time that can't be altered.=C2=A0 =C2= =A0Since work items have been progressing rather well recently, and the edi= tors are in positing, we discussed canceling the meeting.=C2=A0 We wanted t= o get some feedback from the working group.=C2=A0

Here is a l= ightweight agenda Seth put together.=C2=A0 Should we 1) have a meeting arou= nd these topics;=C2=A0 2) discuss other topics or 3) cancel the meeting and= keep=C2=A0moving along.

=
[snip]
<= div>
I vote option 3. There's quite a lot of meaty discus= sion to be had on these topics, and I can't see any of them reaching co= nsensus or anything close to it during the 30 minutes or so each would be a= llotted.=C2=A0

--

Todd Herr | Sr. Technical Program Mana= ger
p: 703.220.4153


This email and all data tr= ansmitted with it contains confidential and/or proprietary information inte= nded solely for the use of individual(s) authorized to receive it. If you a= re not an intended and authorized recipient you are hereby notified of any = use, disclosure, copying or distribution of the information included in thi= s transmission is prohibited and may be unlawful. Please immediately notify= the sender by replying to this email and then delete it from your system.<= /span>

--000000000000ee41dd05b402f674-- From nobody Fri Nov 13 20:34:44 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBFD3A1051 for ; Fri, 13 Nov 2020 20:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egXBP3SehQ7O for ; Fri, 13 Nov 2020 20:34:41 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B3A3A1047 for ; Fri, 13 Nov 2020 20:34:41 -0800 (PST) X-ASG-Debug-ID: 1605328479-11fa31480286300001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Bs4PWz4cxrmPBcqw (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 13 Nov 2020 23:34:39 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=YNIb2ZWJfYq/NRKgCRejd9OEZ25a/RdLqwTcVon6p9U=; b=JcmE/wLt9+EHwWN/gUfRaC2usLxdXO99nQEo+azOVcnDjpRsbzbqw6Epy7lVRTuxR x0IBDBusID8atrVcLnhQM1z3LODI3c16KyQL8A4d8Pu+Y1fXmNIs/V4oq1H6AXbYh X6wgS7GW6nCOdNYWNpPKJsh8EsuLitYmGXHrNv98s= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Fri, 13 Nov 2020 23:34:31 -0500 X-ASG-Orig-Subj: tree walk and DNS optimization Reply-To: fosterd@bayviewphysicians.com Message-ID: <9f3a14053b244bdba2f67f1e2f5d294e@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=c6d25a06cabb4389a7004895d571ca16 X-Exim-Id: 9f3a14053b244bdba2f67f1e2f5d294e X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605328479 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4698 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85860 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] tree walk and DNS optimization X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Nov 2020 04:34:43 -0000 This is a multipart message in MIME format. --c6d25a06cabb4389a7004895d571ca16 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Performance is probably a BCP issue. However, since DNS performance conce= rns are a limiting factor on our specification options, the topic seems rel= evant menioning now. In my mail stream, only a small subset requires a DMARC policy lookup to de= termine disposition. I wonder if others have similar or different results= . - One large portion of mail is sent direct: SPF-compliant and domain alig= ned, so it passes DMARC criteria without checking signatures. This includ= es both spam and legitimate mail. - Another large portion is from major email service providers and mailbox p= roviders: Based on observation and provider reputation, I have concluded = that the RFC5322.From address accurate reflects the providers client domain= . This observation includes ESPs that service both spammers and legitima= te clients, where I need to filter on the RFC5322.From to determine whether= the message is wanted or unwanted. In ESP messages, the presence of a va= lid signature for the client domain is correlated with a DMARC-enforcing po= licy, and the absence of a signature is correlated with non-enforcing clien= t domains. - A third portion is spam which we block based on nominal source identity. = When blocking on source identity, we do not worry about verifying whether = the unwanted source is valid or spoofed. A smaller fourth portion includes messages from trusted senders that have c= onfiguration errors which cause SPF or DMARC policy failure. I whitelist = them based on verified characteristics, without needing to check DMARC poli= cy. For all four of these message groups, policy lookup is not needed during me= ssage processing. Consequently, the DMARC lookup can be deferred until t= he preparation of the RUA report, and duplicates can be eliminated to minim= ize DNS traffic when that report is being prepared. This approach minimiz= es resource usage during message processing, so it seems in the interest of= DMARC developers as well as DNS operations. If developers will optimize in this way, the aggregate DNS workload will be= significantly reduced, regardless of the algorithms specified. Doug Foster --c6d25a06cabb4389a7004895d571ca16 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Performance is pro= bably a BCP issue.   However, since DNS performance concerns are a lim= iting factor on our specification options, the topic seems relevant menioni= ng now.

In my mail stream, only a small subset req= uires a DMARC policy lookup to determine disposition.   I wonder if ot= hers have similar or different results.

- One larg= e portion of mail is sent direct:   SPF-compliant and domain aligned, = so it passes DMARC criteria without checking signatures.   This includ= es both spam and legitimate mail.

- Another large = portion is from major email service providers and mailbox providers:  = Based on observation and provider reputation, I have concluded that the RF= C5322.From address accurate reflects the providers client domain.   &n= bsp;This observation includes ESPs that service both spammers and legitimat= e clients, where I need to filter on the RFC5322.From to determine whether = the message is wanted or unwanted.   In ESP messages, the presence of = a valid signature for the client domain is correlated with a DMARC-enforcin= g policy, and the absence of a signature is correlated with non-enforcing c= lient domains.

- A third portion is spam which we = block based on nominal source identity.  When blocking on source ident= ity, we do not worry about verifying whether the unwanted source is valid o= r spoofed.

A smaller fourth portion includes messa= ges from trusted senders that have configuration errors which cause SPF or = DMARC policy failure.   I whitelist them based on verified characteris= tics, without needing to check DMARC policy.

For a= ll four of these message groups, policy lookup is not needed during message= processing.    Consequently, the DMARC lookup can be deferred un= til the preparation of the RUA report, and duplicates can be eliminated to = minimize DNS traffic when that report is being prepared.   This approa= ch minimizes resource usage during message processing, so it seems in the i= nterest of DMARC developers as well as DNS operations.

=
If developers will optimize in this way, the aggregate DNS workload wi= ll be significantly reduced, regardless of the algorithms specified.
<= div>
Doug Foster


&nbs= p;  

--c6d25a06cabb4389a7004895d571ca16-- From nobody Sat Nov 14 02:34:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40A33A1487 for ; Sat, 14 Nov 2020 02:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIX8y4GBMFm4 for ; Sat, 14 Nov 2020 02:34:50 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D2B3A1484 for ; Sat, 14 Nov 2020 02:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605350086; bh=6CQzH8Az41TuMNcWCIhgZkUEjoHtXThbu5vutpJETXA=; l=743; h=To:References:From:Date:In-Reply-To; b=CCH7+i6cKwDzJLtglyxAbYRBqVT+Cl5uLLneWHUTZ8QGBTSW6+PEVFrJUfbZVIKbY 9g514DSr/jOTfQ/6RVwSKgf2HWkhRliS1TNRKOjrYBQVXRFsByY79mt1QrvDIoltp7 ljXwF9Y6SWPuv3CiIb5qvSmrvx5ngay1G7KDmmPLh8+MxwUJARB9QS/HKtrDb Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C6.000000005FAFB2C6.000003CD; Sat, 14 Nov 2020 11:34:46 +0100 To: dmarc@ietf.org References: From: Alessandro Vesely Message-ID: <67b04ced-319e-7db3-553f-46522082020f@tana.it> Date: Sat, 14 Nov 2020 11:34:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 14 Nov 2020 10:34:52 -0000 On Fri 13/Nov/2020 19:40:33 +0100 Tim Wicinski wrote: > > During the chairs call this morning we were discussing the upcoming meeting. > Now Seth has a conflict with the meeting time that can't be altered.   Since > work items have been progressing rather well recently, and the editors are in > positing, we discussed canceling the meeting.  We wanted to get some feedback > from the working group. > > Here is a lightweight agenda Seth put together.  Should we 1) have a meeting > around these topics;  2) discuss other topics or 3) cancel the meeting and > keep moving along. 3) I follow list discussion better, but in this case I won't be able to participate to the meeting anyway (bad timezone). Best Ale -- From nobody Sun Nov 15 03:00:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95433A105C for ; Sun, 15 Nov 2020 03:00:10 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqqTwrB-0bLw for ; Sun, 15 Nov 2020 03:00:08 -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 BC2563A105E for ; Sun, 15 Nov 2020 03:00:07 -0800 (PST) Received: (qmail 34404 invoked by uid 100); 15 Nov 2020 11:00:06 -0000 Date: 15 Nov 2020 10:59:42 -0000 Message-ID: <20201115105942.34387.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 15 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 11:00:11 -0000 Count | Bytes | Who ------------+----------------+------- 13 (18.6%) | 50703 (10.4%) | Dave Crocker 12 (17.1%) | 58169 (11.9%) | John Levine 7 (10.0%) | 83931 (17.2%) | Douglas E. Foster 6 ( 8.6%) | 28888 ( 5.9%) | Alessandro Vesely 4 ( 5.7%) | 41496 ( 8.5%) | Jesse Thompson 4 ( 5.7%) | 33891 ( 6.9%) | Dotzero 4 ( 5.7%) | 30057 ( 6.1%) | Murray S. Kucherawy 3 ( 4.3%) | 39407 ( 8.1%) | Seth Blank 3 ( 4.3%) | 25302 ( 5.2%) | Tim Wicinski 3 ( 4.3%) | 8814 ( 1.8%) | 2 ( 2.9%) | 26347 ( 5.4%) | Todd Herr 2 ( 2.9%) | 18579 ( 3.8%) | Joseph Brennan 2 ( 2.9%) | 13042 ( 2.7%) | Kurt Andersen (b) 1 ( 1.4%) | 9543 ( 2.0%) | Hector Santos 1 ( 1.4%) | 6542 ( 1.3%) | Dave Crocker 1 ( 1.4%) | 5404 ( 1.1%) | Steven M Jones 1 ( 1.4%) | 5004 ( 1.0%) | Jim Fenton 1 ( 1.4%) | 3998 ( 0.8%) | From nobody Sun Nov 15 12:21:23 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFEB23A0A1E for ; Sun, 15 Nov 2020 12:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=dTuNEa69; dkim=pass (2048-bit key) header.d=taugh.com header.b=Z6Xcg7OF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-r4fr5CKWz8 for ; Sun, 15 Nov 2020 12:21: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 7B3833A0A00 for ; Sun, 15 Nov 2020 12:21:18 -0800 (PST) Received: (qmail 28518 invoked from network); 15 Nov 2020 20:21:15 -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:cleverness; s=6f64.5fb18dbb.k2011; bh=rZfRjTYd3jiubz/1NLrdoAFgRCLtLf/zaNUCIT/Ydts=; b=dTuNEa69KCObHam32W1tdRVcwSTABAy7PLtGOL5F3DaLxpigkg5IXKx42OLYpQO3w4jmQqCGvmwW7DIOmG0a5oUmvSmBphuK7L67a4KFIfWPdNPs57FaIZomgM17u5AZV72XPdNc0LLDcN6h2EEDIENsLKrlrCu6mpgDcAzhbiva0OS70AFlAFA6RNBnqmIsL2zB5vrVVIq149u+ZBtRijYGCQsxNnxCd6Z5IYH6q33YxMGJLC0Tukklxf+1p9jihR7+2mua4ySUGdVuYBUviNnqZSi9Byz7V8q20LjiJjdqzXKo19wZXNoyN81u643rTR4klOrw8lrmBJy/lT27Zw== 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:cleverness; s=6f64.5fb18dbb.k2011; bh=rZfRjTYd3jiubz/1NLrdoAFgRCLtLf/zaNUCIT/Ydts=; b=Z6Xcg7OFO8dnrVemFBKziY4vYBto8zVfLK8OrjTIsubX+Bl6NxUk/edLpO7d4uW4qvVr1btDtP/X6BTrpHnBZn5bsPmZg2fV6ZYycW6xgvDUoUPshEvskdwzKZLXxveRqK+2OhjaKsm0SIoY+ppYRjrJF1e+DM1FxDic6E4j5GUwtLuYT7tS9nv9ZM7bAaWLZDjVyeTsGW9SM4is/XEqkFKvbYsWcmTkRNFPpT2C0SAzhKSKunKE/5aK4w9NY/VaNd4/3ZxbhGeh5usBOOwYV7xfDN7DivpOnpj9UtKCHM/5F0otAvbXDpd5uMd8vPE0S7BYYogxf4FEPukUUrQ+ZA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 15 Nov 2020 20:21:15 -0000 Received: by ary.qy (Postfix, from userid 501) id E4225271B9ED; Sun, 15 Nov 2020 15:21:14 -0500 (EST) Date: 15 Nov 2020 15:21:14 -0500 Message-Id: <20201115202114.E4225271B9ED@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 20:21:22 -0000 In article you write: >https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 > >Please review the changes and offer up comments to the working group. I looked at it, seems fine as an experiment. If we end up changing the way regular DMARC looks for Org domains, PSD might become redundant. Or not. R's, John From nobody Sun Nov 15 12:29:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6E63A0AC3 for ; Sun, 15 Nov 2020 12:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh2MWfiUSGru for ; Sun, 15 Nov 2020 12:29:24 -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 81C0D3A0A87 for ; Sun, 15 Nov 2020 12:29:24 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AFKWrId007630 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 15 Nov 2020 12:32:54 -0800 Reply-To: dcrocker@bbiw.net To: dmarc@ietf.org References: <20201115202114.E4225271B9ED@ary.qy> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <6f93c264-965a-85bb-0209-e0d58bc8c7b5@dcrocker.net> Date: Sun, 15 Nov 2020 12:29:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201115202114.E4225271B9ED@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] Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 20:29:28 -0000 On 11/15/2020 12:21 PM, John Levine wrote: > In article you write: >> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 >> >> Please review the changes and offer up comments to the working group. > > I looked at it, seems fine as an experiment. > > If we end up changing the way regular DMARC looks for Org domains, PSD > might become redundant. Or not. I'm going to reiterate that this draft is tightly integrated into DMARC and shouldn't be, for all the reasons we've been discussing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 16 04:35:42 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA813A0E2C for ; Mon, 16 Nov 2020 04:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AqiAw391cyb for ; Mon, 16 Nov 2020 04:35:39 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34A83A0A06 for ; Mon, 16 Nov 2020 04:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605530136; bh=EkPFYDfk0pZSnbHKAVsT8uwEKHcA67wAQzhB02SieFw=; l=2651; h=References:From:To:Date:In-Reply-To; b=Ci2YPz2OLMRlICzSdAP151qKimYrANfUNtMPT8lgey5vEuKBWOxztvkBWYf4pHMEf rhakozjd5qb8DUPH7dDhSrfdm7Iz/os51OiEUicyS3Zg1O7GurdV705sTibaSH5JAu s0SDf3IkGhEWI2v0c3wvtXSUo06dqJ8sCgeY87/Nqu/GC74TLW90K3SLHSlcn Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C0.000000005FB27218.00006502; Mon, 16 Nov 2020 13:35:36 +0100 References: <160552472789.17809.9810087911818402507@ietfa.amsl.com> From: Alessandro Vesely To: dmarc-ietf X-Forwarded-Message-Id: <160552472789.17809.9810087911818402507@ietfa.amsl.com> Message-ID: Date: Mon, 16 Nov 2020 13:35:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <160552472789.17809.9810087911818402507@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] MLM Transformations Revisited X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 16 Nov 2020 12:35:41 -0000 Hi all, in September, I developed a mail filter more or less around Murray's idea of MLM transformations[*]. It needed MLM support. A reply on the Mailman developers mailing list[†] made it clear to me that it won't work that way. So I rewrote the filter in order to make it work in the current environment. Details are in the I-D referred below. Installed on my mail server, the filter does indeed verify some of the original signatures on this mailing list. As I'm going to release the filter in the near future, I beg of you to post constructive comments soon. In fact, hard-coded names will be difficult to change after multiple users will have installed and configured the filter. So, if something sounds indigestible, please tell me ASAP. Thanks in advance for any comment. Ale [*] https://tools.ietf.org/html/draft-kucherawy-dkim-transform [†] https://mail.python.org/archives/list/mailman-developers@python.org/thread/AHHHY5XN3CAM4PFVAYSKFITFXFPL6575/ -------- Forwarded Message -------- Subject: New Version Notification for draft-vesely-dmarc-mlm-transform-00.txt Date: Mon, 16 Nov 2020 03:05:27 -0800 From: internet-drafts@ietf.org To: Alessandro Vesely A new version of I-D, draft-vesely-dmarc-mlm-transform-00.txt has been successfully submitted by Alessandro Vesely and posted to the IETF repository. Name: draft-vesely-dmarc-mlm-transform Revision: 00 Title: Mailing List Manager (MLM) Transformations Document date: 2020-11-16 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-vesely-dmarc-mlm-transform-00.txt Status: https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ Html: https://www.ietf.org/archive/id/draft-vesely-dmarc-mlm-transform-00.html Htmlized: https://tools.ietf.org/html/draft-vesely-dmarc-mlm-transform-00 Abstract: The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to rewrite the From: header field as a workaround. This document describes cases where it is possible to revert MLM transformations and hence verify DomainKeys Identified Mail (DKIM) signatures that were applied at submission time. For reliable results, some compliance is required of all agents involved, author domain signers, MLMs, forwarders, and final recipients. MLM transformation reversion reduces the DMARC's effects on indirect mail flows. 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. The IETF Secretariat From nobody Mon Nov 16 06:40:11 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB663A10E7 for ; Mon, 16 Nov 2020 06:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ftld.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVN9rU7X-15a for ; Mon, 16 Nov 2020 06:40:08 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A9A3A10E8 for ; Mon, 16 Nov 2020 06:40:07 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id h21so3062364wmb.2 for ; Mon, 16 Nov 2020 06:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ftld.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y4gMG1ZmT4dCZ334raHSC69LbRgHN8hcIZBcdmByBtg=; b=fhs9jnvRfkL9vmelA2AfChCZ7qlitUVt66rVMBlOaZLlDde4NAF9yexAHvsSXRWadX 9qHcdYO2A8PxvH23QVS5bAJoBaU0pIgmLuMFBjtNWd7NxjcFFz+zmB+h31xBB3agAfSV 6wPLlBi43z4uBH6q0wjsrmLmtC+N5eQ4TPJCQ= 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=Y4gMG1ZmT4dCZ334raHSC69LbRgHN8hcIZBcdmByBtg=; b=MaXkkhztE0Ts5N3Z85Ww9HkPSMT3CDrOTJM8dqLFooSOPjchwfPWiNJf9U6IFvNCxr yKEEWXMsNIsU9C7LX6BrRJTjfFYOUVvYC1GkutsqweE2f5DjBIoyqbl7bTqDjFoplNgX 2/BuVOvmss7vXtlyhj6b1FF487Q1JESrfnxIuVDcUlhiluK/ddHel24oUxpTEHLUJYXa GS/6aHXV6pG+Y5b+d/9RJVUZZBMMrApNashAW7k74RP8tZbGCUC+x4WdDHW2ANMJM8fT 0eh5Yxadvui/LaYkxELDMBf7KNmTxlSgoXCoUIPvurGDG/eL2beKwlc0bXBxuPgj7E+W Hoyg== X-Gm-Message-State: AOAM5322WJsK0LiC2gQar77YwynDOrhLtY2vetcEfwM10LssvIh2E3Y+ Pu4ceN6uRh6VRbQqPvQ9xR5IyGFGDLZ1eG8JHSsnCw== X-Google-Smtp-Source: ABdhPJy0k1K+AGdov0KUaA4NAmNdYDKlVNwpfGo82JrHZlqRJwjo+MLYsNtSMjypcEb/bveWIdDfNNNO76k0lU+UsQ4= X-Received: by 2002:a1c:e087:: with SMTP id x129mr15542351wmg.2.1605537605935; Mon, 16 Nov 2020 06:40:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Craig Schwartz Date: Mon, 16 Nov 2020 09:39:54 -0500 Message-ID: To: Tim Wicinski Cc: IETF DMARC WG , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000acfc1e05b43a5a8c" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 14:40:11 -0000 --000000000000acfc1e05b43a5a8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim, As fTLD Registry Services (fTLD), registry operator of the .BANK and .INSURANCE Top-Level Domains, was instrumental in initiating this work within the IETF in 2018, we are keenly interested in providing any support or input needed to see it through to its successful conclusion. fTLD has, in our role as registry operator, mandated specific security policies/requirements for domain names in our zones inclusive of email authentication (i.e., DMARC plus SPF when the domain is used for email). For security and reputational purposes, our interest in protecting our TLDs extends to NXDOMAINs, which for us come in two =E2=80=9Cflavors.=E2=80=9D T= he first is registered domains that are not in the respective zone because they do not meet the baseline security requirements of having in-zone name servers (e.g., ns1.bankname.BANK) and being signed with DNSSEC. The second is the more common unregistered domain name. As fTLD is prohibited by our contract with ICANN from placing non-approved DNS resources record types (e.g., TXT records) into the TLD DNS Zone, there is a process we can pursue with them to seek removal of the prohibition. In consultations with ICANN that started in 2017, we came to understand that the existence of an RFC on this topic (i.e., TXT records in the TLD DNS zone) could help fTLD, and registry operators like ourselves, overcome this obstacle with ICANN. It is for this reason and to further enhance the security of our TLDs that we undertook this work within the IETF. As I=E2=80=99ve shared candidly with Seth Blank, Scott Kitterman, Murray Ku= cherway and more recently Tim Wicinski, my expertise is more in the policy arena than technical and I=E2=80=99ve done all I can to stay abreast of this work= , contribute when appropriate and drive it in any way possible as I said earlier to it successful conclusion. At this point I=E2=80=99d appreciate understanding what obstacles remain an= d what fTLD, and our internal working group, can do to advance this work. Thanks very much and good luck this week at IETF. Craig *--* Craig Schwartz Managing Director fTLD Registry Services | .BANK & .INSURANCE Mobile: +1 202 236 1154 Skype: craig-schwartz www.fTLD.com On Fri, Nov 13, 2020 at 1:42 PM Tim Wicinski wrote: > > All > > During the IESG reviews of draft-ietf-dmarc-psd, there were several issue= s > raised with some of the document. Most of them are editorial but the on= e > big item was the description of the Experiment. The chairs sat down and > broke out the experiment section into three separate experiments, and > included language on how to capture the data to confirm how the experimen= t > worked. > > It's enough of a change that we wanted to do a second working group last > call to make sure the working group agrees with our changes. The diff of > the current version with the previous version is here: > > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-= ietf-dmarc-psd-09 > > This starts a *one* week second working group last call for > draft-ietf-dmarc-psd > > Please review the changes and offer up comments to the working group. > > > This working group last call 20 November 2020 > > Thanks, > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000acfc1e05b43a5a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tim,

As fTLD Registry Services (fTLD), registry opera= tor of the .BANK and .INSURANCE Top-Level Domains, was instrumental in init= iating this work within the IETF in 2018, we are keenly interested in provi= ding any support or input needed to see it through to its successful conclu= sion.

fTLD has, in our role as registry operator, mandated specific= security policies/requirements for domain names in our zones inclusive of = email authentication (i.e., DMARC plus SPF when the domain is used for emai= l). For security and reputational purposes, our interest in protecting our = TLDs extends to NXDOMAINs, which for us come in two =E2=80=9Cflavors.=E2=80= =9D The first is registered domains that are not in the respective zone bec= ause they do not meet the baseline security requirements of having in-zone = name servers (e.g., ns1.bankname.BANK) and being signed with DNSSEC. The se= cond is the more common unregistered domain name.

As fTLD is prohib= ited by our contract with ICANN from placing non-approved DNS resources rec= ord types (e.g., TXT records) into the TLD DNS Zone, there is a process we = can pursue with them to seek removal of the prohibition. In consultations w= ith ICANN that started in 2017, we came to understand that the existence of= an RFC on this topic (i.e., TXT records in the TLD DNS zone) could help fT= LD, and registry operators like ourselves, overcome this obstacle with ICAN= N. It is for this reason and to further enhance the security of our TLDs th= at we undertook this work within the IETF.

As I=E2=80=99ve shared ca= ndidly with Seth Blank, Scott Kitterman, Murray Kucherway and more recently= Tim Wicinski, my expertise is more in the policy arena than technical and = I=E2=80=99ve done all I can to stay abreast of this work, contribute when a= ppropriate and drive it in any way possible as I said earlier to it success= ful conclusion.

At this point I=E2=80=99d appreciate understanding = what obstacles remain and what fTLD, and our internal working group, can do= to advance this work.

Thanks very much and good luck this week at I= ETF.

Craig
--

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



=


On Fri, Nov 13, 2= 020 at 1:42 PM Tim Wicinski <tjw.i= etf@gmail.com> wrote:

All


During the IESG reviews of draft-ietf-dmarc-psd, there were s= everal issues raised with some of the document. =C2=A0 Most of them are edi= torial but the one big item was the description of the Experiment. =C2=A0 T= he chairs sat down and broke out the experiment section into three separate= experiments, and included language on how to capture the data to confirm h= ow the experiment worked.=C2=A0


It's enough of a change that we wanted to do a sec= ond working group last call to make sure the working group agrees with our = changes. The diff of the current version with the previous version is here:= =C2=A0


https://www.ietf.org/rfcdiff?= url1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-ietf-dmarc-psd-09


This starts a *on= e* week second working group last call for=C2=A0 draft-ietf-dmarc-psd

Please review the cha= nges and offer up comments to the working group.


This working group last call 20 November 2020

<= br>

Thanks,


<= br>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000acfc1e05b43a5a8c-- From nobody Mon Nov 16 10:40:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918333A13F5 for ; Mon, 16 Nov 2020 10:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUnx33MnHBYi for ; Mon, 16 Nov 2020 10:40:10 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276D13A13CA for ; Mon, 16 Nov 2020 10:40:09 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id n129so18470099iod.5 for ; Mon, 16 Nov 2020 10:40:09 -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=CLsZ7r7H6j5d1Tbv4E5vkZMngzyk+oqDZ8Q5ugQZ2ms=; b=VEN/dA3wgewf5z6UWUpbxx7IIpi2baZkY8DhpCr9UziaD2/EkwaBZjNUFyVTL/BPDj xjfdoofLfx1N0EP51wDLCqW/IQs4oNfM8dLMgO8s7XPPRLF2NfmReUJu2l6LqzlRUScm NnVqx+7Bz0X5OLAHr9jJWL60RZbgOf/Pg3uM8= 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=CLsZ7r7H6j5d1Tbv4E5vkZMngzyk+oqDZ8Q5ugQZ2ms=; b=oEonurQtbZxaWxu5L3ddF1H+w9nnl0JreLdkmwz65xMPW5wkOhmC7a8eUIltY/+vMq E+SP4KdThoqoc3L4ygaFnlkPO5VWnAqCJZJ8hHRh0pU+HSfXVqFxewyVAmlpttwY6TFn R1Wdt19cbcc1pngeZEG9j7WW4GFzquyu4WED/5IANMi4svzz+I2PHRe0eGC0Ghgi3dBt +Fheuynx7KBWW1rIpz947XJnaBC0SDHuG/85MKpsA9T4YumvBkMPpIXCcTZiLBQw9ypS BHNF/2y7yNoOTJ9pskn/ELc9yID6rOCgW19excbOVkLf6V0kfRqnlYcTsS459eY3vmsH B40w== X-Gm-Message-State: AOAM532RhGrxWVasYfvQ3MTxXhMQlW6ULM4+rrzNqzOYCv061POnMOrH P3lVQoaBXgGbGeFHw8g/Jts1mrgPukTYuSo7sX8idg== X-Google-Smtp-Source: ABdhPJzCober13S1XfYIAC+qleojEP8pAFTVbaIJpAy2EoAzIYBzpdixGCQPjOR2byJwGB4VCtPUFY63nde1/ul3Kqc= X-Received: by 2002:a05:6638:626:: with SMTP id h6mr715935jar.15.1605552009151; Mon, 16 Nov 2020 10:40:09 -0800 (PST) MIME-Version: 1.0 References: <20201115202114.E4225271B9ED@ary.qy> In-Reply-To: <20201115202114.E4225271B9ED@ary.qy> From: "Kurt Andersen (b)" Date: Mon, 16 Nov 2020 10:39:56 -0800 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , tjw ietf Content-Type: multipart/alternative; boundary="0000000000002ca23105b43db5de" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 18:40:14 -0000 --0000000000002ca23105b43db5de Content-Type: text/plain; charset="UTF-8" On Sun, Nov 15, 2020 at 12:21 PM John Levine wrote: > In article wm5WLTcgiB0JBY0GubntOp3Qhzfr68YB2__RRNg@mail.gmail.com> you write: > > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 > > > >Please review the changes and offer up comments to the working group. > > I looked at it, seems fine as an experiment. > > If we end up changing the way regular DMARC looks for Org domains, PSD > might become redundant. Or not. +1 on both counts. --Kurt --0000000000002ca23105b43db5de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 15, 2020 at 12:21 PM John Lev= ine <johnl@taugh.com> wrote:
In article <CADyWQ+HWEK=3Dwm5WLTcgiB0JBY0Gub= ntOp3Qhzfr68YB2__RRNg@mail.gmail.com> you write:
>ht= tps://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-= ietf-dmarc-psd-09
>
>Please review the changes and offer up comments to the working group.
I looked at it, seems fine as an experiment.

If we end up changing the way regular DMARC looks for Org domains, PSD
might become redundant. Or not.

+1 on both = counts.

--Kurt
--0000000000002ca23105b43db5de-- From nobody Mon Nov 16 10:57:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302B43A0418 for ; Mon, 16 Nov 2020 10:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digilicious.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 JHQWJBD7u3CI for ; Mon, 16 Nov 2020 10:57:42 -0800 (PST) Received: from digilicious.com (digilicious.com [108.83.36.113]) (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 ED3083A03F1 for ; Mon, 16 Nov 2020 10:57:41 -0800 (PST) Received: from digilicious.com (digilicious.com [108.83.36.113]) by digilicious.com (Postfix) with ESMTPSA id 0A94E26132F for ; Mon, 16 Nov 2020 10:57:40 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 digilicious.com 0A94E26132F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digilicious.com; s=default; t=1605553060; bh=5a83XTQZjXvUgEi5wSdWI3Q0KYbqWQ0FIp0CZy8oBHg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SDnp1ucKzHGirNOVkk17XAOusDXbchjHaBaQrLQJ2Zx0YYXTi5PcTIfW/jLBnnLjr mBCiSFFvbu7xRPeUjSSyffJ/YCR0gUuS0y3zRao/zG2/9C9VveFZXjbGS7cGPJMAJ5 NhYmz8l5PLh9LcP+eGf6fUruwYpomYki+3OZ38oY= To: dmarc@ietf.org References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> From: Gene Hightower Message-ID: Date: Mon, 16 Nov 2020 10:57:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <160513169495.16356.6565556939968267867@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5lO31HPMUhSrJX9Xxn4TVRTQXCtqm3Tw1" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Mon, 16 Nov 2020 18:57:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5lO31HPMUhSrJX9Xxn4TVRTQXCtqm3Tw1 Content-Type: multipart/mixed; boundary="Y4be9x7ZbmEc20y9CG1hXz1cvefa0pA7j"; protected-headers="v1" From: Gene Hightower To: dmarc@ietf.org Message-ID: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.txt References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: <160513169495.16356.6565556939968267867@ietfa.amsl.com> --Y4be9x7ZbmEc20y9CG1hXz1cvefa0pA7j Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable =46rom the document: > 4.1. Authentication Mechanisms > The following mechanisms for determining Authenticated Identifiers > are supported in this version of DMARC: [=E2=80=A6] > [RFC3986], which can authenticate both the domain found in an > [RFC5322] HELO/EHLO command (the HELO identity) and the domain found > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the > result of SPF authentication of the MAIL FROM identity. Section 2.4 > of [RFC7208] describes MAIL FROM processing for cases in which the > MAIL command has a null path. RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Sy= ntax.=E2=80=9D I suspect a reference to RFC-7208 was intended here. RFC-5322 is the standard for the Internet Message Format, which doesn't have a HELO/EHLO. I suspect a reference to RFC-5321 was intended here. So, maybe this section should read: =E2=80=9C[RFC7208], which can authenticate both the domain found in an [RFC5321] HELO/EHLO command (the RFC5321.HELO identity) and the domain found in an SMTP MAIL command (the RFC5321.MailFrom identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [RFC7208] defines the MAIL FROM identity for cases in which the MAIL command has a null path.=E2=80=9D --Y4be9x7ZbmEc20y9CG1hXz1cvefa0pA7j-- --5lO31HPMUhSrJX9Xxn4TVRTQXCtqm3Tw1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEWOWxKLajOgqXlD8w8MVtphHqSPUFAl+yy6MACgkQ8MVtphHq SPWZRQ//fRvPAk3gH48piSjXBGPNHRJMMyl0Q3VKgxjKLqLLN0Ly+6ClP2H10Sa5 DeApl+R9KuT45gcTv/Av6Q4SS5OoOzMUv5yO0ma79OQNYG8qk4Rv+HORy090ieA9 qHjzragp3s4+yH+++lI9J7wwfc4ALJdnXhvhihVsCum1lbL4HAVo2YwISb6+4y3Q Jwas3enOChl+Db5HzjHzTctRrHa9O9zbf3AfwuQ6uMDl9lzWNyKsUrFyQbcDy2Xo SLgrhNZUqMDGeOdXUSKfU4m2HTlKKQIOQd1zbKzMhI0WmBU5Xnr/sxEiJhDLhKir 083MZZLp40RFdxYB+xyl47aMEjFav9YYsssgiQf1LAcOL5gJHl6sICA+rH62pPt1 bGcJuqq7jOHWjY9d9XKK/M/i7anPjwc/HXn9YCdoYNMLKRagB9PyeCnA6oCeV8GT n3UeLP3cpXVulkk/OncCVSpqRh5IiKHVrBrq4Ri1VZvjBznCY/P3YdGDYCPPvHEJ Xu89S0mKd5B8gmsNB7rZA0Zs9Bha4TBvhpDiyQWXHqoM3XdDcnaCdQh5FCdv8W5V DDq65BGGkiBapbYtEhqVZbejKh6WHq2xCO8NaGnvnir2argZOkfIxWxOFoPGiaug PLMDYxU2mX6R5tPVO9bQfIzh7Tlt4FE/c1VWncEjsSwvfmkKVvU= =NcfM -----END PGP SIGNATURE----- --5lO31HPMUhSrJX9Xxn4TVRTQXCtqm3Tw1-- From nobody Mon Nov 16 16:38:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350833A178C for ; Mon, 16 Nov 2020 16:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 BQouxoiuSE5J for ; Mon, 16 Nov 2020 16:38:40 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 59DA33A178A for ; Mon, 16 Nov 2020 16:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jJPIYEEmwTn6+4IDfQRqIhdHURw2SdAga8FXthYJ8wo=; b=b0eQn6bHS3zZ0RMfXm/zZV6EQl h+djobFTShX1FRa+8plHwYBgS2vCYXP0cfzehNTmpuftYGZTSsQlzBxS3odLp+iwLdPZLwWI3T5bX ToetMeqjxa90MhCKMwjK2zccHROQPRauBArQnsF8V9IrrNYW+vVTxhbdlDqL7fXRpmuY=; Received: from [2601:647:4400:1261:6158:38b2:21ec:77f6] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kep12-00081d-S7; Mon, 16 Nov 2020 16:38:39 -0800 From: "Jim Fenton" To: "Tim Wicinski" Cc: "IETF DMARC WG" Date: Mon, 16 Nov 2020 16:38:36 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_63AFA329-61FE-4FC0-B827-8AC68704DD62_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[560, 2015], "plain":[229, 1085], "uuid":"5CAAACAB-4190-4641-95DF-30B66F29B02D"}] Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 00:38:42 -0000 --=_MailMate_63AFA329-61FE-4FC0-B827-8AC68704DD62_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit So what’s the conclusion on this? I still see the dmarc meeting on the agenda page, but without any agenda or meeting materials (unlike virtually every other WG meeting). -Jim On 13 Nov 2020, at 12:26, Tim Wicinski wrote: > Dave > > It's the latter. Alexey and I are quite fine with running the > meeting, > that was part of our conversation. > > tim > > > On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker wrote: > >> On 11/13/2020 10:40 AM, Tim Wicinski wrote: >>> During the chairs call this morning we were discussing the upcoming >>> meeting. Now Seth has a conflict with the meeting time that can't >>> be >>> altered. Since work items have been progressing rather well >>> recently, >>> and the editors are in positing, we discussed canceling the meeting. >>> We >>> wanted to get some feedback from the working group. >>> >>> Here is a lightweight agenda Seth put together. Should we 1) have a >>> meeting around these topics; 2) discuss other topics or 3) cancel >>> the >>> meeting and keep moving along. >> >> >> Four days before a scheduled, rare meeting, it's being canceled >> because >> one of its 3 chairs can't attend? >> >> Or because it has suddenly been realized that the meeting won't be >> useful? >> >> Really? >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --=_MailMate_63AFA329-61FE-4FC0-B827-8AC68704DD62_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">So what=E2=80=99s the conclusion on this? I still see the = dmarc meeting on the agenda page, but without any agenda or meeting mater= ials (unlike virtually every other WG meeting).

-Jim

On 13 Nov 2020, at 12:26, Tim Wicinski wrote:


Dave
<= br>
It&= #39;s the latter.=C2=A0 =C2=A0Alexey and I are quite fine with running=C2= =A0the meeting, that was part of our conversation.

tim


On Fri, Nov 13, 2020 a= t 3:23 PM Dave Crocker <dhc@dcrock= er.net> wrote:
On 11/13/2020 10:40 AM, Tim Wicinski wrote:
> During the chairs call this morning we were discussing the upcoming =
> meeting.=C2=A0 Now Seth has a conflict with the meeting time that ca= n't be
> altered.=C2=A0 =C2=A0Since work items have been progressing rather w= ell recently,
> and the editors are in positing, we discussed canceling the meeting.= =C2=A0 We
> wanted to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.=C2=A0 Should we 1) h= ave a
> meeting around these topics;=C2=A0 2) discuss other topics or 3) can= cel the
> meeting and keep=C2=A0moving along.


Four days before a scheduled, rare meeting, it's being canceled becau= se
one of its 3 chairs can't attend?

Or because it has suddenly been realized that the meeting won't be us= eful?

Really?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net=

______________________= _________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--=_MailMate_63AFA329-61FE-4FC0-B827-8AC68704DD62_=-- From nobody Mon Nov 16 19:16:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEEE3A067A for ; Mon, 16 Nov 2020 19:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 N4EJfxJBVUmn for ; Mon, 16 Nov 2020 19:16:44 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 E30F23A0603 for ; Mon, 16 Nov 2020 19:16:43 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id erU2kszyOwDxzerU2kAtOZ; Tue, 17 Nov 2020 03:16:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1605583002; bh=NdIV1m5jwJK0+TklFo4TvQB3jpPmruUxm6rKKiD+34Q=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=G+P2mL1Zcr5Qyc2cnHLnCu2lswL6MIonrSA3VV5CxqAV9P9HdSdSWvNz104VdFztT kCvcPoPRkHwl3OCkdE+q47U8QGCWDRUp3w4TW57q2YvYnr5UjGYytG5efaJfIQ+cLA ZNSIUi3oY2n0Q8J/poI0rLbTtTvL6lnmGlFMzwIWAxeANaZCtikLXGJqcmogZiXC5g KBUq8rfSjwa+YSAklC2+yEDGAhN/qk8kCXmsskrYvvcSbk0H0N+ENCJSTek97c4fNh v8XzKmtUxxCqG4Il5nY/KfAS3D1sVKcfsqpV0XtiMW+U2wOryj116izrnAVJIvyYmY RYUqj39ab1HyQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id erU0kEeT2BuUOerU1kDLyX; Tue, 17 Nov 2020 03:16:42 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0AH3GeTR008694; Mon, 16 Nov 2020 22:16:40 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0AH3GdSv008687; Mon, 16 Nov 2020 22:16:39 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Tim Wicinski Cc: scott@kitterman.com, last-call@ietf.org, dmarc@ietf.org, gen-art@ietf.org, draft-ietf-dmarc-psd.all@ietf.org In-Reply-To: (tjw.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 16 Nov 2020 22:16:39 -0500 Message-ID: <87ima4wu3s.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 03:16:46 -0000 Tim Wicinski writes: > Apologies for the delay on the PSD updates. I sat down with Scott and went > through your review and made lots of edits > related to your comments. I actually attached the reply to your email as > it's been sitting in my editor buffer for a few months too long. > > One normative change that I want your assistance on is the descriptions of > the Experiments. I updated them and pulled them apart, to make them more > understandable to folks looking at this for the first time. I'm not still > 100% on them. > > I want to go back through your opening Nits/editorial comments to make sure > I'm not missing anything. > > Here's the link to the diff. > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 My apologies for not tending to this promptly. In regard to the description of the experiments, the result criteria are rather subjective, but I don't see that as a problem. It does seem to me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is too narrow, as only the 3rd experiment seems to be about privacy issues. A title as generic as "PSD DMARC Experiments" would be fine. Looking at the diffs, I notice that I find the new sections 2.3 through 2.6 straightforward. Oddly, they aren't much different than what is in the -08, which I found confusing. It's not clear why ... Perhaps it is because the -09 version starts with attention on "organizational domain", which one has an intuitive understanding of, and defines the other terms from there, whereas the -08 seems to focus on "PSD". Although I note that even the -09 does not define "PSD", only "longest PSD", even though "PSD" is used in section 2.5. I suspect that PSD is equal to "PSO Controlled Domain Name", though, or rather to some related set of them. That needs to be cleaned up in some way. In section 3.5 and later there is the phrase "[this document] longest PSD". I'm not sure, but I think this is supposed to be "longest PSD ([this document] section NN.NN)". I believe that my strongest critique was that section 1 is difficult to understand if one does not already understand DMARC, and it does not seem that the section has been revised. Re-reading it, I notice that it says "DMARC leverages public suffix lists to determine which domains are organizational domains." Ignoring that I dislike this use of "leverage", a critical point is that it takes the existence of public suffix lists a priori -- indeed, this use of "leverage" generally means that the leveraged thing already exists and one is now extracting additional benefit from that. Whereas I've never heard of public suffix lists and would naively expect that they are difficult to create and maintain. It might be better to say "DMARC uses public suffix lists to determine which domains are organizational domains. Public suffix lists are obtained/maintained/distributed by ..." Looking at the second paragraph of section 1, I notice that despite all the special terms for classifying domain names in section 2, the example in this section does not describe which of the domain names that it mentions fall into which of these classes. E.g. "tax.gov.example" is said to be registered, but it looks like it is also the organizational domain, and "gov.example" is its longest PSD. It would also help to mention that "tax.gov.example" is "registered at" "gov.example" to introduce the details of the usage "registered at". Suppose there exists a domain "tax.gov.example" (registered at "gov.example") ... Dale From nobody Mon Nov 16 22:41:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE073A1190 for ; Mon, 16 Nov 2020 22:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZJePy98IlMG for ; Mon, 16 Nov 2020 22:41:39 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 3FEC83A10FB for ; Mon, 16 Nov 2020 22:41:32 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id t8so10518717vsr.2 for ; Mon, 16 Nov 2020 22:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cg5yWD3Slfj4U+mt+YM2XAJndylcZYsJo8wycqCXY0k=; b=MSBQNL5gM0RykSteZw4Im2nItTGyl6G9TsCZPPc5yofcTOW17Rh0MErhLty+5tZWHa isLCMZ2K8el08rT5df3kXZgZiiH1JoXQT/jW0oXDEsgstqcUs+bFMJgYSIOEnIsgIC7i mLTUJxPXnEfZ8f9hjV5BgiBJsHrgKamrth1WBUetyQAUmU3cROIqoRZdjqiKG2Tgf9rX 09Ff0J0Q+auEvxtsksBvFcJpDwnhajQRAk5hTZW87BOt7GS3AFuA8N8cVhqExRgn4DMI h1/37Dv7eWxrSjriosZ+f/WGoX+q39g4mObJpsp07ewLR1SpXa8w9S6/Y/hnpulSzgnY PX3Q== 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=Cg5yWD3Slfj4U+mt+YM2XAJndylcZYsJo8wycqCXY0k=; b=Q4wparrTZsh4QoK4H52jCym8AO+KahO++ZzKRuhx1OPcV74Z/lkhTlBbXEcD/l0Q4G ORdwYBeuljp2s1SV+eU98Pa5jGIAaIM9fn4bff79QDuQj1D8qoa4Q7X2Bv4a88CKS1mk UbZiDnlYTjGKEzBnf1duFanoh6C9ryfubQ1l89GTIrekl4lwtJ7TByd4w499F9nn+xql YTlX3s43br7c7sZkmSBm7FY7t6zupBh8hW4Ar8DZKijL46cI8tgff71qxrVE5Tfvlx3K uAKrHAn16yew5jRTBbY5kqjiipUm61ERYOteLksWQRR/bMBO/UMZpcC4hIHtIMKAWLbo zP2Q== X-Gm-Message-State: AOAM5310B7TBGdmsZGR+fLpptUJrfXyK4a3ds3+j+XBFHg+5MfDe3bC/ 0UVFCRbiVrnRG1OIpXTcR0fer8oP6nnF536rBowbjkCm X-Google-Smtp-Source: ABdhPJy5+z4IB4KL6yRf7kbB02fvsgIg77mZmX3m3IiopTEaDkquv0PMZXTAbhEiq3G7JRwJueOszB+iyfF56NGkFNU= X-Received: by 2002:a05:6102:21c6:: with SMTP id r6mr10170661vsg.0.1605595290952; Mon, 16 Nov 2020 22:41:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 16 Nov 2020 22:41:17 -0800 Message-ID: To: Todd Herr Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000f8680005b447c825" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 06:41:44 -0000 --000000000000f8680005b447c825 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 13, 2020 at 12:35 PM Todd Herr wrote: > I vote option 3. There's quite a lot of meaty discussion to be had on > these topics, and I can't see any of them reaching consensus or anything > close to it during the 30 minutes or so each would be allotted. > My understanding is that consensus calls from meetings still have to be confirmed with the list before they become action items, so this by itself isn't a reason to cancel. -MSK --000000000000f8680005b447c825 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 13, 2020 at 12:35 PM Todd Her= r <todd.herr=3D40valima= il.com@dmarc.ietf.org> wrote:
I vote opt= ion 3. There's quite a lot of meaty discussion to be had on these topic= s, and I can't see any of them reaching consensus or anything close to = it during the 30 minutes or so each would be allotted.

My understanding is that consensus calls from meeting= s still have to be confirmed with the list before they become action items,= so this by itself isn't a reason to cancel.

-= MSK
--000000000000f8680005b447c825-- From nobody Mon Nov 16 22:47:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B053A105C for ; Mon, 16 Nov 2020 22:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6GxCdG-fxtw for ; Mon, 16 Nov 2020 22:47:03 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40CE3A1051 for ; Mon, 16 Nov 2020 22:47:02 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id u7so10486954vsq.11 for ; Mon, 16 Nov 2020 22:47:02 -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=U+vUZ8ASGQs+OiF5+Ru7NTzQtcQK0KM7iV/DgIMJJIw=; b=qYAvg35xe+7vicoxmYCCyXxNRrVYvOWwTYzV/shIoLLZ81AwK+HshI7woLKjswbndO 616fOF6qzEE1MPUPl66A1GH2Tv11lC7xZJ8F/mOUARl4BzjGHt35GdrILGL24m5tGhHC j0GZ0/FR/hoxu24MYPwaT0lPPcqy0HpGXP4zkfy2eqDj67beb0bzaH3e/OJl1KAfUFf1 7lkVCh2/lA+wS4o5qIe69ej0yQIPvhwhiMp9nuQ1UI46K52kmgrKl+MNG4wVBAE3x/q8 MlyO2N5Bcb03Psa8bWVq3JK1gsSvYGuHh0KRC5l16r+oRGTBHr/xlY7NotBsYWj+u95s ROPg== 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=U+vUZ8ASGQs+OiF5+Ru7NTzQtcQK0KM7iV/DgIMJJIw=; b=AIUz3yRAG+nn9EbXzDjMxX4BRv8dLGXyIUPT+OVNu+9eh6MlfBx4lMUPJB7y70BX8V 2HT0zzrpchkbqvwhJaui9i4UraxwBrsJL3pVQEyKtbU3YSe5NDs1aTBHBn9FoJ26e751 TGigKfCMetunjw52+U946is3MBmuboqOAwX4cstG5Nk/VIeIjPPJDJ5aX2c0qAoW2nKt Yu+/uFdTTq59AkHwc96V3Ao4/pMkCN7se7UR+NHvo5ITGaJYTZp7Lpbv0+k6ZOFzfL5S 4kRt1ISnFkcDfLjI+PYVYG0zqxnwp2J+w8AGcy4ZQwEfBNRrBts/yQGxBG67SoPgWXMw Qwtw== X-Gm-Message-State: AOAM53259qakm8Kjzlq7oG4SKwmjvzNLW/+AkjhwseR+PMJ/9b/b6gAw nyP2yewXfAcsE40g2zgIyjlli0YzC5fjrNaTC44= X-Google-Smtp-Source: ABdhPJxRTzLyET7AZifcn5wSDdJUz50/rI0Yu9JtbgwQKs+X9k9c/zGeadt3/G5EFIBKtU2Pum1G8L+QlZCBG9FPNGI= X-Received: by 2002:a05:6102:21c6:: with SMTP id r6mr10176408vsg.0.1605595621846; Mon, 16 Nov 2020 22:47:01 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Mon, 16 Nov 2020 22:46:48 -0800 Message-ID: To: Jim Fenton Cc: Tim Wicinski , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000b1749105b447dc64" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 06:47:05 -0000 --000000000000b1749105b447dc64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm discussing this with the chairs and they or I will get back to you shortly. -MSK, ART AD On Mon, Nov 16, 2020 at 4:38 PM Jim Fenton wrote: > So what=E2=80=99s the conclusion on this? I still see the dmarc meeting o= n the > agenda page, but without any agenda or meeting materials (unlike virtuall= y > every other WG meeting). > > -Jim > > On 13 Nov 2020, at 12:26, Tim Wicinski wrote: > > > Dave > > It's the latter. Alexey and I are quite fine with running the meeting, > that was part of our conversation. > > tim > > > On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker wrote: > >> On 11/13/2020 10:40 AM, Tim Wicinski wrote: >> > During the chairs call this morning we were discussing the upcoming >> > meeting. Now Seth has a conflict with the meeting time that can't be >> > altered. Since work items have been progressing rather well recently= , >> > and the editors are in positing, we discussed canceling the meeting. >> We >> > wanted to get some feedback from the working group. >> > >> > Here is a lightweight agenda Seth put together. Should we 1) have a >> > meeting around these topics; 2) discuss other topics or 3) cancel the >> > meeting and keep moving along. >> >> >> Four days before a scheduled, rare meeting, it's being canceled because >> one of its 3 chairs can't attend? >> >> Or because it has suddenly been realized that the meeting won't be usefu= l? >> >> Really? >> >> d/ >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000b1749105b447dc64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm discussing this with the chairs and they or I= will get back to you shortly.

-MSK, ART AD

On Mon, Nov 16, 2020 at 4:38 PM Jim Fenton <fenton@bluepopcorn.net> wrote:

So what=E2=80=99s the conclusion on this? I still see the dmar= c meeting on the agenda page, but without any agenda or meeting materials (= unlike virtually every other WG meeting).

-Jim

On 13 Nov 2020, at 12:26, Tim Wicinski wrote:


Dave

It's the latter.=C2=A0 =C2=A0Ale= xey and I are quite fine with running=C2=A0the meeting, that was part of ou= r conversation.

tim

On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker <dhc@dcrocker.net> wrote:
On 11/13/2020 10:40 AM,= Tim Wicinski wrote:
> During the chairs call this morning we were discussing the upcoming > meeting.=C2=A0 Now Seth has a conflict with the meeting time that can&= #39;t be
> altered.=C2=A0 =C2=A0Since work items have been progressing rather wel= l recently,
> and the editors are in positing, we discussed canceling the meeting.= =C2=A0 We
> wanted to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.=C2=A0 Should we 1) hav= e a
> meeting around these topics;=C2=A0 2) discuss other topics or 3) cance= l the
> meeting and keep=C2=A0moving along.


Four days before a scheduled, rare meeting, it's being canceled because=
one of its 3 chairs can't attend?

Or because it has suddenly been realized that the meeting won't be usef= ul?

Really?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000b1749105b447dc64-- From nobody Mon Nov 16 22:54:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491AA3A109F for ; Mon, 16 Nov 2020 22:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM8RRnO12tz8 for ; Mon, 16 Nov 2020 22:54:34 -0800 (PST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 8E7973A10A2 for ; Mon, 16 Nov 2020 22:54:34 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id f7so10501669vsh.10 for ; Mon, 16 Nov 2020 22:54:34 -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=guIGV1HW/qWkr+jvnt9eISWZGJ5wRGZuuyo60QkATqY=; b=Z8UqHGL5YRU9nBgMrukpHAWgXS/88tQe+mJt/MnJIDv6Y0k3saaqWymuwEVfyrYvXR sp2QT0ZcFOabJ2v4DbxLAKPz5L9TT6lMMP82xDI3idQRn14b6HAS6L0HOrjdGuENPztx 6DSkgBH651c0LKBO9nbonAeXA2Epb+20I7Q1TPsEBfYZAQKqpGIlFEP8r3r3cnNtoZcM gS6jutvuc3AY9SVMlW7i6t1rykSi2ydd5e3FDIX2XfhO/Yyka64XSHxQhyGAqdP9GwsV CnEIponOXrHgGxSWtzapVVz2nfJGzS9Rq5qBptoVc/LmiU76phw8SdhBdr3K+qiaGeq4 SAUg== 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=guIGV1HW/qWkr+jvnt9eISWZGJ5wRGZuuyo60QkATqY=; b=L4lfELrFj/0ktbXAcBgCnU45i1G6HtlYaCzOg7S+vnOAv09s8u7HLpg40FwK1wfQVZ 0vY+GCxDKcbNWMliw7lTuL5H0PtGBRBo4AwdN+8Gg6b65zUk+ENgynr2J+saSAFOuuYx RJB8KA39ZhEaT8FDTcl7iW13dVyMIJqLjTVQEr5NjGQfYvmjn/ELPJ4XN+GJ98uNGvoZ m2OayOlH41yQvAqre5AplpBsSkkHlpTorbzf/nyUAFMExJmku9qwf46YX7OGy6KGjvKM GRJqLZVyb08ZKMDuVmh95U68aL1mT9r8gZd9wA3q4uVg+6Rnkle3XhpAB3LNG0G3JzU/ NAAQ== X-Gm-Message-State: AOAM5310x4H0GWs7GXuXY06sMuok/iNCEs3ag9vVjDJd2NVHLbZX7Eiz Hb6WA0spDIQPuUdyEbN5WIFFwZpK8/3rP0RoN2A= X-Google-Smtp-Source: ABdhPJwHT1hDsnW3uhhVJDJBsBG0BtejmV2CfW7DyuS+IJOY68nIN9aqPnjdXu69TK4NkcKb34Ckk++DgywufZjkZiY= X-Received: by 2002:a67:ec10:: with SMTP id d16mr10533967vso.33.1605596073588; Mon, 16 Nov 2020 22:54:33 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 16 Nov 2020 22:54:20 -0800 Message-ID: To: Jim Fenton Cc: Tim Wicinski , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000009e7a8f05b447f7c5" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 06:54:36 -0000 --0000000000009e7a8f05b447f7c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the meeting were to be held, who (besides Jim) was planning to attend? -MSK, ART AD On Mon, Nov 16, 2020 at 10:46 PM Murray S. Kucherawy wrote: > I'm discussing this with the chairs and they or I will get back to you > shortly. > > -MSK, ART AD > > On Mon, Nov 16, 2020 at 4:38 PM Jim Fenton wrote= : > >> So what=E2=80=99s the conclusion on this? I still see the dmarc meeting = on the >> agenda page, but without any agenda or meeting materials (unlike virtual= ly >> every other WG meeting). >> >> -Jim >> >> On 13 Nov 2020, at 12:26, Tim Wicinski wrote: >> >> >> Dave >> >> It's the latter. Alexey and I are quite fine with running the meeting, >> that was part of our conversation. >> >> tim >> >> >> On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker wrote: >> >>> On 11/13/2020 10:40 AM, Tim Wicinski wrote: >>> > During the chairs call this morning we were discussing the upcoming >>> > meeting. Now Seth has a conflict with the meeting time that can't be >>> > altered. Since work items have been progressing rather well >>> recently, >>> > and the editors are in positing, we discussed canceling the meeting. >>> We >>> > wanted to get some feedback from the working group. >>> > >>> > Here is a lightweight agenda Seth put together. Should we 1) have a >>> > meeting around these topics; 2) discuss other topics or 3) cancel th= e >>> > meeting and keep moving along. >>> >>> >>> Four days before a scheduled, rare meeting, it's being canceled because >>> one of its 3 chairs can't attend? >>> >>> Or because it has suddenly been realized that the meeting won't be >>> useful? >>> >>> Really? >>> >>> d/ >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --0000000000009e7a8f05b447f7c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the meeting were to be held, who (besides Jim) was= planning to attend?

-MSK, ART AD

On = Mon, Nov 16, 2020 at 10:46 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
I'm discussi= ng this with the chairs and they or I will get back to you shortly.

-MSK, ART AD

On Mon, Nov 16, 2020 at 4:38 PM Jim= Fenton <fen= ton@bluepopcorn.net> wrote:

So what=E2=80=99s the conclusion on this? I still see the dmar= c meeting on the agenda page, but without any agenda or meeting materials (= unlike virtually every other WG meeting).

-Jim

On 13 Nov 2020, at 12:26, Tim Wicinski wrote:

=

D= ave

<= /div>
It's = the latter.=C2=A0 =C2=A0Alexey and I are quite fine with running=C2=A0the m= eeting, that was part of our conversation.

tim


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 13, 2020 at 3:23 PM Dave C= rocker <dhc@dcrock= er.net> wrote:
On 11/13/2020 10:40 AM, Tim Wicinski wrote:
> During the chairs call this morning we were discussing the upcoming > meeting.=C2=A0 Now Seth has a conflict with the meeting time that can&= #39;t be
> altered.=C2=A0 =C2=A0Since work items have been progressing rather wel= l recently,
> and the editors are in positing, we discussed canceling the meeting.= =C2=A0 We
> wanted to get some feedback from the working group.
>
> Here is a lightweight agenda Seth put together.=C2=A0 Should we 1) hav= e a
> meeting around these topics;=C2=A0 2) discuss other topics or 3) cance= l the
> meeting and keep=C2=A0moving along.


Four days before a scheduled, rare meeting, it's being canceled because=
one of its 3 chairs can't attend?

Or because it has suddenly been realized that the meeting won't be usef= ul?

Really?

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000009e7a8f05b447f7c5-- From nobody Tue Nov 17 01:28:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4CF3A0D68 for ; Tue, 17 Nov 2020 01:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mimecast.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy8A9mm_p278 for ; Tue, 17 Nov 2020 01:28:38 -0800 (PST) Received: from eu-smtp-1.mimecast.com (service-alpha-uk-a.mimecast.com [195.130.217.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4072E3A0997 for ; Tue, 17 Nov 2020 01:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mimecast.com; s=20130419; t=1605605316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=PUyiOQlX1MSeYG+2a4VHQrwtu5HUx2dhKkF8i+Uic1A=; b=LlpVLZ+VAHoM22FavKVd1GOpc62TLfDkz4pfpGQXQ5q4UuvA9qffKhzvU3ecXEMgh6DvEB wXJcIjxtUa3GWEF869p7NVfpdtdITjzFKTRHY7DMEMx1X5q99XAVceWT/ng2OJ74HHOHpC Bq6OHcx5SGdPtXqlTwEwBrzIzRASYHs= Received: from mail.mimecast.com (45.91.17.200 [45.91.17.200]) (Using TLS) by relay.mimecast.com with ESMTP id uk-sl-a-Cj6j-JgZNmmSasS5nIM0UQ-1; Tue, 17 Nov 2020 09:28:34 +0000 X-MC-Unique: Cj6j-JgZNmmSasS5nIM0UQ-1 Received: from LHC-IT-EML-P01.mcsltd.internal (172.17.26.211) by LHC-IT-EML-P03.mcsltd.internal (172.17.26.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Tue, 17 Nov 2020 09:28:31 +0000 Received: from LHC-IT-EML-P01.mcsltd.internal ([fe80::b9f5:2f16:6fee:613d]) by LHC-IT-EML-P01.mcsltd.internal ([fe80::b9f5:2f16:6fee:613d%9]) with mapi id 15.01.2044.007; Tue, 17 Nov 2020 09:28:31 +0000 From: Gren Elliot To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] IETF 109 possible agenda/session discussion Thread-Index: AQHWvMQD0AmilQ1cfUGZ8lo+YGfujg== Date: Tue, 17 Nov 2020 09:28:31 +0000 Message-ID: <4BA72AFF-4058-4F8C-93B9-A5084E634779@contoso.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.26.8] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C1A1 smtp.mailfrom=gelliot@mimecast.com X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: mimecast.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8 Content-ID: <53A40C2F199A674796697350EBF5B5ED@mimecast.com> Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 09:28:40 -0000 PiBJZiB0aGUgbWVldGluZyB3ZXJlIHRvIGJlIGhlbGQsIHdobyAoYmVzaWRlcyBKaW0pIHdhcyBw bGFubmluZyB0byBhdHRlbmQ/DQoNCkkgYW0gLSBhZG1pdHRlZGx5IGJlY2F1c2UgSSB0aG91Z2h0 IHRoaXMgd291bGQgYmUgYSBnb29kIGNoYW5jZSB0byBsZWFybiBtb3JlIGFib3V0IERNQVJDLg0K V291bGQgdGhpcyBub3QgYmUgYSBnb29kIGNoYW5jZSB0byBwb3RlbnRpYWxseSBpbmNyZWFzZSBp bnRlcmVzdD8NCg0KDQo= From alwindebruin@gmail.com Tue Nov 17 01:37:20 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37E3A0D7B for ; Tue, 17 Nov 2020 01:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsUt9w245Cem for ; Tue, 17 Nov 2020 01:37:14 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD943A0D7D for ; Tue, 17 Nov 2020 01:37:08 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id u18so29150550lfd.9 for ; Tue, 17 Nov 2020 01:37:07 -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=NShmKOnkj32+dTf2ZFpR5r2oHI1vpxrWkpNtM3fFelA=; b=sophQdmm2mJAR8SJ3hA7si6W6pgn7n+XpBRIUbUMvo4xZtd36nmMLDROM3D7S0ydrG SGTkza/pFtedxB4Gk9FOZPNA/rEAbSEvAPUagopx5lCkt81KV9T6jYrPk7w1v6HosoyH XjtgW8ye50nZrV/qoVWuReV5e24qsxcR8AM9cN7ugAFvj+r8gZC93YupNyol45d1IzqO HKnCCr18GnxYqb4aXYzqY9ZT/8zDLFPKfi7dsbzXsLEXF4Ly4iMIoHdukBTt/FWbenxh adTu3FGsH/UYzcZyUubTNzFB3z5UpUh/LP4xltV5QF4t015YUH7LPYMo1oTo83gov0EF 5GFQ== 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=NShmKOnkj32+dTf2ZFpR5r2oHI1vpxrWkpNtM3fFelA=; b=iseEr61oXFbfSQ7hQoYuF0em/cRNusSh4j49tB6PPVzSTnpSnXUuFxUkHUmkSg4Vmt X5fJb3sxBHKzqLel7zGFDiI+mVS61FhG707XWPS+9snKP6SuI3i6gJ365Fsrj/3aoD+J nFXL5/PFtb6G3eX/1M5MWPOzYJC2DYsf9BxCVLRXA9VpZgoRMv0lHxVGK8z6zePFpN4R ofv62syEXee8lyIbxOvNEZg2pkloHbDN+WZ0AujX5pWJyKqvgkOm5kVCB+/eB+Xwg5Qb KRAe/irEagkE2hSkt/xMtULadPuuW24kvLQTMSp0lWpVDTd7b9h8lDwkt5mbk4OR8lBZ 3pvw== X-Gm-Message-State: AOAM532Ie7Cjmwkxckle7KRbhJ1vcarsyUU5WeqLfvHVZAMwJhNIjrwA xqYalJ0+F5vRxwxYXyRHgUh19R5BwD8imQQuPUevZFrE1NM= X-Google-Smtp-Source: ABdhPJxLNyAL9/z6sm0sPedh3QkhlUwRIHMA00wnFQGsyJCyukj94ONuqa95fRmT0n9lb3xI0hXmqakItnzqesd/4Is= X-Received: by 2002:ac2:58ee:: with SMTP id v14mr1323134lfo.16.1605605825695; Tue, 17 Nov 2020 01:37:05 -0800 (PST) MIME-Version: 1.0 References: <4BA72AFF-4058-4F8C-93B9-A5084E634779@contoso.com> In-Reply-To: <4BA72AFF-4058-4F8C-93B9-A5084E634779@contoso.com> From: Alwin de Bruin Date: Tue, 17 Nov 2020 10:36:54 +0100 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e3d2c005b44a3cbf" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 09:57:46 -0000 --000000000000e3d2c005b44a3cbf Content-Type: text/plain; charset="UTF-8" > If the meeting were to be held, who (besides Jim) was planning to attend? Scheduled time to be there "virtually" at the meeting. - Alwin On Tue, 17 Nov 2020 at 10:28, Gren Elliot wrote: > > If the meeting were to be held, who (besides Jim) was planning to attend? > > I am - admittedly because I thought this would be a good chance to learn > more about DMARC. > Would this not be a good chance to potentially increase interest? > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000e3d2c005b44a3cbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> If the meeting were to be held, who (besides Jim) was= planning to attend?

Schedu= led time to be there "virtually" at the meeting.

- Alwin

On Tue, 17 Nov 2020 at 10:28, Gren = Elliot <gelliot=3D40mimecast.com@dmarc.ietf.org> wrote:
> If the meeting were to be he= ld, who (besides Jim) was planning to attend?

I am - admittedly because I thought this would be a good chance to learn mo= re about DMARC.
Would this not be a good chance to potentially increase interest?


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000e3d2c005b44a3cbf-- From nobody Tue Nov 17 05:37:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3163A130F for ; Tue, 17 Nov 2020 05:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXoEOCARTUBL for ; Tue, 17 Nov 2020 05:37:05 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 E7C513A130E for ; Tue, 17 Nov 2020 05:37:04 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id f93so15500550qtb.10 for ; Tue, 17 Nov 2020 05:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JaxaqAOUixdOqyIe61MHp5rJ2riLdWoJextqQqO+LOA=; b=CG+jZwN3olosdl3uSG0IcAxKVhdXFUyZdo1RVDbtWLQib0QnavfUmpXfSg+fhsuK27 /H238LZrpJkSqLqMxU88uzVoeYSfdM7Ah+7R9LNJTIm5XuUwkK4FMyTKsd76/3e1qold 25z0JulnaSVf/fjN33oObuZVATpj86Tuuey5L0Tnm5h+TwfVtOzuPN0ZqhK0VFnhICsA OnzJXZBdn770MU3/eIxeRtFbkBCPMxB+0Z1wjNDiOf5N+yISI6UIuE28z8IJoaqxYtmj gVfUHXB8IWoLIFpJ3Ml8cSEfXUWN2fuUJrSYXiGuDygcmFrpoA4d5AtxC20wXhBZY6tX Ch8A== 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=JaxaqAOUixdOqyIe61MHp5rJ2riLdWoJextqQqO+LOA=; b=N8Ff+tkSjyka5nNAX8b/tdW7eg2Ps174LfnWojgR+35RPm01lRuYLuKBAH/z2Hb8WD aO9H93uU2+X9xhFVwHwCVnvAuDoIATIO2s5PE+k6lXkoZHYr6eX5brp+P9k38FLIrgTN nM1WnnCyvZi+slomgbQfSvRqaeZ+vDAn+rBrcT6pw6qRPyDUdvXafzZU6U4SvTkg4pDx Ss7APp5dZVFWRYD3CVsXjZqzcuGwvb5EKnYzjuaNI3gv8JlTV+iX1L2MBHoRBS89ZyEC RmroFakGusSdFzhF1GVNeZ+9AGD/O4XwPbGC56ZqT4QUHvzLYjZmESyUVl8/E6LDPVqA 1qkA== X-Gm-Message-State: AOAM532Psgfd9EK5KVlxJ2HZ+c2XjeM/GpwTRYdElD5vWmwA+7/Oh2fI atoyGTbrY7taxei/CAckVHvSyPN3Y+skifY7iiLK/g== X-Google-Smtp-Source: ABdhPJzDhP+5xzHvKAeHhe4mfHQn8Tts/5XXO2+ZC6swIqCq1522icijtN53ujK/apHYUqCZw64fVSMf7Chy08BCtNk= X-Received: by 2002:ac8:5c54:: with SMTP id j20mr4822116qtj.83.1605620223619; Tue, 17 Nov 2020 05:37:03 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: From: Todd Herr Date: Tue, 17 Nov 2020 08:36:47 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Jim Fenton , Tim Wicinski , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000012cb2205b44d9726" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 13:37:06 -0000 --00000000000012cb2205b44d9726 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 17, 2020 at 1:54 AM Murray S. Kucherawy wrote: > If the meeting were to be held, who (besides Jim) was planning to attend? > > I was planning to attend. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000012cb2205b44d9726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 17, 2020 at 1:54 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
If the = meeting were to be held, who (besides Jim) was planning to attend?

I was planning to attend.=C2=A0

--

Todd Herr | Sr. Technical Program Manager
p: 703.220.= 4153


This email and all data transmitted with it = contains confidential and/or proprietary information intended solely for th= e use of individual(s) authorized to receive it. If you are not an intended= and authorized recipient you are hereby notified of any use, disclosure, c= opying or distribution of the information included in this transmission is = prohibited and may be unlawful. Please immediately notify the sender by rep= lying to this email and then delete it from your system.

<= /span>
--00000000000012cb2205b44d9726-- From nobody Tue Nov 17 06:46:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7D33A13BC for ; Tue, 17 Nov 2020 06:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3yenla2-K1p for ; Tue, 17 Nov 2020 06:46:31 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52573A13C0 for ; Tue, 17 Nov 2020 06:46:30 -0800 (PST) X-ASG-Debug-ID: 1605624385-11fa314802a51f0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id q8qpnG1szty3iwMH (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 17 Nov 2020 09:46:25 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=niamDJ0M6reopRSGwfZddhKOExCwRGEoWt4JExLFJR0=; b=KtD1aATl3jsBJ/nc30qpOEBncOS17USYKrSiEu87nn2SfVA+TYvrGwelJs8otAlRH jvmuxirggz2SXaLvk3cLpTBT0cLOi6FVBMKNzTc82eR0W77Aqo20tYg6irl5do8hu shD0Jfh0p97F2FRgClC7Esvtc17Y1rQ5hEdL8gbrM= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 17 Nov 2020 09:46:18 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF DMARC WG'" Cc: Date: Tue, 17 Nov 2020 09:46:19 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Message-ID: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01D6BCC6.80303DC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ada88GFJ86kRpbyJQy29R2Tb4HxNaA== Content-Language: en-us X-Exim-Id: 003f01d6bcf0$69055b60$3b101220$ X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605624385 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 10555 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85939 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 14:46:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0040_01D6BCC6.80303DC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I did not see a definition of a =E2=80=9Cnon-existent domain=E2=80=9D = (the np policy). A definition is needed. =20 To my thinking, the obvious rule should be to query for a NS record for = the domain. If the record exists, then the domain owner could create a = DMARC record for that domain, or could create a default entry for the = domain at the organizational level. If no record exists, it is because = the domain owner chose to not create one. =20 However, the DMARC Bis document conflicts strongly with this. In = section A.4, it suggest several ways to do a test of this type, then = repudiates all of them. NS lookup is not one of the mentioned options. =20 There is a possible second-level policy test for a =E2=80=9Cmail-enabled = domain=E2=80=9D. I would define that test as =E2=80=9CMX record exists = or SPF policy exists=E2=80=9D. That could be an additional option to = NP, but should not be a replacement for it. =20 PSD for DMARC clearly intends for the NP policy to be a general solution = to a general problem. If there are still objections to it becoming a = general solution, this should be addressed soon. =20 Doug Foster =20 =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski Sent: Friday, November 13, 2020 1:42 PM To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd =20 =20 All =20 During the IESG reviews of draft-ietf-dmarc-psd, there were several = issues raised with some of the document. Most of them are editorial = but the one big item was the description of the Experiment. The chairs = sat down and broke out the experiment section into three separate = experiments, and included language on how to capture the data to confirm = how the experiment worked. =20 =20 It's enough of a change that we wanted to do a second working group last = call to make sure the working group agrees with our changes. The diff of = the current version with the previous version is here:=20 =20 https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dmarc-psd-08 = &url2=3Ddraft-ietf-dmarc-psd-09 =20 This starts a *one* week second working group last call for = draft-ietf-dmarc-psd Please review the changes and offer up comments to the working group. This working group last call 20 November 2020 =20 Thanks, =20 ------=_NextPart_000_0040_01D6BCC6.80303DC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I did not see a definition of a =E2=80=9Cnon-existent domain=E2=80=9D = (the np policy). =C2=A0=C2=A0A definition is = needed.

 

To my thinking, the obvious rule should be to query for a NS record = for the domain. =C2=A0If the record exists, then the domain owner could = create a DMARC record for that domain, or could create a default entry = for the domain at the organizational level.=C2=A0 If no record exists, = it is because the domain owner chose to not create = one.

 

However, the DMARC Bis document conflicts strongly with this.=C2=A0 = In section A.4, it suggest several ways to do a test of this type, then = repudiates all of them.=C2=A0 NS lookup is not one of the mentioned = options.

 

There is a possible second-level policy test for a = =E2=80=9Cmail-enabled domain=E2=80=9D.=C2=A0 I would define that test as = =E2=80=9CMX record exists or SPF policy exists=E2=80=9D. = =C2=A0=C2=A0=C2=A0That could be an additional option to NP, but should = not be a replacement for it.

 

PSD for DMARC clearly intends for the NP policy to be a general = solution to a general problem.=C2=A0=C2=A0=C2=A0 If there are still = objections to it becoming a general solution, this should be addressed = soon.

 

Doug Foster

 

 

From:= = dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim = Wicinski
Sent: Friday, November 13, 2020 1:42 PM
To: = IETF DMARC WG
Cc: dmarc-chairs@ietf.org
Subject: = [dmarc-ietf] Second WGLC for = draft-ietf-dmarc-psd

 

 

A= ll

 

D= uring the IESG reviews of draft-ietf-dmarc-psd, there were several = issues raised with some of the document.   Most of them are = editorial but the one big item was the description of the Experiment. =   The chairs sat down and broke out the experiment section into = three separate experiments, and included language on how to capture the = data to confirm how the experiment worked. 

 

I= t's enough of a change that we wanted to do a second working group last = call to make sure the working group agrees with our changes. The diff of = the current version with the previous version is here: 

 

<= a = href=3D"https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dmarc-psd-08&u= rl2=3Ddraft-ietf-dmarc-psd-09">https://www.ietf.org/rfcdiff?url1=3Ddraft-= ietf-dmarc-psd-08&url2=3Ddraft-ietf-dmarc-psd-09

 

T= his starts a *one* week second working group last call for  = draft-ietf-dmarc-psd

P= lease review the changes and offer up comments to the working = group.

<= br>This working group last call 20 November 2020

 

T= hanks,

 

------=_NextPart_000_0040_01D6BCC6.80303DC0-- From nobody Tue Nov 17 11:35:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4424C3A1588; Tue, 17 Nov 2020 11:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nps57VdmfOX3; Tue, 17 Nov 2020 11:35:31 -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 4E95A3A1585; Tue, 17 Nov 2020 11:35:31 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AHJd24Y011238 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 17 Nov 2020 11:39:02 -0800 Reply-To: dcrocker@bbiw.net To: "Murray S. Kucherawy" , dmarc-chairs@ietf.org Cc: IETF DMARC WG References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> X-Priority: 2 (High) From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 17 Nov 2020 11:35:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.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] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 19:35:32 -0000 On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: > I'm discussing this with the chairs and they or I will get back to you > shortly. Forgive me, but this is all a bit nuts. Very few days before the scheduled session, we get a query about canceling it, though the query also included a fresh, 'lightweight' agenda. A couple of responses are posted, stating a preference for cancellation, with no immediate responses choosing having the meeting (though today, some have). We are now less than 12 hours from the scheduled time and still have not received a definitive decision by the chairs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 17 12:10:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951B23A03F1; Tue, 17 Nov 2020 12:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfjDWA_sg3NT; Tue, 17 Nov 2020 12:10:04 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 F004C3A03EE; Tue, 17 Nov 2020 12:10:03 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id 7so16832379qtp.1; Tue, 17 Nov 2020 12:10:03 -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=oUsRDPxhRbJ8GRxTMCStQXAwinsgtVER0rcj7JZdyAw=; b=gS9Ppu9sZaAfCEMJe5M5beJcjaLlmEiQ06qUzqmWV2MmjLe2QUj1VrOvP72txwbu0G r3CotxafaxIhaeZj76WufqF5wfY0wTroXmWLyaFjAA9Fz4pyY4XqScQCcQeq7wEpCaYp Gw9YK4BJl400x2gbzAF7v2jI7K8kMzEx0Q8ruiWLzpwsB+6n+UE2VWIvxVFoi8yYyP1m j4jgfDfGitj9wJecKyomzb2FpAL8IrgWvLvZV/L4kciTqtODEVbQcr3/OCB+77jq1y0+ pz5LGY/WeX7VygCqj+NRXUGxcDFj/gbLH+G3BmrYRTWcIXrxOVB+oHjATVjLG4sS+/Qh 1bEw== 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=oUsRDPxhRbJ8GRxTMCStQXAwinsgtVER0rcj7JZdyAw=; b=DZfg0CEga1KK2pfq12xGPyTrLtLK23arDuDqrilUybObx7HCQMNLLc8mroeiOpMOQl BV2VqFhUhCqBEyzMkbpN9nJIWat1N/sCbzZw26RgHYK7zThkIJXt5H7R6t9V4FtZXJSD rfyvIG7uFn+iK9EogvKor07zvbaCDeQbAzwPVSgS2jAKiVx6q1t3ZJPAolugsJpB46KA m5lgYid2+SW9fYjWJz0xsOlsV/6sFF09KfiYwahpWJRjnflD9NjzbwLojQjeml/7Gcbt R2vjclitmX2+d/a545sPKXW0aDgNyifbvLO9F7FXQUySYSMZH+v85tMLQIGtaGsmoCjX telw== X-Gm-Message-State: AOAM5324FaZjl1aZVhfNGx7fWfhwXNlLAVtEnxEYqFSIwq1j+pDeXskE L0TwfaRYx9sliOf2QZjK/byNRmJ8h2Ughpag3iLF1DIp X-Google-Smtp-Source: ABdhPJxEjZi4OlspXxkKkMcRgMsnB/Gp3lRa37Xr8H2CbcYO92L0lUsnN0f7VCFbPZPeFmV4WeX96VdC6NZUjjyumPg= X-Received: by 2002:ac8:5c05:: with SMTP id i5mr945365qti.34.1605643803025; Tue, 17 Nov 2020 12:10:03 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: From: Dotzero Date: Tue, 17 Nov 2020 15:09:51 -0500 Message-ID: To: Dave CROCKER Cc: "Murray S. Kucherawy" , dmarc-chairs@ietf.org, IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000083e40705b4531488" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 20:10:06 -0000 --00000000000083e40705b4531488 Content-Type: text/plain; charset="UTF-8" Considering that some of us have to be up in the wee hours to participate, it would be nice to know whether it is happening or cancelled. Just saying. If the agenda is that light weight I may skip it even if held. Michael Hammer. On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker wrote: > On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: > > I'm discussing this with the chairs and they or I will get back to you > > shortly. > > > Forgive me, but this is all a bit nuts. > > Very few days before the scheduled session, we get a query about > canceling it, though the query also included a fresh, 'lightweight' > agenda. > > A couple of responses are posted, stating a preference for cancellation, > with no immediate responses choosing having the meeting (though today, > some have). > > We are now less than 12 hours from the scheduled time and still have not > received a definitive decision by the chairs. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000083e40705b4531488 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Considering that some of us have to be up in the wee = hours to participate, it would be nice to know whether it is happening or c= ancelled. Just saying. If the agenda is that light weight I may skip it eve= n if held.

Michael Hammer.

=
On Tue, No= v 17, 2020 at 2:35 PM Dave Crocker <= dhc@dcrocker.net> wrote:
On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote:
> I'm discussing this with the chairs and they or I will get back to= you
> shortly.


Forgive me, but this is all a bit nuts.

Very few days before the scheduled session, we get a query about
canceling it, though the query also included a fresh, 'lightweight'=
agenda.

A couple of responses are posted, stating a preference for cancellation, with no immediate responses choosing having the meeting (though today,
some have).

We are now less than 12 hours from the scheduled time and still have not received a definitive decision by the chairs.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000083e40705b4531488-- From nobody Tue Nov 17 12:14:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6367D3A03EE for ; Tue, 17 Nov 2020 12:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEQLg6yCaUep for ; Tue, 17 Nov 2020 12:14:16 -0800 (PST) Received: from mail-il1-x131.google.com (mail-il1-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 09F563A0EA6 for ; Tue, 17 Nov 2020 12:13:46 -0800 (PST) Received: by mail-il1-x131.google.com with SMTP id y9so19802547ilb.0 for ; Tue, 17 Nov 2020 12:13:46 -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=Jzs6uUjxv5d6IQf0mT2flZCiIbiKpxyR5+mhZti7wjE=; b=cTweeiv56v17vEzapcTU8ZtS2ANmJzsoY4MosE0805g/SEn5CiCZQOSRQ0rgCaOMJn 8Rh+OBEHa+4+F0TJN2546WX2kgFJRYYuAawowd1IJBYz0LxVvX3BkmhWMfe/zyoNWgij JKaxBHGXqjNw2zyYQxYc8/wvUdvPDgHUe1xCQ= 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=Jzs6uUjxv5d6IQf0mT2flZCiIbiKpxyR5+mhZti7wjE=; b=OglRFsJknfi/vlpYRxJBbMu3J8jrxzPpzFDoSvMryJ33hn92i+R0e/HQHj4acwKGjA fhcdGNxje/892BoAuopssswBydpnXWNbFis0gSKAVilcarBlRQXhJUWb3kp4+NtAaPGw 9nFueLJyTsmASzxA0c6n6mPCAvDJqXq8daX7/t7sB3kLJKmUd83kCJxhDALo4aH/nquX P+iwF25V6zLfKJSa/81YDMpwUpRos2Un2MphC2kkj8CzBfebntqzJGE8nclxt2v4KBRs 4ejJ3o0G+v2MaRRmkxPsSSILi80DcBM8+eK9bPMosh8d/4gGXEkeQLft8TQtnuRvnTbM W9uQ== X-Gm-Message-State: AOAM533SpVhLFtrPBDVOR4SAJ/6iQakQTpnAjp/CwYBxeOptw8ofvX3S wRCNfwYgpAUW90eCd0QvM0czFtR/qijxtCYF1qn7NQ== X-Google-Smtp-Source: ABdhPJy6x3t39jfgoyWr9MpMmo4SibhfGVMCY3bSvwDUnfPQH5BJnxesU8w9ZBj7JW7z0CL8n64BF2w+ASfGmzT90Ec= X-Received: by 2002:a05:6e02:8f:: with SMTP id l15mr8854398ilm.263.1605644026220; Tue, 17 Nov 2020 12:13:46 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: From: "Kurt Andersen (b)" Date: Tue, 17 Nov 2020 12:13:34 -0800 Message-ID: To: Dotzero Cc: Dave CROCKER , IETF DMARC WG , "Murray S. Kucherawy" , dmarc-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1ac9505b4532157" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 20:14:18 -0000 --000000000000d1ac9505b4532157 Content-Type: text/plain; charset="UTF-8" +1 to being able to sleep through the night and deal with issues asynchronously on the list. --Kurt On Tue, Nov 17, 2020 at 12:10 PM Dotzero wrote: > Considering that some of us have to be up in the wee hours to participate, > it would be nice to know whether it is happening or cancelled. Just saying. > If the agenda is that light weight I may skip it even if held. > > Michael Hammer. > > On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker wrote: > >> On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: >> > I'm discussing this with the chairs and they or I will get back to you >> > shortly. >> >> >> Forgive me, but this is all a bit nuts. >> >> Very few days before the scheduled session, we get a query about >> canceling it, though the query also included a fresh, 'lightweight' >> agenda. >> >> A couple of responses are posted, stating a preference for cancellation, >> with no immediate responses choosing having the meeting (though today, >> some have). >> >> We are now less than 12 hours from the scheduled time and still have not >> received a definitive decision by the chairs. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d1ac9505b4532157 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to being able to sleep through the night and deal with = issues asynchronously on the list.

--Kurt

On Tu= e, Nov 17, 2020 at 12:10 PM Dotzero <dotzero@gmail.com> wrote:
Considering that some of us have t= o be up in the wee hours to participate, it would be nice to know whether i= t is happening or cancelled. Just saying. If the agenda is that light weigh= t I may skip it even if held.

Michael Hammer.<= br>

On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker <dhc@dcrocker.net> wrote:
On 11/16/2020 10:46 PM= , Murray S. Kucherawy wrote:
> I'm discussing this with the chairs and they or I will get back to= you
> shortly.


Forgive me, but this is all a bit nuts.

Very few days before the scheduled session, we get a query about
canceling it, though the query also included a fresh, 'lightweight'=
agenda.

A couple of responses are posted, stating a preference for cancellation, with no immediate responses choosing having the meeting (though today,
some have).

We are now less than 12 hours from the scheduled time and still have not received a definitive decision by the chairs.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d1ac9505b4532157-- From nobody Tue Nov 17 14:00:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991923A0E59; Tue, 17 Nov 2020 14:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.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 vF5BeBBvQ6se; Tue, 17 Nov 2020 14:00:42 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 1967B3A0E4B; Tue, 17 Nov 2020 14:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x25nRdVRleYZO9qWEMDYDfZ6NF9DqykRBMaGfnAkqH4=; b=t02+a+IWGxcjGpArApOGhOdrQc M1OWZ/DHVtdDgtF5r3xikPjpFSqlnG61kMReyBUBr6d+AyKmePNMf3B1pgzqxFLtjvOW4NS9glu9V sjxSpo+zk0vXq0+jomKScfWgOm3g1hjz8GovJeVJCIOBUWhnIcmfalc+lrHuHE6Uor5I=; Received: from [2601:647:4400:1261:bdd1:595c:6104:38d0] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kf91a-000436-4g; Tue, 17 Nov 2020 14:00:30 -0800 From: "Jim Fenton" To: dcrocker@bbiw.net Cc: "Murray S. Kucherawy" , dmarc-chairs@ietf.org, "IETF DMARC WG" Date: Tue, 17 Nov 2020 14:00:29 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <992DD90D-452A-4DFE-A976-58EE75BBBC5C@bluepopcorn.net> In-Reply-To: References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 22:00:50 -0000 On 17 Nov 2020, at 11:35, Dave Crocker wrote: > On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: >> I'm discussing this with the chairs and they or I will get back to >> you shortly. > > > Forgive me, but this is all a bit nuts. > > Very few days before the scheduled session, we get a query about > canceling it, though the query also included a fresh, 'lightweight' > agenda. > > A couple of responses are posted, stating a preference for > cancellation, with no immediate responses choosing having the meeting > (though today, some have). > > We are now less than 12 hours from the scheduled time and still have > not received a definitive decision by the chairs. +1. Given the amount of activity on the mailing list, it seemed obvious to me that we would benefit from some higher-bandwidth interaction. But apparently that’s less obvious to others. If the meeting is held, I will be there (since it’s 9-11 pm here in California), but understand if we don’t want to keep others up for a less than fully productive meeting. -Jim From nobody Tue Nov 17 15:10:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CBB3A0EDF; Tue, 17 Nov 2020 15:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxUuoR1wB9BI; Tue, 17 Nov 2020 15:10:02 -0800 (PST) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 55E093A0EDE; Tue, 17 Nov 2020 15:10:02 -0800 (PST) Received: by mail-vk1-xa34.google.com with SMTP id o73so23803vka.5; Tue, 17 Nov 2020 15:10:02 -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=k/XSypiCu95ghsIOnln3SITdANvmcy3lWY/i17SJJiI=; b=cASvjcps6U4PNHbLAsWLRUlw34/IwhsdcjX0mXy05DbDtb8ufu484Z/uDMs050ksJE w6oRX7qrw/uOglI7tmXrdl4rTT2a3RILrnwLUiErRw+Y0W+YYOA5xXS7ODAs2NovqQ+y 4dM1NyTzRhpnCYGladzeVUUvpTB8sbje8k5SRyiw9Zn44YMWlIg8HTaiZbo5s3OLggzP C5m7mg8pWuz1U+rLT4mcfnTOpj3LO5sbQUOedjig5TPFUhriMa0gd7d5AexeS2lNZt2g O4cG7t8q/WVbQSj75fpaIikbBnb2OBsRZU+TYd3z8QX1tP65/PnJoNxt2E1P1sB0fz36 7xcA== 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=k/XSypiCu95ghsIOnln3SITdANvmcy3lWY/i17SJJiI=; b=bOHnb3sm0yK9FHp0gE4SFek5MY/0W44kPZaLjpUu/5m8iw4xgCN1etw8Z90VPMgYPO L97Oe2Exo69Raw+BZomNdM8Pp3fLwlae/6R5fTgmeJB9UBF0q4Z2uwD85B8KUECmgK0Z tT4491okXKntt0L0BWC9d91b0g+RCAG0lQm3xOd8PrQ7DbdevR/MDgcqDTZIL9cUJ+Fx 0Lz744+z0eJW+i7WYzm9J007TLgbTHEl8P3+Q7Q7zGeIk7xb/qmh0VWZYtVaay6OBJA1 F7jaE4xOOC9cpyKVZ+wwL5HI6wlDyJdrGFYQFmkes3lXZVMXJ5GjSfLeFMAkJmZWTIvl r0pw== X-Gm-Message-State: AOAM531mzwWQthXFLcgvxc50TywDK0lvAMfmNI8CJlZ8lhTgXPZhPhQE 3IdWGuaI5H0WsUKn0LbKGR5O7HJs/f1Zg3JWorI= X-Google-Smtp-Source: ABdhPJx/zxZ1zCFUFbWv6vrqwShnfTGGRvpFE9QSb9xWspgDCI6hu/Uhe9nMZCNNGlxoUDNVMspv0/pIlyFZx5wYcDg= X-Received: by 2002:a1f:3655:: with SMTP id d82mr1441217vka.22.1605654601257; Tue, 17 Nov 2020 15:10:01 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 17 Nov 2020 15:09:49 -0800 Message-ID: To: Dotzero Cc: Dave CROCKER , dmarc-chairs@ietf.org, IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000023d96005b4559817" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 23:10:04 -0000 --00000000000023d96005b4559817 Content-Type: text/plain; charset="UTF-8" Yes, I apologize for not getting back to the WG as promised. The meeting will proceed as scheduled. -MSK, ART AD On Tue, Nov 17, 2020 at 12:10 PM Dotzero wrote: > Considering that some of us have to be up in the wee hours to participate, > it would be nice to know whether it is happening or cancelled. Just saying. > If the agenda is that light weight I may skip it even if held. > > Michael Hammer. > > On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker wrote: > >> On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: >> > I'm discussing this with the chairs and they or I will get back to you >> > shortly. >> >> >> Forgive me, but this is all a bit nuts. >> >> Very few days before the scheduled session, we get a query about >> canceling it, though the query also included a fresh, 'lightweight' >> agenda. >> >> A couple of responses are posted, stating a preference for cancellation, >> with no immediate responses choosing having the meeting (though today, >> some have). >> >> We are now less than 12 hours from the scheduled time and still have not >> received a definitive decision by the chairs. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > --00000000000023d96005b4559817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I apologize for not getting back to the WG as pr= omised.=C2=A0 The meeting will proceed as scheduled.

-MSK, ART AD

On Tue, Nov 17, 2020 at 12:10 PM Dotzero <dotzero@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Cons= idering that some of us have to be up in the wee hours to participate, it w= ould be nice to know whether it is happening or cancelled. Just saying. If = the agenda is that light weight I may skip it even if held.
<= br>
Michael Hammer.

On Tue, Nov 17, 2020 at 2:35 PM Dave= Crocker <dhc@dcro= cker.net> wrote:
On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote:
> I'm discussing this with the chairs and they or I will get back to= you
> shortly.


Forgive me, but this is all a bit nuts.

Very few days before the scheduled session, we get a query about
canceling it, though the query also included a fresh, 'lightweight'=
agenda.

A couple of responses are posted, stating a preference for cancellation, with no immediate responses choosing having the meeting (though today,
some have).

We are now less than 12 hours from the scheduled time and still have not received a definitive decision by the chairs.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000023d96005b4559817-- From nobody Tue Nov 17 15:19:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D76B3A0F44; Tue, 17 Nov 2020 15:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Ckm9UC-DQn; Tue, 17 Nov 2020 15:19:29 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A773A0EB3; Tue, 17 Nov 2020 15:19:26 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id l22so12088990vsa.4; Tue, 17 Nov 2020 15:19:26 -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=t8AoUjnb2AtVJTmhSrypkrgQnK277VdgQpxows6tZN8=; b=mK7WmAivKMiw5R7xrqu9hbybA14E8Ts/xoXCRirpQhTJtrMdDZHHZsCxu8pAdR60kI GRXvcRnwuQMt6LFc3au36YAYJMFKodPDYJkJZckmIqA8mL880x0hx/0nMeEdFcwdxyuu JDr98DgE7RLuGkNYOPYdwvt3vOJGAsIfEMqZMiUBmBSb1i8ief4jeyjV5tIuO3GX73HD mRbtl6W431wt0+AhAmg82GkcU0pl+kmyzSPJ0Kh/v1ezfl3T4P2RT/j/7OHeGqZM4W9g NvvN7EYVRh1tAuGQucC3ZdheAlEmPmqurWRaUD09nXcTRj6GWcIhUzThQsKy6plm9iHY KPVg== 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=t8AoUjnb2AtVJTmhSrypkrgQnK277VdgQpxows6tZN8=; b=FCcyJyzRiytrGxeZoBFyxBqo7OxL8haBGQ0XNYYCKT1xyhJeMctooKR/GX+QNO+jWO nKOXybJ5jjt0MHoHEsE+NCzf+L+KymcxDtmrQUMrxq34UPQaNKMMQRdd0DkKxs9O5yrW 2CjPR7FQjPNhy4FrN5S9l6XgEdO6GHGB1HwGPjGdZPUB6Cu6KdAS9lpm6EqQ1z0ojdZt KrowuWOJBvwxxiusWQ2ROOo76AdQwcQREckjVS8fapbiAcqINflIdU2iR8Dw2qtwE5CQ XjJF7BuqN4w1vE8tPdke/ttwBlDi+mCT0SL2GvjLS2O9jUqnpjiC7ZD4UDaGa7rU/CFV xhtQ== X-Gm-Message-State: AOAM532B59wMSB5j5NIIkryN9pbD1D0KXymR20OKo+VQJXamyBl6VvkK 55AEO6GAi714pmKihAYSzisFXdz5fIP8rY7NnEE= X-Google-Smtp-Source: ABdhPJy8/HS6Zlf7bgOMuefBREErDKzZonJr3TU6GXcdJXGVu0pn4HQAP+Av1tbxqqNx7013YBJSsMeeSweB2VEn58k= X-Received: by 2002:a67:6981:: with SMTP id e123mr1727182vsc.40.1605655165635; Tue, 17 Nov 2020 15:19:25 -0800 (PST) MIME-Version: 1.0 References: <801158ba-fcef-1bf3-497a-89e08c0005ec@dcrocker.net> <9BAE8F43-9B78-4352-A111-9549B7C46EDB@bluepopcorn.net> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 17 Nov 2020 15:19:13 -0800 Message-ID: To: Dotzero Cc: Dave CROCKER , dmarc-chairs@ietf.org, IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000c790e605b455b938" Archived-At: Subject: Re: [dmarc-ietf] IETF 109 possible agenda/session discussion X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 17 Nov 2020 23:19:31 -0000 --000000000000c790e605b455b938 Content-Type: text/plain; charset="UTF-8" To be clear, I encouraged the chairs to hold the meeting as scheduled. My reasons: a) It is likely some people registered for IETF 109 specifically to attend this and maybe one or two other email-related meetings, possibly at their own expense. Canceling this late in the game does them a disservice. b) Canceling simply on the basis that it's late at night for some people doesn't seem compelling in the IETF context. c) As Jim suggested, high-bandwidth discussion will be useful, even if the list of attendees is relatively small, as any consensus they develop needs to be verified with the list anyway. d) My own reading is that more people would likely attend than those who expressed interest in canceling. -MSK, your ART AD On Tue, Nov 17, 2020 at 3:09 PM Murray S. Kucherawy wrote: > Yes, I apologize for not getting back to the WG as promised. The meeting > will proceed as scheduled. > > -MSK, ART AD > > On Tue, Nov 17, 2020 at 12:10 PM Dotzero wrote: > >> Considering that some of us have to be up in the wee hours to >> participate, it would be nice to know whether it is happening or cancelled. >> Just saying. If the agenda is that light weight I may skip it even if held. >> >> Michael Hammer. >> >> On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker wrote: >> >>> On 11/16/2020 10:46 PM, Murray S. Kucherawy wrote: >>> > I'm discussing this with the chairs and they or I will get back to you >>> > shortly. >>> >>> >>> Forgive me, but this is all a bit nuts. >>> >>> Very few days before the scheduled session, we get a query about >>> canceling it, though the query also included a fresh, 'lightweight' >>> agenda. >>> >>> A couple of responses are posted, stating a preference for cancellation, >>> with no immediate responses choosing having the meeting (though today, >>> some have). >>> >>> We are now less than 12 hours from the scheduled time and still have not >>> received a definitive decision by the chairs. >>> >>> d/ >>> >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> --000000000000c790e605b455b938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, I encouraged the chairs to hol= d the meeting as scheduled.=C2=A0 My reasons:

a) It is l= ikely some people registered for IETF 109 specifically to attend this and m= aybe one or two other email-related meetings, possibly at their own expense= .=C2=A0 Canceling this late in the game does them a disservice.

b) Canceling simply on the basis that it's late at night for som= e people doesn't seem compelling in the IETF context.

c) As Jim suggested, high-bandwidth discussion will be useful, even= if the list of attendees is relatively small, as any consensus they develo= p needs to be verified with the list anyway.

d) My= own reading is that more people would likely attend than those who express= ed interest in canceling.

-MSK, your ART AD

On Tue, Nov 17, 2020 at 3:09 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
Yes, I apol= ogize for not getting back to the WG as promised.=C2=A0 The meeting will pr= oceed as scheduled.

-MSK, ART AD
On Tue, = Nov 17, 2020 at 12:10 PM Dotzero <dotzero@gmail.com> wrote:
Considering that so= me of us have to be up in the wee hours to participate, it would be nice to= know whether it is happening or cancelled. Just saying. If the agenda is t= hat light weight I may skip it even if held.

M= ichael Hammer.

On Tue, Nov 17, 2020 at 2:35 PM Dave Crocker <dhc@dcrocker.net>= ; wrote:
On 11/1= 6/2020 10:46 PM, Murray S. Kucherawy wrote:
> I'm discussing this with the chairs and they or I will get back to= you
> shortly.


Forgive me, but this is all a bit nuts.

Very few days before the scheduled session, we get a query about
canceling it, though the query also included a fresh, 'lightweight'=
agenda.

A couple of responses are posted, stating a preference for cancellation, with no immediate responses choosing having the meeting (though today,
some have).

We are now less than 12 hours from the scheduled time and still have not received a definitive decision by the chairs.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000c790e605b455b938-- From nobody Tue Nov 17 21:35:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A9D3A147F for ; Tue, 17 Nov 2020 21:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN93vHlExoqn for ; Tue, 17 Nov 2020 21:35:31 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 98A8B3A145A for ; Tue, 17 Nov 2020 21:35:31 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id g17so846179qts.5 for ; Tue, 17 Nov 2020 21:35:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iSCQcTeOU6eOB/ZuMxMbH4EJIcJ3Bi7JsaEWfNRPZcA=; b=M+SwC5AGDR0PRIfQ8HEVMoQ6/EK44CHw5mARyxY4JKjSp0IthelDSXCAf2hX4fApWg vYcwpXPqG7LhXQqRptVUjFlsYKpjDSndPWz+ME0hGqMEwWYvmGjWcxHhlOjjCdOX69b5 In3FrJXNQ5vR/ctSAIjQyXijJSRsX0uQIxFNJEvnI4cceggmFbxti0ELZIUP7XoV/TPs 8FGOJCk6h1TLEYEN1+JBfvriKuYDu2joj0FJXQgL8MkljsO/yC9wdp0jTScD6se8bgpW IehSVP9W8wmSBHn/QtBpvjsRCRO4edrndVD9aDroFXTPr+T3V4a2exJc7BVpNGS3ED6n vR5A== 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=iSCQcTeOU6eOB/ZuMxMbH4EJIcJ3Bi7JsaEWfNRPZcA=; b=CLtxIg1PLb1hCpvq3hlv086oNkNxgKmyDs3USzWwTdyFKRNX2XkpG8LSqePN9++mSR ukFPaCK0Cn73NkC+dQUWNsB2fgDtmjrbCZuH8YYuNUp6dHOtrVUhQnGUahxeS8Ebi3xG GWfePsdyYh5c+bYcj/71DgqH1vuytOITqTX9FPlgDZ5G3g9iR9TIPDeITvBXBDN55XM0 zH7RfkzLXy91VK1dqE9PUsC7XR53ZM09vpPqpfjLbmECup/z2KUbDC0St8wcmigRgSs8 TYlfqs+1Ly8Cr25IMJHWJwubGl12yG6/wFRZZCra8AwHjp8gKtWf2LiHOfkhwv+7DvT4 f5zg== X-Gm-Message-State: AOAM5321Lwf7zyCZYV3vR9sLj6b2LRRUSrUJbo9+HsDc6TiDz6IqLphc hv3pzIAPfrBPtSzGKq9uP+6Ff5hmZbpQ7+x61WOpRGzjoq0= X-Google-Smtp-Source: ABdhPJylCxUJQGigC5WRIhxtHZFimcnEkvGU64YdNESRuEQBIk1PesaJxhJriqc7PCvpNjWN5FHIs5icG22JGUUZFKw= X-Received: by 2002:ac8:5c54:: with SMTP id j20mr3026643qtj.83.1605677730171; Tue, 17 Nov 2020 21:35:30 -0800 (PST) MIME-Version: 1.0 References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: From: Todd Herr Date: Wed, 18 Nov 2020 00:35:14 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000bb24e305b45afa78" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Wed, 18 Nov 2020 05:35:40 -0000 --000000000000bb24e305b45afa78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2020 at 1:57 PM Gene Hightower wrote: > From the document: > > > > > 4.1. Authentication Mechanisms > > > The following mechanisms for determining Authenticated Identifiers > > are supported in this version of DMARC: [=E2=80=A6] > > > [RFC3986], which can authenticate both the domain found in an > > [RFC5322] HELO/EHLO command (the HELO identity) and the domain found > > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the > > result of SPF authentication of the MAIL FROM identity. Section 2.4 > > of [RFC7208] describes MAIL FROM processing for cases in which the > > MAIL command has a null path. > > RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Sy= ntax.=E2=80=9D > I suspect a reference to RFC-7208 was intended here. > > RFC-5322 is the standard for the Internet Message Format, which doesn't > have a HELO/EHLO. I suspect a reference to RFC-5321 was intended here. > > So, maybe this section should read: > > =E2=80=9C[RFC7208], which can authenticate both the domain found in an > [RFC5321] HELO/EHLO command (the RFC5321.HELO identity) and the > domain found in an SMTP MAIL command (the RFC5321.MailFrom > identity). DMARC uses the result of SPF authentication of the MAIL > FROM identity. Section 2.4 of [RFC7208] defines the MAIL FROM > identity for cases in which the MAIL command has a null path.=E2=80=9D > > Thank you, Gene. The text in question is taken directly from RFC 7489, so I'll follow up with the authors of that document to get clarity on what was intended, and change the new base spec if necessary. --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000bb24e305b45afa78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 16, 2020 at 1:57 PM Gene High= tower <dmarc@digilicious.com> wrote:
From the document:

<https://www.ietf.org/archive/id= /draft-ietf-dmarc-dmarcbis-00.html:>

> 4.1. Authentication Mechanisms

> The following mechanisms for determining Authenticated Identifiers
> are supported in this version of DMARC: [=E2=80=A6]

> [RFC3986], which can authenticate both the domain found in an
> [RFC5322] HELO/EHLO command (the HELO identity) and the domain found > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the
> result of SPF authentication of the MAIL FROM identity. Section 2.4 > of [RFC7208] describes MAIL FROM processing for cases in which the
> MAIL command has a null path.

RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Synt= ax.=E2=80=9D
I suspect a reference to RFC-7208 was intended here.

RFC-5322 is the standard for the Internet Message Format, which doesn't=
have a HELO/EHLO. I suspect a reference to RFC-5321 was intended here.

So, maybe this section should read:

=E2=80=9C[RFC7208], which can authenticate both the domain found in an
=C2=A0[RFC5321] HELO/EHLO command (the RFC5321.HELO identity) and the
=C2=A0domain found in an SMTP MAIL command (the RFC5321.MailFrom
=C2=A0identity). DMARC uses the result of SPF authentication of the MAIL =C2=A0FROM identity. Section 2.4 of [RFC7208] defines the MAIL FROM
=C2=A0identity for cases in which the MAIL command has a null path.=E2=80= =9D


Thank you, Gene.

<= div>The text in question is taken directly from RFC 7489, so I'll follo= w up with the authors of that document to get clarity on what was intended,= and change the new base spec if necessary.
=C2=A0
-- =

Todd Herr | Sr. Technical Program Manager
p: 703.220.4153


This email and all data transmitted with it contains confidential an= d/or proprietary information intended solely for the use of individual(s) a= uthorized to receive it. If you are not an intended and authorized recipien= t you are hereby notified of any use, disclosure, copying or distribution o= f the information included in this transmission is prohibited and may be un= lawful. Please immediately notify the sender by replying to this email and = then delete it from your system.

--000000000000bb24e305b45afa78-- From nobody Tue Nov 17 22:55:12 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C8C3A0BDF for ; Tue, 17 Nov 2020 22:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FySmWNf5DEqq for ; Tue, 17 Nov 2020 22:55:08 -0800 (PST) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 8519C3A0BD6 for ; Tue, 17 Nov 2020 22:55:08 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id a10so336722uan.12 for ; Tue, 17 Nov 2020 22:55:08 -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=GF0wPsJUx5lKX5VDZ852F76JQh1GY1QFTebEwKpejJY=; b=crOODJMy0NiajfEjPkCZrwDOFSixF8knBNyQDOuBMceKPnOIlA4O33ZYA0AFYMss7S KwuKF62iYN4hvnzliZPYUFX7hxaS6g3lFbwIaOLMRVdua/tSz5xWh3lITtndCYSy2F5W Fu8M/+JjUHy2QIsGnmqq8JDxyK7bdV+G9UYMRApeiFBVkWzqw0TgXppEzoGSQ5StwcWZ DI0TPRS1D0dR6oZWnSF99CoPNU8R4+TijUkECXiuBturIOxk6CQh7uZ333+fmCFbakKs HJ9v3phEbPjemlHLiPfgxdWNnSbwpTvFkWbUJBFqevCuZpe6dhptc/SVPy/Xd+6tmTeK Lr3w== 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=GF0wPsJUx5lKX5VDZ852F76JQh1GY1QFTebEwKpejJY=; b=Gu1HTI8SnF0R3jpwImQx+4kVmDAgn5dCA9+AgfGEoxi+gqk01Z0ukncqVjHsMTja31 ARVcR+7nNhRp4XrVuyuK+ZF6B1pNfIFpKG7uzPlQxoxNAOj7tjKXeXaJIJtzEevbNvho 85G7yDR/yVIMV2fBRAEoqjV07b2JDWib90km08yR5Zp+qrHhDIlJXC1I/U84NxHI7d+x +uk9gM44U5n9J3izbIs2i4DAtN2rxVQG13bm3lNk/gHlNVXesbwYpXZgQrLddWTzF7D8 VeN3CgGIyU4a4PxY0d5n6Enq/nFYcNlIpRfNkbxv26Y2nLSTmCJtFHuPD7FALnD/drFP k18A== X-Gm-Message-State: AOAM532n0erDR1dR0UwcTfTQDwDs4GtpuepnMx16Q1BHJY7K/cxqFuvD XYW6NPpzW3Y5PkCDZVaKJ1xoLbIETSTt1rIHSgBGZGJG X-Google-Smtp-Source: ABdhPJx7QP41HIaYBAnj2PCOeQAGfuXBTakk3ZGQ1eXTO2pl8XwqS07DMhovWy0iBTH8pc1iKZRb5sYVJnbcZBFGxfA= X-Received: by 2002:ab0:3774:: with SMTP id o20mr2656552uat.67.1605682507443; Tue, 17 Nov 2020 22:55:07 -0800 (PST) MIME-Version: 1.0 References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 17 Nov 2020 22:54:55 -0800 Message-ID: To: Gene Hightower Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007a723105b45c1787" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Wed, 18 Nov 2020 06:55:10 -0000 --0000000000007a723105b45c1787 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2020 at 10:57 AM Gene Hightower wrote: > From the document: > > > > > 4.1. Authentication Mechanisms > > > The following mechanisms for determining Authenticated Identifiers > > are supported in this version of DMARC: [=E2=80=A6] > > > [RFC3986], which can authenticate both the domain found in an > > [RFC5322] HELO/EHLO command (the HELO identity) and the domain found > > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the > > result of SPF authentication of the MAIL FROM identity. Section 2.4 > > of [RFC7208] describes MAIL FROM processing for cases in which the > > MAIL command has a null path. > > RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Sy= ntax.=E2=80=9D > I suspect a reference to RFC-7208 was intended here. > This error actually exists in at least two other locations in the document. -MSK --0000000000007a723105b45c1787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 16, 2020 at 10:57 AM Gene Hig= htower <dmarc@digilicious.com> wrote:
From the document:

<https://www.ietf.org/archive/id= /draft-ietf-dmarc-dmarcbis-00.html:>

> 4.1. Authentication Mechanisms

> The following mechanisms for determining Authenticated Identifiers
> are supported in this version of DMARC: [=E2=80=A6]

> [RFC3986], which can authenticate both the domain found in an
> [RFC5322] HELO/EHLO command (the HELO identity) and the domain found > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the
> result of SPF authentication of the MAIL FROM identity. Section 2.4 > of [RFC7208] describes MAIL FROM processing for cases in which the
> MAIL command has a null path.

RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Synt= ax.=E2=80=9D
I suspect a reference to RFC-7208 was intended here.
<= br>
This error actually exists in at least two other locations in= the document.

-MSK
--0000000000007a723105b45c1787-- From nobody Wed Nov 18 05:53:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679E13A044A for ; Wed, 18 Nov 2020 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe_zeJxT1NeS for ; Wed, 18 Nov 2020 05:53:04 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 BD7BC3A0365 for ; Wed, 18 Nov 2020 05:53:04 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id j31so1591688qtb.8 for ; Wed, 18 Nov 2020 05:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XnEKgLsJeQ8ZVlEwUkW5AiUKyer1D4BgCLh8C9T2IKw=; b=AF1Fr8TPjWIz2DPnPbT31BYZhkBZxM5AdDixyEbYyo154sqmS78NimwSD+w7qyE0HI jXteiAl8HiqIlePWpy6dcnvs9v27BGctqMMQymuZCVeLfsaRfPenns5tVwAMV6gGB/A+ cnYzdDwN5ApjeRXmMPg0bhZU9Tsc7tGivt4ZpjeJK0LVRXF40cTc6pWDmE+5HBRDe18c QOUM7GAZ9n1mW7wR0e5Gyzj90ceFZmShffGKk2Gs1IJIWSqPEBb8JoilN3o43peghy70 8+Jv2n63OTmMaNqMW+eG90SmXc3Wxy+rvMd8yGY4Z6/RsVwiKLa32SKfgsddbCQuqGvt p5IQ== 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=XnEKgLsJeQ8ZVlEwUkW5AiUKyer1D4BgCLh8C9T2IKw=; b=QxKclgNK2kyHeGbiJLfORJJ4L3QTMd0oLM1x/Fbk9eaQcFa1d+X30Ak0bzxNfGWWPD ITumOm+HN0oPodq+BCPYW2fYBwnZx6BBDBWDLlTniRa2nNZbWNGf7oiAQVe1G2PnrmDN USIG/94iYNAoEFj5nQRm7scsiioikVu9O9bMs7pLhA9mf96SsCuvT4wT6iMhv+HhMaH1 M+lfLhepgZOYAfX1oL7/os2BdhZJeKvkp/M3DAAo1mQsoah4YQ7uXeZ33HhKUXxNBMI3 Hisc6v1C8CUKoriyo5rwpR11aoUBhfvvU2Vj39cJWk1UQzs7zBexNZXY/VM+9c95tnzc 6jRg== X-Gm-Message-State: AOAM5312wScti7W4AhiXhzCusP83avyBp3z2qoX6ShpDBmztTJ+8RBGA ROPpD+GRsFxfEJC3c23LslY5o+W7ZyF5NHli242JtJf4TIc= X-Google-Smtp-Source: ABdhPJzeXatFx9PTDSFndGmGtKXgPbb8sTumIiACARs2HPZEIrRB3ZImyiz8omc4K15R8nPQFGsgM5T6NTVKlJvcoSM= X-Received: by 2002:ac8:5412:: with SMTP id b18mr4898515qtq.220.1605707583404; Wed, 18 Nov 2020 05:53:03 -0800 (PST) MIME-Version: 1.0 References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: From: Todd Herr Date: Wed, 18 Nov 2020 08:52:47 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001f541005b461ee7a" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Wed, 18 Nov 2020 13:53:06 -0000 --0000000000001f541005b461ee7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2020 at 1:55 AM Murray S. Kucherawy wrote: > On Mon, Nov 16, 2020 at 10:57 AM Gene Hightower > wrote: > >> From the document: >> >> >> >> > 4.1. Authentication Mechanisms >> >> > The following mechanisms for determining Authenticated Identifiers >> > are supported in this version of DMARC: [=E2=80=A6] >> >> > [RFC3986], which can authenticate both the domain found in an >> > [RFC5322] HELO/EHLO command (the HELO identity) and the domain found >> > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the >> > result of SPF authentication of the MAIL FROM identity. Section 2.4 >> > of [RFC7208] describes MAIL FROM processing for cases in which the >> > MAIL command has a null path. >> >> RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic S= yntax.=E2=80=9D >> I suspect a reference to RFC-7208 was intended here. >> > > This error actually exists in at least two other locations in the documen= t. > > > Noted. I'll open an issue and make sure the document is updated. --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000001f541005b461ee7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 18, 2020 at 1:55 AM Murray S.= Kucherawy <superuser@gmail.com> wrote:
From th= e document:

<https://www.ietf.org/archive/id= /draft-ietf-dmarc-dmarcbis-00.html:>

> 4.1. Authentication Mechanisms

> The following mechanisms for determining Authenticated Identifiers
> are supported in this version of DMARC: [=E2=80=A6]

> [RFC3986], which can authenticate both the domain found in an
> [RFC5322] HELO/EHLO command (the HELO identity) and the domain found > in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the
> result of SPF authentication of the MAIL FROM identity. Section 2.4 > of [RFC7208] describes MAIL FROM processing for cases in which the
> MAIL command has a null path.

RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Synt= ax.=E2=80=9D
I suspect a reference to RFC-7208 was intended here.
<= br>
This error actually exists in at least two other locations in= the document.


=

Noted.

I'll open an issue = and make sure the document is updated.
=C2=A0
--
<= div dir=3D"ltr" class=3D"gmail_signature">

Todd Herr | = Sr. Technical Program Manager
e:<= span style=3D"vertical-align:baseline"> todd.herr@valimail.com
p: 703.220.4153
=


This email and all data transmitted with it contains confidential and/or = proprietary information intended solely for the use of individual(s) author= ized to receive it. If you are not an intended and authorized recipient you= are hereby notified of any use, disclosure, copying or distribution of the= information included in this transmission is prohibited and may be unlawfu= l. Please immediately notify the sender by replying to this email and then = delete it from your system.

--0000000000001f541005b461ee7a-- From nobody Wed Nov 18 06:26:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781383A09C3 for ; Wed, 18 Nov 2020 06:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5CNjCAyntSG for ; Wed, 18 Nov 2020 06:26:21 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 CC2A23A09C1 for ; Wed, 18 Nov 2020 06:26:21 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id n132so1929415qke.1 for ; Wed, 18 Nov 2020 06:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Y3JHhZi4a+9jU2RyzoJQDsPqwtq1JNS2BGk2gqEyUvA=; b=WW5XYpa3JmV+utiIkGMN5GqtHQWo/gJNKUELy3pA9HHISeAlCdDIA0qSJUAfZSfLNB QhpwyiHOed7YRV8oy/LZce1aEiwl1AsViSww3xlYoq9g6coZpS9fBFtOXXWihWpzylv4 gwvICGl6Df5/WKYVt6MlMoSHHQ0jDRBo5zuecGA70dsZDrRsO+mesSQ12qqMZWH6R43m rvtMBsjO5kk/Qe9ggeG5tSvhVpGLILQrK1Vbjkwfz2wVI5/EP+/g3Ms8qpHID2jk2iT6 hZU14ZaNf6Mr236l0TcOEcEZss1Dub+LRZuhRZ5EA4qdP+yuzsezmr3J7cLNfKqgdtBq xNYw== 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=Y3JHhZi4a+9jU2RyzoJQDsPqwtq1JNS2BGk2gqEyUvA=; b=k2hTcFKkEv3c7clWcs+Y1aLF0CUregu31vfs7UyL99EQldayaHNyCLwBmtHhVyGF1q 5i15RxFV+n0poVDJT8aVkJ5oaQodLCgiJEaLsaNCeF187jGjcsOJ/pobHNvpGN6j1kku hy2Zxkqgx4ebftzdEDCM24FpedjPQfaPYhBwHuiRiza/bpyMGcHceWEVYBKZ3zroyNnC MxY4aACQGyZHq3xt3SHeAzsU/fu/Adr7Md4ZIIux2pJ6J4mH3aJwSIMVYM72Ejk7WDYU 6COg3ykBbKI3uufPr0wPBbWDO9Gh81XfbEdFeFGq51VmrM6SpHda8+QAlSwCaDBWHd8B 3Kbg== X-Gm-Message-State: AOAM532tqiYkG6UVjrx6S0KWUvndFEJUtg4WrApYJL0u+CBn2m/XjBaw Wa+j0uiWjGc4k437TWoTkCz/jWzXxe3bwXd7zj4DNWKEvRVzCQ== X-Google-Smtp-Source: ABdhPJzT2J0B8vtgumZYPLK0raCpHU55v4pKvfOMCXCpDPzVPTctoL1ojNCn5Z6YSHTKDN0tueMJjz6uuu1OG3/mBe0= X-Received: by 2002:a37:b483:: with SMTP id d125mr4890216qkf.456.1605709580290; Wed, 18 Nov 2020 06:26:20 -0800 (PST) MIME-Version: 1.0 References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: From: Todd Herr Date: Wed, 18 Nov 2020 09:26:04 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000002567e605b4626578" Archived-At: Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Wed, 18 Nov 2020 14:26:23 -0000 --0000000000002567e605b4626578 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2020 at 8:52 AM Todd Herr wrote: > On Wed, Nov 18, 2020 at 1:55 AM Murray S. Kucherawy > wrote: > >> On Mon, Nov 16, 2020 at 10:57 AM Gene Hightower >> wrote: >> >>> >>> RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic = Syntax.=E2=80=9D >>> I suspect a reference to RFC-7208 was intended here. >>> >> >> This error actually exists in at least two other locations in the >> document. >> >> >> > Noted. > > I'll open an issue and make sure the document is updated. > Issue 84 is open for this - https://trac.ietf.org/trac/dmarc/ticket/84 --=20 *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000002567e605b4626578 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 18, 2020 at 8:52 AM Todd Herr= <todd.herr@valimail.com&g= t; wrote:
On Wed, Nov 18, 2020= at 1:55 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Mon, Nov 16, 2020 at 10:57 AM Gene Hightower <= dmarc@digiliciou= s.com> wrote:

RFC-3986 is titled =E2=80=9CUniform Resource Identifier (URI): Generic Synt= ax.=E2=80=9D
I suspect a reference to RFC-7208 was intended here.
<= br>
This error actually exists in at least two other locations in= the document.


=

Noted.

I'll open an issue = and make sure the document is updated.
<= br>
=C2=A0Issue 84 is open for this - https://trac.ietf.org/trac/dmarc/ticket/84<= /div>

--

Todd Herr= | Sr. Technical Program Manager
e: <= a href=3D"mailto:todd.herr@valimail.com" target=3D"_blank">todd.herr@valima= il.com
p: 703.2= 20.4153

=


This email and all data transmitted wit= h it contains confidential and/or proprietary information intended solely f= or the use of individual(s) authorized to receive it. If you are not an int= ended and authorized recipient you are hereby notified of any use, disclosu= re, copying or distribution of the information included in this transmissio= n is prohibited and may be unlawful. Please immediately notify the sender b= y replying to this email and then delete it from your system.=

--0000000000002567e605b4626578-- From nobody Wed Nov 18 09:55:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7843A0114 for ; Wed, 18 Nov 2020 09:55:50 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zL3jVz71kPx for ; Wed, 18 Nov 2020 09:55:48 -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 5FC6F3A0B45 for ; Wed, 18 Nov 2020 09:55:13 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AIHwkfS010365 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 18 Nov 2020 09:58:46 -0800 Reply-To: dcrocker@bbiw.net To: IETF DMARC WG From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <9c1dc4dd-48b2-9d2c-4cb4-dac733169a0f@dcrocker.net> Date: Wed, 18 Nov 2020 09:55:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] org domain and dns-perimeter draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 18 Nov 2020 17:55:51 -0000 Given the renewed discussion about organizational domain and alternative boundaries, I'll suggest that this draft from last year might be relevant: DNS Perimeter Overlay > Abstract > > The Domain Name System (DNS) naming syntax provides no meta-data for > indicating administrative transitions through the hierarchy. For > example, it does not distinguish the higher-level portions that > operate as public registries, versus those that operate as private > organizations. This specification creates a basic overlay mechanism > for defining a logical Perimeter between administrative entities > through the naming hierarchy. The mechanism can then be applied for > a variety of independent administrative indications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 18 12:44:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802313A0C43 for ; Wed, 18 Nov 2020 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=Cm2HKPdK; dkim=pass (2048-bit key) header.d=taugh.com header.b=IggIG/L8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXQAKvuBf4tN for ; Wed, 18 Nov 2020 12:44:38 -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 4C9603A07C8 for ; Wed, 18 Nov 2020 12:44:38 -0800 (PST) Received: (qmail 95365 invoked from network); 18 Nov 2020 20:44:37 -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:cleverness; s=17483.5fb587b5.k2011; bh=Oj7cljWsVIGOQG9LmCds56UtNhzwSgQb1BM2nWTPP00=; b=Cm2HKPdKePz02Gh2YBvzClYiIlQZqsvWdE9W8nO9d3WiyVM/IcO137+YS7CywFC4OwjBj/JyexPo9TtGlyhCvugi1fGDVgonyzK49C7PPf8TbcTPItFgNZTHoe8L8wlf9h52+R5U60t5gKvxzYf+Z+26H0uhchz9IiJpz//AVq1yJK02PxUZx1K5PLj4VvMEdD90xX+U5L3mdPgTRlGiR6Y6mniVq4as3pqGxhqWew1cmKHAb3HZPDoLi/v0XeKt/pyHUALEFzHVheQ+jcyDA6/XJS3lnbZmt0yfUQeQwCQztQaL5bsdqmMadlniEjMyxpEsfJbBk7OlkerzcUmkEw== 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:cleverness; s=17483.5fb587b5.k2011; bh=Oj7cljWsVIGOQG9LmCds56UtNhzwSgQb1BM2nWTPP00=; b=IggIG/L8Lx1lJ9EKF+W+3Nn3IZkIqg/bimU+/hukGx8GsNrSzsIKyO84WLd6EvUvbJcaDvobt7KfeUIIES5+cW6CYVlMDruJfLWYYhzukfHRp4j0OhoOkDxKJ/ZOPaB3zoygOINa/uZxnPCfmbTjBMP7JitW38sPurADNqNcfXno9R1PUvXaXxB2VwWbeMo3fkb5UwGoNmKgmETFZDra/fS2G3IMmoxPxSTMfH147nE1Uo9sNgTVBUqyBcAVXglHzhhbZn6jPp8zuU5f4XKJU4XIuBTJK/K7yH9d/FEHy6hPPAD6/8slW6RTAl2RapLcdmHzCPcmvBjOx3Mryl0OFA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 18 Nov 2020 20:44:36 -0000 Received: by ary.qy (Postfix, from userid 501) id 5BE81278D997; Wed, 18 Nov 2020 15:44:36 -0500 (EST) Date: 18 Nov 2020 15:44:36 -0500 Message-Id: <20201118204436.5BE81278D997@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <9c1dc4dd-48b2-9d2c-4cb4-dac733169a0f@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 18 Nov 2020 20:44:41 -0000 If we're going to refight the DBOUND battle, here's another entry, which even has running code. I see no reason to think that we are any more likely to endorse one of these now than we were a few years ago so I encourage the group to limit the debate to the existing Org/PSL kludge and a tree walk. Draft: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/ Code: https://github.com/jrlevine/bound Abstract The organization that manages a subtree in the DNS is often different from the one that manages the tree above it. We describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models and can be queried with a small number of DNS lookups. R's, John In article <9c1dc4dd-48b2-9d2c-4cb4-dac733169a0f@dcrocker.net> you write: >Given the renewed discussion about organizational domain and alternative >boundaries, I'll suggest that this draft from last year might be relevant: > > > DNS Perimeter Overlay > > > > >> Abstract >> >> The Domain Name System (DNS) naming syntax provides no meta-data for >> indicating administrative transitions through the hierarchy. For >> example, it does not distinguish the higher-level portions that >> operate as public registries, versus those that operate as private >> organizations. This specification creates a basic overlay mechanism >> for defining a logical Perimeter between administrative entities >> through the naming hierarchy. The mechanism can then be applied for >> a variety of independent administrative indications. > > >d/ >-- >Dave Crocker >Brandenburg InternetWorking >bbiw.net > From nobody Wed Nov 18 12:55:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7843A0C54 for ; Wed, 18 Nov 2020 12:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GI3uuCrnB-T for ; Wed, 18 Nov 2020 12:55: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 A98473A0C58 for ; Wed, 18 Nov 2020 12:55:06 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AIKwc86031930 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 18 Nov 2020 12:58:39 -0800 To: John Levine , dmarc@ietf.org References: <20201118204436.5BE81278D997@ary.qy> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> Date: Wed, 18 Nov 2020 12:54:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201118204436.5BE81278D997@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] org domain and levine-dbound and dns-perimeter drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 18 Nov 2020 20:55:08 -0000 On 11/18/2020 12:44 PM, John Levine wrote: > so I encourage the group to limit the debate to the existing Org/PSL > kludge and a tree walk. "and a tree walk" is not a minor 'and'. neither conceptually nor operationally. assurances to the contrary notwithstanding. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 18 13:33:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07EB3A0CB5 for ; Wed, 18 Nov 2020 13:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Gm3I87Cs; dkim=pass (2048-bit key) header.d=taugh.com header.b=Jd89fxsP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpVIR7eUC7da for ; Wed, 18 Nov 2020 13:33:34 -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 659673A0CB2 for ; Wed, 18 Nov 2020 13:33:34 -0800 (PST) Received: (qmail 11955 invoked from network); 18 Nov 2020 21:33:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2eb1.5fb5932c.k2011; i=johnl-iecc.com@submit.iecc.com; bh=iQbH719Tl2fgLaXcB5HbAZdClKOiGtq5OnrTCphtwA4=; b=Gm3I87Csqyj6aIkslDbdatT0Mo0Q3QwNbO7DZUN2/vLkzhzBb2KRmMF3Wppbt/VWBtbEl0S7ChmJtnvB721IiVaGe8JirdtJyWEw7GNKxWV1nBvJEMXy6OfdNhBQM0Hwsj3jaea50w2EdtoNS6h1nbMYKHs0K1oUncXBvI0GaPHBtvGj/qSprhJL4Kwa8HlJzG87dwx6Ye10m0fh36xgQnRxEWvIj8Him11jprdxcEwhJWlxAzMmSmjkf+LOj9LHQswj/+RVtEf2MM1ufJlr0M136zrCaCisiVembWeh8495RFXVlrN9mRRw04LOhGaVEmxLT52mS2zX7Xwp2VyNhQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2eb1.5fb5932c.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=iQbH719Tl2fgLaXcB5HbAZdClKOiGtq5OnrTCphtwA4=; b=Jd89fxsPErJVxWJuanEmFdBw9uCS0RuOgWKGPFTwkT2haS86Lutsnni6iNquVYkoCoPGkSrwKTKmSociiEndcXmBcDr94tyj0JBd+cVdGdQdgtq4UNbIN3kKnGyoS83LTN9qqTNh2vyBa+TIZCY15TKIJokRpJRx/ZnjuLw+//fQebiWAl5dcqMeIWLBrIaU09yl6uhNh7x2qAfFKxaY4qjqBvafhL5oY/pKZ04l4LuaFvQa1Ieop3EoI4TZarcFu+EhhUsKhWZvQP5vEfIFTv+3aPeip+viUPeEoZH0xZKZFfRMdYqoXb2N2DSpXDU0eiaCB9r0dtA60PZpdbdWCA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 18 Nov 2020 21:33:32 -0000 Date: 18 Nov 2020 16:33:32 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> References: <20201118204436.5BE81278D997@ary.qy> <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 18 Nov 2020 21:33:36 -0000 > On 11/18/2020 12:44 PM, John Levine wrote: >> so I encourage the group to limit the debate to the existing Org/PSL >> kludge and a tree walk. > > "and a tree walk" is not a minor 'and'. neither conceptually nor > operationally. assurances to the contrary notwithstanding. I didn't say they were equivalent. But I do think they are the only options that are likely to get much interest from the WG. I think my DBOUND wildcard implementation is wonderful but I don't have much hope of persuading the rest of the world. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Nov 19 04:39:36 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5645B3A0D47 for ; Thu, 19 Nov 2020 04:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2eUFORQT2DL for ; Thu, 19 Nov 2020 04:39:32 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02DE3A0D43 for ; Thu, 19 Nov 2020 04:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605789567; bh=Lec5vyLofOr3HD7SuPIe7nQbFsNt7w+dBVcpQUqSnA0=; l=993; h=To:References:From:Date:In-Reply-To; b=BQhGimoPx4AGy8+NVSRwAdnOJJVYqNzmPh+M4Ts5Nxb1b+pXDTglHKLl2XXF/6U2h w6lUfmrehueeGgTA2i3yvsf/jrJlCp/dAU/6tOhcplPQJWA1E1OkIW3unkuvBpul8z Fc2vJin4rdicyg+lndwQnIMOujNzXlN/HfdtjYOvd7wSTPqNmwvBsqNDbAdcY Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07E.000000005FB6677F.00007F54; Thu, 19 Nov 2020 13:39:27 +0100 To: dmarc@ietf.org References: <20201118204436.5BE81278D997@ary.qy> <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Thu, 19 Nov 2020 13:39:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Nov 2020 12:39:34 -0000 On 18/11/2020 22:33, John R Levine wrote: >> On 11/18/2020 12:44 PM, John Levine wrote: >>> so I encourage the group to limit the debate to the existing Org/PSL >>> kludge and a tree walk. >> >> "and a tree walk" is not a minor 'and'.  neither conceptually nor >> operationally.  assurances to the contrary notwithstanding. > > I didn't say they were equivalent.  But I do think they are the only options > that are likely to get much interest from the WG. I don't think tree walk is a viable option, as it distorts semantics. But then, we don't need alternatives to the PSL. The whole point is to detach the PSL from the base DMARC spec. Alternatives can be researched afterwards. > I think my DBOUND wildcard implementation is wonderful but I don't have much > hope of persuading the rest of the world. And you don't need to persuade it before releasing the base DMARC spec. AIUI, the purpose of the split is to leave that door opened. Best Ale -- From nobody Thu Nov 19 12:34:08 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3F53A11DB for ; Thu, 19 Nov 2020 12:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smcXVPuLY5f3 for ; Thu, 19 Nov 2020 12:34:05 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 3CDF13A11D9 for ; Thu, 19 Nov 2020 12:34:05 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id z24so3432813qto.3 for ; Thu, 19 Nov 2020 12:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CsL4vARkeCGjabTlhmCeaNMIsj8UutzIa/PXy0m5VwE=; b=LIHqeP3GzHoVLhwW6tkkIy9oQ7F/VACIEGjryKx7QbO59P86NTwDfS5sTBY+5h6vAU sto/YRiVYPiIAzfBbqzb1RUe/Bo4jirH/EakDzqCHTQDuDSd3pkYZTosHKmrt/zDkSl5 GQ5nZYNB/ghqnQCWu7mYuH9+kY0HnMacaD77AqffbgnBc/RriZebK49huulgaU0NtoPj zRxL8hy2w6yhwmNFR2EDhMs9MgOeZO7xFfbfIaqUwhw4SSL4BTfGOdhCEWr7VmdHFvBd Q7nxuiGUupoUeN8YfQAF2Bngh+iiS9XdpNvp9Dud8H2+iAgvyzOQ0pIGYUODnbwt+WRi Poow== 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=CsL4vARkeCGjabTlhmCeaNMIsj8UutzIa/PXy0m5VwE=; b=eUSinH8qfdCAyijxazceECpF8z5eOfuygslWXKLx5SKnleoATLS3M3SEAPW3a7chC0 eSjChwkVLMj+T6A24BIzKKFzmdRK4oMYRbY3ru7lMJ0eejmLd1WJYRbyC2DJcgNObBmZ 9DMpT3y8YQUFyAhbihfHyG5EUjWdBt/W4cR9/Urc59503nBilnfOyPHSVzpu0o14vVEu gSQ53y6eIlnXbHO/hqTMx3ihNoer0yds/AstHo+uNx7aM0PR+WdPCsL2NuMcxt+t1gNc /TntYAoJkNRtMi0ywUQr4abYqwmiqKhFWc0ehhmWW1ybfD04fLBhULLctS+sVpiwGrP0 jWJQ== X-Gm-Message-State: AOAM530JbE9RdUFoprTk2wheFHAuhw6T91UdoJmZ2NKhsKIua89H9zO2 DqfSKKJF2cbij6Q8mCAkwCY+qu659eMEStWeRdY45ldIDmk= X-Google-Smtp-Source: ABdhPJyzKUcA01dx4IHpWsKEvA/rGJPNO1Lb2FNbQfoombOK8qjyHZ1cfCZX7jAGnqSPliRdjUVvU9ImgL/S8PpI7ho= X-Received: by 2002:a05:622a:14e:: with SMTP id v14mr12025887qtw.298.1605818043799; Thu, 19 Nov 2020 12:34:03 -0800 (PST) MIME-Version: 1.0 References: <20201118204436.5BE81278D997@ary.qy> <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> In-Reply-To: From: Todd Herr Date: Thu, 19 Nov 2020 15:33:48 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000013315605b47ba6f4" Archived-At: Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Nov 2020 20:34:07 -0000 --00000000000013315605b47ba6f4 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely wrote: > On 18/11/2020 22:33, John R Levine wrote: > >> On 11/18/2020 12:44 PM, John Levine wrote: > >>> so I encourage the group to limit the debate to the existing Org/PSL > >>> kludge and a tree walk. > >> > >> "and a tree walk" is not a minor 'and'. neither conceptually nor > >> operationally. assurances to the contrary notwithstanding. > > > > I didn't say they were equivalent. But I do think they are the only > options > > that are likely to get much interest from the WG. > > > I don't think tree walk is a viable option, as it distorts semantics. > > Forgive me, but I don't know what you mean by the phrase "distorts semantics"; can you please help me understand? As for the viability of a tree walk, it is possible in complex environments to have something resembling the following: - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent - _dmarc.b.foo.com record exists, p=x, rua=r1 - _dmarc.foo.com record exists, p=y, rua=r2 (The actual p= and rua= values for these two records are of no consequence; in this example it is only required that they differ from each other.) Let's put aside whether or not such a configuration is the ideal way to do things, because that's outside the scope of the working group; let's acknowledge that the "Holy Roman Empire" method of management of DNS and email does exist, and so centralized control of DNS across all organizations is just not possible. With the current DMARC specification, the receiver actions for policy discovery would look first for a policy record at a.b.foo.com, and finding none, would then look at the organizational domain, foo.com. This would result in a policy of y being applied to mail from a.b.foo.com, and aggregate reports going to r2. Perhaps the people in charge of DNS and email for a.b.foo.com intended for this to happen; we can't know their intentions without speaking directly with them (which obviously doesn't scale) but this is what the configuration would yield. On the other hand, one might infer from the DNS records that are published that their intent was for a.b.foo.com to inherit x for the policy and r1 as the destination for aggregate reports from the b.foo.com record; this would be an error on their part, because DMARC does not currently support discovery of the record at _dmarc.b.foo.com in this case. However, it's not hard to see that this might be what they intended, especially if the published policy here is p=none; they may be in the "audit" phase of their DMARC rollout for their portion of foo.com's namespace, wanting reports sent to a mailbox under their local control, so that they can effect change quickly to their mailstreams. The way I see it, we can choose one of three paths here: 1. Keep things as they are, where if there is no policy published for RFC5322.From, the policy is inherited from the org domain, if a policy is published there 2. Change the spec so that the only policy lookup done is for the RFC5322.From domain, and if there's no policy there, then DMARC doesn't exist for that domain 3. Change the spec so that policies published between the RFC5322.From domain and the organizational domain can be discovered, in order to support the most flexibility across organizations. Option 2 would cause the most pain for the current install base of domain owners that publish DMARC policies, because even those who understand DMARC will have to update DNS for domains below the org domain that are used in RFC5322.From headers. Meanwhile, options 2 and 3 would both require code changes for domains that do DMARC validation. The larger point, though, is that there are plausible scenarios that argue for supporting the ability to publish policies somewhere in the DNS hierarchy between the RFC5322.From domain and the organizational domain. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000013315605b47ba6f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 19, 2020 at 7:39 AM Alessandr= o Vesely <vesely@tan= a.it> wrote:
On 18/11/2020 22:33, John R Levine wrote:<= br> >> On 11/18/2020 12:44 PM, John Levine wrote:
>>> so I encourage the group to limit the debate to the existing O= rg/PSL
>>> kludge and a tree walk.
>>
>> "and a tree walk" is not a minor 'and'.=C2=A0 ne= ither conceptually nor
>> operationally.=C2=A0 assurances to the contrary notwithstanding. >
> I didn't say they were equivalent.=C2=A0 But I do think they are t= he only options
> that are likely to get much interest from the WG.


I don't think tree walk is a viable option, as it distorts semantics.

Forgive me, but I don't know wha= t you mean by the phrase "distorts semantics"; can you please hel= p me understand?

As for the viability of a tree wa= lk, it is possible in complex environments to have something resembling the= following:
(The= actual p=3D and rua=3D values for these two records are of no consequence;= in this example it is only required that they differ from each other.)

Let's put aside whether or not such a confi= guration is the ideal way to do things, because that's outside the scop= e of the working group; let's acknowledge that the "Holy Roman Emp= ire" method of management of DNS and email does exist, and so centrali= zed control of DNS across all organizations is just not possible.

With the current DMARC specification, the receiver actions = for policy discovery would look first for a policy record at a.b.foo.com, and finding none, would= then look at the organizational domain, foo.com. This would result in a policy of y being applied t= o mail from a.b.foo.com, and aggregate reports going to r2.

Perhaps the = people in charge of DNS and email for a.b.foo.com intended for this to happen; we can't know = their intentions without speaking directly with them (which obviously doesn= 't scale) but this is what the configuration would yield.
On the other hand, one might infer from the DNS records that ar= e published that their intent was for a.b.foo.com to inherit x for the policy and r1 as the desti= nation for aggregate reports from the b.foo.com record; this would be an error on their part, bec= ause DMARC does not currently support discovery of the record at _dmarc.b.foo.com in this c= ase. However, it's not hard to see that this might be what they intende= d, especially if the published policy here is p=3Dnone; they may be in the = "audit" phase of their DMARC rollout for their portion of foo.com's namespace, wanting reports sent to a = mailbox under their local control, so that they can effect change quickly t= o their mailstreams.

The way I see it, we can choo= se one of three paths here:
  1. Keep things as they are, wher= e if there is no policy published for RFC5322.From, the policy is inherited= from the org domain, if a policy is published there
  2. Change the spe= c so that the only policy lookup done is for the RFC5322.From domain, and i= f there's no policy there, then DMARC doesn't exist for that domain=
  3. Change the spec so that policies published between the RFC5322.Fro= m domain and the organizational domain can be discovered, in order to suppo= rt the most flexibility across organizations.
Option 2 would = cause the most pain for the current install base of domain owners that publ= ish DMARC policies, because even those who understand DMARC will have to up= date DNS for domains below the org domain that are used in RFC5322.From hea= ders. Meanwhile, options 2 and 3 would both require code changes for domain= s that do DMARC validation. The larger point, though, is that there are pla= usible scenarios that argue for supporting the ability to publish policies = somewhere in the DNS hierarchy between the RFC5322.From domain and the orga= nizational domain.

--
=

Todd Herr<= /b> | Sr. Technical Program Manager
=
e: todd.herr@valimai= l.com
p: 703.22= 0.4153

<= span style=3D"font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">


This email and all data transmitted with it cont= ains confidential and/or proprietary information intended solely for the us= e of individual(s) authorized to receive it. If you are not an intended and= authorized recipient you are hereby notified of any use, disclosure, copyi= ng or distribution of the information included in this transmission is proh= ibited and may be unlawful. Please immediately notify the sender by replyin= g to this email and then delete it from your system.

--00000000000013315605b47ba6f4-- From nobody Thu Nov 19 12:45:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B773A11F6; Thu, 19 Nov 2020 12:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqLUyJWeShLD; Thu, 19 Nov 2020 12:45:47 -0800 (PST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF75C3A0B75; Thu, 19 Nov 2020 12:45:46 -0800 (PST) Received: by mail-ot1-x32b.google.com with SMTP id o3so6655190ota.8; Thu, 19 Nov 2020 12:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Uy4iwn3ZejNDaaaMbQwfRWoLH6ZG/GwLdTaNwGYoB+Y=; b=ggqZknHpPBYcKT886rQlcfXdcc2ELHvnE6mM+icPUN2cJLNRXgg9CxgGcU93PpGp8S 7niiB1yELHw10d0KZpH/bOKbpZ07Lrm2kZgK0OFibhV0YFEbvHftT25PcckwoEv3rW/K urbbZpAbhjrRHCu5WNSi8oHvNVyL4IlvesqhBhidgg6gEf3lvH+SnwKEtYSm7AkTVv+P 8WQEcqSDli/EsSIbUgpGdf+pqtVeyViUkyh/TsdUpDIPmSCZ4br1+X/3FPzgSTAYsycR 0ILEHdhyMRMlnQaRsjSikcWkTZi4Q072qL8JEYTk9ahSAnEC4MbrkNcjwn6aKZzRuwrI yzMg== 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:cc; bh=Uy4iwn3ZejNDaaaMbQwfRWoLH6ZG/GwLdTaNwGYoB+Y=; b=rsic4/GOZw1moDcV+LcfFv0LiSUJ2Uk8DqzxgxIHqcW6fyJt3mK+DUX0bpUvSS0d8q Tb3CxzjJ2qtA7lR/P5QLq8KSo2GOKZmgUcWsZ2Th4VaVeFPOB8QtnJ8artrquhvubz3S FEyJu24iCx8qlHW/pkxsbc2JcVIjo1qXnYMl2v7sT3IMcEb/lCiarl+UMRj+Hr1NA7X9 kjkpY/t2ErqbsPFA1IXlj8yUTMRbPa4/2KzzOmEuvDfqg44rurMLSY+u+psSX0Dr8UwP txJ47q8rUWpdKHIBytOk41fIa715EhKZFwdHJPXFzUxLj0/m/pWDJb3Z8NQRnd0wvf2e A33w== X-Gm-Message-State: AOAM531bDI9mqwyEJp2EGZfBped04m0Ck41ov+tLbLWPToUB+1Ulq5aw WOHXOgoO9m5f2n1zCqaJx157tP4vrXrzbClh4MsJiy7jqxI= X-Google-Smtp-Source: ABdhPJz/jkvUepf+0hfbtssqYDnCult09NQHPelB5hw0jn/6EUhsuIa+9F+v9JC3qBFx0XodAFvqvX8Yn4JrzBIYQts= X-Received: by 2002:a9d:4b81:: with SMTP id k1mr11762673otf.371.1605818745994; Thu, 19 Nov 2020 12:45:45 -0800 (PST) MIME-Version: 1.0 From: Tim Wicinski Date: Thu, 19 Nov 2020 15:45:35 -0500 Message-ID: To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Content-Type: multipart/mixed; boundary="000000000000ede7b405b47bcff9" Archived-At: Subject: [dmarc-ietf] Minutes for DMARC meeting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Nov 2020 20:45:49 -0000 --000000000000ede7b405b47bcff9 Content-Type: multipart/alternative; boundary="000000000000ede7b205b47bcff7" --000000000000ede7b205b47bcff7 Content-Type: text/plain; charset="UTF-8" All I've uploaded the minutes into the datatracker. Please take a look to make sure I captured everyone's comments correctly, and let us know updates. https://datatracker.ietf.org/meeting/109/materials/minutes-109-dmarc-00 thanks tim (for Alexey/Seth) --000000000000ede7b205b47bcff7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A= ll

I've u= ploaded the minutes into the datatracker.=C2=A0 Please take a look to make = sure I captured everyone's comments correctly, and let us know updates.= =C2=A0
https://datatracker.ietf.org/meeting/109/materials/minutes-109-dmarc-00<= /a>
<= br>
thank= s

tim
(for Alexey/Seth= )


<= /div> --000000000000ede7b205b47bcff7-- --000000000000ede7b405b47bcff9 Content-Type: text/markdown; charset="UTF-8"; name="DMARC-ietf109-minutes.md" Content-Disposition: attachment; filename="DMARC-ietf109-minutes.md" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_khpayyvj0 IyBETUFSQyAoRG9tYWluLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sIFJlcG9ydGluZywg YW5kIENvbmZvcm1hbmNlKSBXRwoKKiBEYXRlOiBXZWRuZXNkYXksIE5vdmVtYmVyIDE4LCAyMDIw CiogVGltZTogMDU6MDAtMDc6MDAgVVRDIChvciAxMjowMC0xNDowMCBVVEMrNykKKiBNZWV0ZWNo bzogaHR0cHM6Ly9tZWV0aW5ncy5jb25mLm1lZXRlY2hvLmNvbS9pZXRmMTA5Lz9ncm91cD1kbWFy YyZzaG9ydD0maXRlbT0xCgoKIyMjCiogSmFiYmVyOiBkbWFyY0BqYWJiZXIuaWV0Zi5vcmcKKiBO b3RlczogaHR0cHM6Ly9jb2RpbWQuaWV0Zi5vcmcvbm90ZXMtaWV0Zi0xMDktZG1hcmMKCgojIyMg Q2hhaXJzCiogU2V0aCBCbGFuayBzZXRoQHZhbGltYWlsLmNvbQoqIEFsZXhleSBNZWxuaWtvdiBh bGV4ZXkubWVsbmlrb3ZAaXNvZGUuY29tCiogVGltIFdpY2luc2tpIHRqdy5pZXRmQGdtYWlsLmNv bQoKIyMjIERvY3VtZW50czoKIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtZG1hcmMtZG1hcmNiaXMvP2luY2x1ZGVfdGV4dD0xCiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtYXJjLWFnZ3JlZ2F0ZS1yZXBvcnRpbmcvP2luY2x1 ZGVfdGV4dD0xCiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRt YXJjLWZhaWx1cmUtcmVwb3J0aW5nLz9pbmNsdWRlX3RleHQ9MQogCiMjIE1JTlVURVMKCiogU2hv dWxkIHdlIGRlcHJlY2F0ZSDigJxwY3TigJ0gdGFnPwoKCgpUb2RkIEhlcnI6IGdvb2dsZSBncm91 cHMgcmVxdWlyZWQgcD1xdWFyYW50aW5lO3BjdD0wIHRvIGdldCByZXBvcnRzIGluIHRoZSBwYXN0 LiAKCkF1dHVtbiBUeXItU2FsdmlhOiBwPXF1YXJhbnRpbmUgbWFpbGluZyBsaXN0IG11bmdpbmcg aGFwcGVucyBidXQgbm90IHA9bm9uZS4gTGFyZ2UgY3VzdG9tZXJzIHZlcnkgcmlzayBhdmVyc2Ug d2l0aG91dCBwY3Q9MC4KCkFsZXhleTogQ291bGQgYmUgYWRkcmVzc2VkIHdpdGggbW9yZSB0ZXh0 PwoKQXV0dW1uOiBZZXMuIAoKQWx3aW4gZGUgQnJ1aW46IFByYWN0aWNhbCBjYXNlcyBtb3Zpbmcg ZnJvbSBxdWFyYW50aW5lIHRvIHJlamVjdAoKSmltIEZlbnRvbjogZGVwcmVjYXRlIG1heSBub3Qg YmUgdGhlIHJpZ2h0IHRlcm0gaGVyZS4gIENvdWxkIGp1c3QgbGVhdmUgb3V0LgoKQWxleGV5OiBX aWxsIHN0aWxsIGV4cGxhaW4gcmVhc29uaW5nLiAKCkppbTogIEF1dHVtbiBpbiB0aGUgY2hhdCBw PW5vbmUgcmVwb3J0cyB3L291dCBoZWFkZXIgbXVuZ2luZy4gCgoKKiBBZ2dyZWdhdGUgcmVwb3J0 aW5nCgoKKiBFeHRlbnNpYmxlIHJlcG9ydGluZwoKV2hhdCBraW5kIG9mIGV4dGVuc2lvbnMgc2hv dWxkIGJlIGFsbG93ZWQ/CldoYXTigJlzIG5lZWRlZCBmb3IgZnV0dXJlIGF1dGhlbnRpY2F0aW9u IG1lY2hhbmlzbXMgdG8gYmUgZm9sZGVkIGludG8gRE1BUkM/CglFeHRlbmRpbmcgcmVwb3J0cyBm b3IgYXJiaXRyYXJ5IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgdG8gYmUgcmVwb3J0ZWQgbWFr ZXMgaXQgZWFzeSB0byBjb2xsZWN0IGRhdGEgYW5kIHJ1biBleHBlcmltZW50cyB3aXRob3V0IG1v ZGlmeWluZyB0aGUgc3BlYwoKQXV0dW1uOiBnbWFpbCBpbmNsdWRpbmcgZGtpbSBzZWxlY3RlcnMg aW4gYWdncmVnYXRlIHJlcG9ydHMsIGJ1dCBub3QgY29tbW9uLiBXb3VsZCBsb3ZlIHRvIHNlZSBt b3JlLiAKVmVyeSB1c2VmdWwgZm9yIHRyYWNraW5nIGRvd24gdXNhZ2UgaW4gbGFyZ2Ugb3Jncy4g CgpNdXJyYXkgS3VjaGVyYXd5OiA4NjAxIGFkZCBoZWFkZXIgcyBtb3N0IGNvbW1vbiB1c2UgY2Fz ZS4KClRvZGQ6IFRpY2tldCA1NyBvbiBtYWtpbmcgZGtpbSBzZWxlY3RvcnMgcmVxdWlyZWQuIAoK Sm9obiBMZXZpbmU6IGFkZCB0aGVtIGludG8gdGhlIHJlcG9ydGluZyBYTUwsIGFkdmljZSBvbiBp Z25vcmluZyBkdXJpbmcgcGFyc2luZy4gCgoKKiBBUkMgUmVwb3J0aW5nCgoKKiBOWERPTUFJTiBy ZXBvcnRpbmcKCkpvaG46IEJvdGggc2VlbSByZWFzb25hYmxlLCBzdWdnZXN0IGZvbGtzIHNlbmQg c3VnZ2VzdGVkIFhNTCAKCgoqIEZhaWx1cmUgcmVwb3J0aW5nCgpNdXJyYXk6IElzIHF1ZXN0aW9u IHdoYXQgbXVzdCBiZSBpbmNsdWRlZCBvciBtaWdodCBiZSBpbmNsdWRlZCBvciBzb21lIG1peD8K CkFsZXhleTogQm90aCAtIHJlYXNvbnMgdG8gaW5jbHVkZSBvciBub3QgaW5jbHVkZSBtb3JlLCBh bmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucy4gCgpUb2RkOiBKZXNzZSBAIFdpc2NvbnNpbiBzdHJh d21hbiBmYWlsdXJlIHJlcG9ydGluZyB0byBmaW5kIHByb2JsZW1zLiAKCkF1dHVtbjogU29tZSBw aWVjZXMgd2UgYXJlIGxlc3MgaW4gbmVlZCBvZi4gZG9uJ3QgbmVlZCBmdWxsIGRraW0gaGVhZGVy OyBkb24ndCBuZWVkIGZ1bGwgZGF0ZS90aW1lIHN0YW1wOwpkbyB1c2UgRnJvbSBhZGRyZXNzZXMu IE1lc3NhZ2UtSWQgaGVscGZ1bCBhdCB0aW1lcy4gd2hhdCBzcGVjaWZpYyBmaWVsZHMgcGVvcGxl IG9iamVjdGluZyB0bz8gCgoKTWljaGFlbCBIYW1tZXI6IGZhaWx1cmUgcmVwb3J0cyB1c2VmdWwg aW4gZ2V0dGluZyByaWQgb2YgdGhlIGJhZGRuZXNzLCBub3QganVzdCBhcmJpdHJhcnkgZmFpbHVy ZXMuCgpKb2huOiBOb3Qgc3VyZSBvZiBwcm9ibGVtIHNvbHZpbmcgaXRzZWxmLiBNb3N0IHdvbid0 IHNlbmQgZmFpbHVyZSByZXBvcnRzLCBvdGhlcnMgd2lsbCByZWRhY3QgZm9yIGxlZ2FsIHJlYXNv bnMuCgpBbGV4ZXk6IFNob3VsZCBoYXZlIHRleHQgb24gd2hhdCBzaG91bGQgYmUgaW5jbHVkZWQg Zm9yIHVzZWZ1bCBmYWlsdXJlIHJlcG9ydC4KCkpvaG46IFRhbGtpbmcgdG8gbGF3eWVycyBoZXJl IGFib3V0IGZhaWx1cmUgcmVwb3J0cy4gUGVvcGxlIHdpbGwgcmVwb3J0IHdoYXQgdGhleSByZXBv cnQuIAoKCiogQnJlYWsgb3V0IGRlZmluaXRpb24gb2Ygb3JnIGRvbWFpbiB0byBhIGRpZmZlcmVu dCBkb2N1bWVudD8KCkRhdmUgQ3JvY2tlcjogTWVzc3ksIHVucGxlYXNhbnQgdG9waWMgbWFraW5n IGRvIHdpdGggc29sdXRpb24uICBEaWZmZXJlbnQgc29sdXRpb25zLCBvbmUgbWF5IHdvcmsuIApI YXZpbmcgdGhlIHNwZWMgc3RhdGUgd2hhdCBpdCB3YW50cyBhcyBhIHJlc3VsdCBkb2VzIG1ha2Ug c2Vuc2UuIEhvdyBpdCBnZXRzIHRoZSBpbmZvIGlzIGEgcHJvYmxlbS4gClN1Z2dlc3RlZCB0ZXh0 IHdhcyBjbGVhbiBhbmQgc2ltcGxlIGJ5IHdob20/ICAoTXVycmF5IGh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9tc2cvZG1hcmMvWncwS2p5ck5mSE1RNVM4VHBvQlJOdm5mVlJjLykK CkpvaG46IEFsbW9zdCBhZ3JlZSB3aXRoIERhdmUhIHdoZW4gd2Ugc3BsaXQgb3V0IGludG8gYW5v dGhlciBkb2N1bWVudCwgZGlmZmVyZW50IHJlc3VsdC4gCgpNdXJyYXk6ICBQcm9kdWNlIGFuIG9y ZyBkb21haW4gZG9jdW1lbnQgZnJvbSA3NDg5IGludG8gbmV3IGRvY3VtZW50LiBDYW4gYWxzbyBh ZGQgdHJlZSB3YWxrIGludG8gc2FtZQpkb2N1bWVudCBvciBhIG5ldyBkb2N1bWVudC4gCgpLdXJ0 IEFuZGVyc2VuOiB0YWxrIHBvbGljeSBkaXNjb3ZlcnkgZmlyc3QsIGJlZm9yZSBvcmcgZG9tYWlu IGlzIG5lZWRlZC4gIE9uIHRoZSBmZW5jZSBvbiBhIHNlcGFyYXRlIGRvY3VtZW50LgoKKiBQb2xp Y3kgRGlzY292ZXIgLSBUcmVlIFdhbGshCgpBdXR1bW46IFNlZW4gaW4gaGlnaGVyIGVkLiAgZXhh bXBsZSBvZiBncmFkLnVuaXYuZWR1IGFuZCBtdWx0aXBsZSBzdWIgZG9tYWlucy4gdW5pdi5lZHUg d2FzIG5vdCBpbnRlcmVzdGVkIGluIGRvaW5nIGRtYXJjLgphbHNvIHNlZW4gaW4gZ292ZXJubWVu dHMuICBvbmUgb3IgdHdvIGxldmVscyB3b3VsZCBiZSB1c2VmdWwuIAoKSm9objogQXNrZWQgRE5T T1AsIHdhc24ndCBjb25jZXJuZWQuICBDQUEgc3BlY2lmaWVzIGEgdHJlZSB3YWxrLCBhbmQgQ0Fz IGRvIHRoaXMuIDUgbGV2ZWxzLCB1c2UgdGhlIHJlc29sdmVyIGNhY2hlIHRvIGNhdGNoIE5YRE9N QUlOcy4gCgpKaW06IERpc2N1c3NlZCB0cmVlIHdhbGsgd2l0aCBBRFNQLCB3YXMgdmVyeSB0b3hp YyBhdCB0aGUgdGltZS4gCgpXZXMgSGFyZGFrZXI6IENBQSB3YXMgdXNlZCBhcyBhbiBleGFtcGxl IGJ1dCBDQUEgcXVlcmllcyBtdWNoIGRpZmZlcmVudCB0aGFuIG1haWwgc2VydmVyLiAgClRoZSBs YXR0ZXIgY2FuIHByb2R1Y2UgbW9yZSB0cmFmZmljLiBQcm92aWRlIGd1aWRhbmNlIHNvbWUgcmVm ZXJlbmNlIHRvIGFub3RoZXIgZG1hcmMgcmVjb3JkLiAKCkFsZXhleTogIFdpbGwgdGFrZSBkaXNj dXNzaW9ucyB0byBtYWlsaW5nIGxpc3QuIAo= --000000000000ede7b405b47bcff9-- From nobody Thu Nov 19 14:15:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95C53A12DB for ; Thu, 19 Nov 2020 14:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLeRAvJjAaK7 for ; Thu, 19 Nov 2020 14:15:53 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942893A16B1 for ; Thu, 19 Nov 2020 14:14:55 -0800 (PST) X-ASG-Debug-ID: 1605824093-11fa313c01105a0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 1hFkxxRTEXPQvu0Z (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 19 Nov 2020 17:14:54 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=dJk9p0oFB58aMoJ4xHA1+ZXqgnUmCtHDoduXr2D33xw=; b=oVErTSPPeC9CO6fxu/MmwIu34fKcM2VF6z6oLEb/P2zL4upo1jQ/+ZIWYVvASknkP PDU7R9RioA5L1kHjl2dX+7o0lbOcOgBrXQA3jFlmh2V9+Bjzr+HLXnmWCncqJgCDW eB9Bd+ptwEgcgirO2uA2ED2q6BYbodn5AKcxs3g5A= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Thu, 19 Nov 2020 17:14:46 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF DMARC WG'" Date: Thu, 19 Nov 2020 17:14:47 -0500 X-ASG-Orig-Subj: How does PSD for DMARC affect tree walk issue? Message-ID: <004001d6bec1$6434b630$2c9e2290$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01D6BE97.7B5EFC50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ada+wJ8JEdWRIYCGSgGnxkHfsy/YOA== Content-Language: en-us X-Exim-Id: 004001d6bec1$6434b630$2c9e2290$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605824093 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 2623 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85989 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [dmarc-ietf] How does PSD for DMARC affect tree walk issue? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Nov 2020 22:15:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01D6BE97.7B5EFC50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PSD for DMARC specifies moving up one additional layer of the DNS tree to look for the PSD policy, but it has the effect of adding DMARC policies to all levels of participating public suffixes. How do we judge whether this workload will be acceptable or not if widely implemented? I ask because it seems to be moving us closer to the performance implications of a scope-limited tree walk. Doug Foster ------=_NextPart_000_0041_01D6BE97.7B5EFC50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PSD for = DMARC specifies moving up one additional layer of the DNS tree to look = for the PSD policy, but it has the effect of adding DMARC policies to = all levels of participating public suffixes.    How do we = judge whether this workload will be acceptable or not if widely = implemented?

 

I ask because it seems to be moving us closer to the = performance implications of a scope-limited tree walk.

 

Doug = Foster

 

------=_NextPart_000_0041_01D6BE97.7B5EFC50-- From nobody Thu Nov 19 14:30:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642333A12FF; Thu, 19 Nov 2020 14:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail.mil Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGr2rsk_mXTe; Thu, 19 Nov 2020 14:30:50 -0800 (PST) Received: from UPDC19PA21.eemsg.mail.mil (UPDC19PA21.eemsg.mail.mil [214.24.27.196]) (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 448623A12FB; Thu, 19 Nov 2020 14:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1605825050; x=1637361050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C+4icvjLwA1AjFI7nK7tPwBGLx6ZmueWqkJR+C0w3ug=; b=MBK9pElIt4ybkgjShY+d4BxF7K46LgJFgMy1oFt1CmcWeLL9Cr4OpV1B J4324TFkNM2588CUvhgZyOeDmKbZD1Qu2bXWehOtJ/MXiJVPTiNCjVASy YoSjrdFI2cueVhmrnaobUp1PEf8aaGswR0hhQ9OqaRtSx3QJ86DdgdhYm 8QDUyOh7p/+D58CfazHD4b1faVzDmxth9sBuSDYMSAmJjauanmZHisUFU K+kx8MyZ80kFw+HT1t4Lu4tpVmC5MVzIO2XdJeGRHAqeusPg9zLF3e55U YM3QedIGLHvlWYA8qBhEb80HvsfhQKvDcZtzH0AaGQWPVNYdFnXLGebG3 Q==; X-EEMSG-check-017: 148802809|UPDC19PA21_ESA_OUT03.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.78,354,1599523200"; d="scan'208";a="148802809" Received: from edge-mech02.mail.mil ([214.21.130.230]) by UPDC19PA21.eemsg.mail.mil with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Nov 2020 22:30:42 +0000 Received: from UMECHPAOX.easf.csd.disa.mil (214.21.130.167) by edge-mech02.mail.mil (214.21.130.230) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 19 Nov 2020 22:30:18 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.6.95]) by umechpaox.easf.csd.disa.mil ([214.21.130.167]) with mapi id 14.03.0487.000; Thu, 19 Nov 2020 22:30:18 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: 'Doug Foster' , 'IETF DMARC WG' CC: "'dmarc-chairs@ietf.org'" Thread-Topic: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thread-Index: AQHWvPCMpiMZLl3tlkunzDAVmodKO6nQB+MA Date: Thu, 19 Nov 2020 22:30:17 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> References: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> In-Reply-To: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.44.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Nov 2020 22:30:52 -0000 U2VjdGlvbiAyLjcuIGRlZmluZXMgYSBub24tZXhpc3RlbnQgZG9tYWluIGFzICJhIGRvbWFpbiBm b3Igd2hpY2ggdGhlcmUgaXMgYW4gTlhET01BSU4gb3IgTk9EQVRBIHJlc3BvbnNlIGZvciBBLCBB QUFBLCBhbmQgTVggcmVjb3Jkcy4gIFRoaXMgaXMgYSBicm9hZGVyIGRlZmluaXRpb24gdGhhbiB0 aGF0IGluIE5YRE9NQUlOIFtSRkM4MDIwXS4iIFRoaXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQgZm9y IGRldGVybWluaW5nIHRoYXQgdGhlIGRvbWFpbiBpcyBub3QgaW50ZW5kZWQgdG8gYmUgdXNlZCBh bmQgdGhlcmVmb3JlIGNvdWxkIGhhdmUgYSBtb3JlIHN0cmluZ2VudCBwb2xpY3kgYXBwbGllZC4g IA0KDQpUaGUgaWRlYSBvZiBsb29raW5nIGZvciBhICJtYWlsLWVuYWJsZWQgZG9tYWluIiBiYXNl ZCBvbiBpZiBhbiAiTVggcmVjb3JkIGV4aXN0cyBvciBTUEYgcG9saWN5IGV4aXN0cyIgaXMgaW50 ZXJlc3RpbmcuIEFsdGhvdWdoIHRoZXJlIG1heSBiZSBkb21haW5zIHRoYXQgc2VuZCBlbWFpbCBi dXQgbm90IHJlY2VpdmUgZW1haWwgYW5kIHNvIG1heSBub3QgaGF2ZSBhbiBNWCByZWNvcmQuIEFs c28sIGV2ZW4gaWYgdGhlcmUgaXMgbm8gU1BGIHJlY29yZCwgdGhlIGRvbWFpbiBtYXkgc3RpbGwg c2VuZCBlbWFpbCwgYnV0IHRoZW4gaXQgbWlnaHQgYmUgaGVsZCB0byBhIG1vcmUgc3RyaW5nZW50 IERNQVJDIHBvbGljeSB0aGF0IHdvdWxkIGZ1cnRoZXIgcGVuYWxpemUgaXQgZm9yIG5vdCBoYXZp bmcgYW4gU1BGIHJlY29yZC4gDQoNCkFsc28sIGZvciB0aGUgcmV2aXNpb24gb2YgdGhlIGRvY3Vt ZW50IEkgbGlrZSB0aGUgd2F5IHRoYXQgdGhlIHRocmVlIHBhcnRzIG9mIHRoZSBleHBlcmltZW50 IGFyZSBub3cgbGFpZCBvdXQgbW9yZSBjbGVhcmx5LiAgTXkgb25seSBjb21tZW50IGlzIHRoYXQg dGhlIHRpdGxlIG9mIEFwcGVuZGl4IEEgaXMgb3Zlcmx5IHNwZWNpZmljIHRvIGp1c3Qgb25lIG9m IHRoZSBleHBlcmltZW50cyBhbmQgc28gc2hvdWxkIGJlIGJyb2FkZXIuDQoNClRoYW5rcywNCg0K RXJpYyBDaHVkb3cNCkRvRCBDeWJlcnNlY3VyaXR5IE1pdGlnYXRpb25zDQoNCkZyb206IERvdWcg Rm9zdGVyIDxmb3N0ZXJkQGJheXZpZXdwaHlzaWNpYW5zLmNvbT4gDQpTZW50OiBUdWVzZGF5LCBO b3ZlbWJlciAxNywgMjAyMCA5OjQ2IEFNDQpUbzogJ0lFVEYgRE1BUkMgV0cnIDxkbWFyY0BpZXRm Lm9yZz4NCkNjOiBkbWFyYy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0 Zl0gU2Vjb25kIFdHTEMgZm9yIGRyYWZ0LWlldGYtZG1hcmMtcHNkOiBEZWZpbml0aW9uIG9mIE5Q DQoNCkkgZGlkIG5vdCBzZWUgYSBkZWZpbml0aW9uIG9mIGEg4oCcbm9uLWV4aXN0ZW50IGRvbWFp buKAnSAodGhlIG5wIHBvbGljeSkuIMKgwqBBIGRlZmluaXRpb24gaXMgbmVlZGVkLg0KDQpUbyBt eSB0aGlua2luZywgdGhlIG9idmlvdXMgcnVsZSBzaG91bGQgYmUgdG8gcXVlcnkgZm9yIGEgTlMg cmVjb3JkIGZvciB0aGUgZG9tYWluLiDCoElmIHRoZSByZWNvcmQgZXhpc3RzLCB0aGVuIHRoZSBk b21haW4gb3duZXIgY291bGQgY3JlYXRlIGEgRE1BUkMgcmVjb3JkIGZvciB0aGF0IGRvbWFpbiwg b3IgY291bGQgY3JlYXRlIGEgZGVmYXVsdCBlbnRyeSBmb3IgdGhlIGRvbWFpbiBhdCB0aGUgb3Jn YW5pemF0aW9uYWwgbGV2ZWwuwqAgSWYgbm8gcmVjb3JkIGV4aXN0cywgaXQgaXMgYmVjYXVzZSB0 aGUgZG9tYWluIG93bmVyIGNob3NlIHRvIG5vdCBjcmVhdGUgb25lLg0KDQpIb3dldmVyLCB0aGUg RE1BUkMgQmlzIGRvY3VtZW50IGNvbmZsaWN0cyBzdHJvbmdseSB3aXRoIHRoaXMuwqAgSW4gc2Vj dGlvbiBBLjQsIGl0IHN1Z2dlc3Qgc2V2ZXJhbCB3YXlzIHRvIGRvIGEgdGVzdCBvZiB0aGlzIHR5 cGUsIHRoZW4gcmVwdWRpYXRlcyBhbGwgb2YgdGhlbS7CoCBOUyBsb29rdXAgaXMgbm90IG9uZSBv ZiB0aGUgbWVudGlvbmVkIG9wdGlvbnMuDQoNClRoZXJlIGlzIGEgcG9zc2libGUgc2Vjb25kLWxl dmVsIHBvbGljeSB0ZXN0IGZvciBhIOKAnG1haWwtZW5hYmxlZCBkb21haW7igJ0uwqAgSSB3b3Vs ZCBkZWZpbmUgdGhhdCB0ZXN0IGFzIOKAnE1YIHJlY29yZCBleGlzdHMgb3IgU1BGIHBvbGljeSBl eGlzdHPigJ0uIMKgwqDCoFRoYXQgY291bGQgYmUgYW4gYWRkaXRpb25hbCBvcHRpb24gdG8gTlAs IGJ1dCBzaG91bGQgbm90IGJlIGEgcmVwbGFjZW1lbnQgZm9yIGl0Lg0KDQpQU0QgZm9yIERNQVJD IGNsZWFybHkgaW50ZW5kcyBmb3IgdGhlIE5QIHBvbGljeSB0byBiZSBhIGdlbmVyYWwgc29sdXRp b24gdG8gYSBnZW5lcmFsIHByb2JsZW0uwqDCoMKgIElmIHRoZXJlIGFyZSBzdGlsbCBvYmplY3Rp b25zIHRvIGl0IGJlY29taW5nIGEgZ2VuZXJhbCBzb2x1dGlvbiwgdGhpcyBzaG91bGQgYmUgYWRk cmVzc2VkIHNvb24uDQoNCkRvdWcgRm9zdGVyDQoNCg0KRnJvbTogZG1hcmMgW21haWx0bzpkbWFy Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGltIFdpY2luc2tpDQpTZW50OiBGcmlk YXksIE5vdmVtYmVyIDEzLCAyMDIwIDE6NDIgUE0NClRvOiBJRVRGIERNQVJDIFdHDQpDYzogZG1h cmMtY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBbZG1hcmMtaWV0Zl0gU2Vjb25kIFdHTEMgZm9y IGRyYWZ0LWlldGYtZG1hcmMtcHNkDQoNCg0KQWxsDQoNCkR1cmluZyB0aGUgSUVTRyByZXZpZXdz IG9mIGRyYWZ0LWlldGYtZG1hcmMtcHNkLCB0aGVyZSB3ZXJlIHNldmVyYWwgaXNzdWVzIHJhaXNl ZCB3aXRoIHNvbWUgb2YgdGhlIGRvY3VtZW50LiDCoCBNb3N0IG9mIHRoZW0gYXJlIGVkaXRvcmlh bCBidXQgdGhlIG9uZSBiaWcgaXRlbSB3YXMgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBFeHBlcmlt ZW50LiDCoCBUaGUgY2hhaXJzIHNhdCBkb3duIGFuZCBicm9rZSBvdXQgdGhlIGV4cGVyaW1lbnQg c2VjdGlvbiBpbnRvIHRocmVlIHNlcGFyYXRlIGV4cGVyaW1lbnRzLCBhbmQgaW5jbHVkZWQgbGFu Z3VhZ2Ugb24gaG93IHRvIGNhcHR1cmUgdGhlIGRhdGEgdG8gY29uZmlybSBob3cgdGhlIGV4cGVy aW1lbnQgd29ya2VkLsKgIA0KDQpJdCdzIGVub3VnaCBvZiBhIGNoYW5nZSB0aGF0IHdlIHdhbnRl ZCB0byBkbyBhIHNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCB0byBtYWtlIHN1cmUgdGhl IHdvcmtpbmcgZ3JvdXAgYWdyZWVzIHdpdGggb3VyIGNoYW5nZXMuIFRoZSBkaWZmIG9mIHRoZSBj dXJyZW50IHZlcnNpb24gd2l0aCB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBoZXJlOsKgDQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWRtYXJjLXBzZC0wOCZ1 cmwyPWRyYWZ0LWlldGYtZG1hcmMtcHNkLTA5DQoNClRoaXMgc3RhcnRzIGEgKm9uZSogd2VlayBz ZWNvbmQgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9ywqAgZHJhZnQtaWV0Zi1kbWFyYy1wc2QN ClBsZWFzZSByZXZpZXcgdGhlIGNoYW5nZXMgYW5kIG9mZmVyIHVwIGNvbW1lbnRzIHRvIHRoZSB3 b3JraW5nIGdyb3VwLg0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIDIwIE5vdmVtYmVy IDIwMjANCg0KVGhhbmtzLA0KDQo= From nobody Thu Nov 19 14:35:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BE23A131E for ; Thu, 19 Nov 2020 14:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail.mil Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIccNJ-qGVxP for ; Thu, 19 Nov 2020 14:35:38 -0800 (PST) Received: from UPDC19PA19.eemsg.mail.mil (UPDC19PA19.eemsg.mail.mil [214.24.27.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5382A3A0D73 for ; Thu, 19 Nov 2020 14:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1605825338; x=1637361338; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lTfGSJzwOxrSleDQeZIiN1vFAE4vR8ML7Gw8qf0cAME=; b=AsGM9U6Y7tYOXOUZSyYY0szWSZXppAvskvTDE/RtyDF9QwV7RjtYxaHh wO4Xn5nEglDThAPnzj0KjG8PKPgKKsFUosEFiwvPYXIeamdgH7p3roSFu 8kZmtJZLi7JKWQMPVweqmP6hk/Nt8Cal0jLjzVaxofPtg/UkL2cdTOuf7 S/wI00Rs6QokQ1JkMCwEcTdVQNr+aSu6srKLS7fINmO7LGP2uQS5dv7OM VO9qtpP2koOZq1a3UTs6flxQfUR9fDBlR4SO47iRyvzuG0H71+iuPOJLx BuROLjPgYwLaggC0LW1ByTdqx/3+idze/NqMmiELNes7idQf2LxxQ34pM A==; X-EEMSG-check-017: 146852373|UPDC19PA19_ESA_OUT01.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.78,354,1599523200"; d="scan'208";a="146852373" Received: from edge-mech02.mail.mil ([214.21.130.229]) by UPDC19PA19.eemsg.mail.mil with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Nov 2020 22:35:35 +0000 Received: from UMECHPAOY.easf.csd.disa.mil (214.21.130.168) by edge-mech02.mail.mil (214.21.130.229) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 19 Nov 2020 22:34:30 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.6.95]) by umechpaoy.easf.csd.disa.mil ([214.21.130.168]) with mapi id 14.03.0487.000; Thu, 19 Nov 2020 22:34:30 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: 'Doug Foster' , 'IETF DMARC WG' Thread-Topic: [dmarc-ietf] How does PSD for DMARC affect tree walk issue? Thread-Index: AQHWvsGkAWTmp4RaHEW5GvreMBRMcKnQCeEw Date: Thu, 19 Nov 2020 22:34:30 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC031281164A4@UMECHPA7D.easf.csd.disa.mil> References: <004001d6bec1$6434b630$2c9e2290$@bayviewphysicians.com> In-Reply-To: <004001d6bec1$6434b630$2c9e2290$@bayviewphysicians.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.44.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] How does PSD for DMARC affect tree walk issue? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 19 Nov 2020 22:35:40 -0000 For domains and organizational domains that have DMARC policies, then there= is no difference. For ones that don't, there is only one extra check and = I think that often it will be cached to minimize the actual lookups needed = in practice. Thanks, Eric Chudow DoD Cybersecurity Mitigations From: Doug Foster =20 Sent: Thursday, November 19, 2020 5:15 PM To: 'IETF DMARC WG' Subject: [dmarc-ietf] How does PSD for DMARC affect tree walk issue? PSD for DMARC specifies moving up one additional layer of the DNS tree to l= ook for the PSD policy, but it has the effect of adding DMARC policies to a= ll levels of participating public suffixes.=A0=A0=A0 How do we judge whethe= r this workload will be acceptable or not if widely implemented? I ask because it seems to be moving us closer to the performance implicatio= ns of a scope-limited tree walk. Doug Foster From nobody Thu Nov 19 14:55:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947E13A133E for ; Thu, 19 Nov 2020 14:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7GUnCBN3f5z for ; Thu, 19 Nov 2020 14:55:37 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 8253D3A133D for ; Thu, 19 Nov 2020 14:55:37 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id 11so7221635qkd.5 for ; Thu, 19 Nov 2020 14:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=X/nD672DTsXHiR4lKYZ8WlneakJKWHSglSxwB59rP8o=; b=cZJcJHii8lundcgUyE3CBoCZBmVv2iIksTS/Ueg4L4VG4OBBI0jZC301BqTfuDvafX bPaD9hsFhQvzIldSeCrz4AYDfQlROLQdDtEcknD7ksd965h5I9E8ALwf5JM98+4Cmvek bNQDRWq0bjgdVJgtGBVv6BmzYeH6tr8eUzk0twiyPk/V+1t/rv1lX6dkmK0U5KcTJbTb hahkIXyaDRCLzXlZQYoSvuKks5IQJzcsuAhCPuyeSlKHLi+y43KIFzjpkQoQ2OwPH6i1 M+sCAhqno6fysMkbVFGMThLXThus6T6T/3X6lamj/20qdrTDjyqS22tvye4ctjRKm9Ne tCwg== 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=X/nD672DTsXHiR4lKYZ8WlneakJKWHSglSxwB59rP8o=; b=jsB6yeXbCscGGwhEoomA19BS5FYv4yX9Kos5LuRy6Qvd/bCzl8FLlAKtd6WGOwbIm+ AyLi2USrU0vI397lXp3liD09MruVWIsBndm8boJGaJC9yyQ4JWptfQNMuCBkNArI8JvA rahrLsdj83LuJRN0Xl/qNJ3hJ9tVaqzYm985fCXJvuhWwS8VMSmULDdK9kIg+D2s5Db0 bUSsLXnWjvYI+tW3RIthOXe8bIvlRdJcbWGpnN97UVOHc6nHW1H89YBBK+hgN13nwFAF wkyk7rEn/apiTRxd37OZR5v2zzzkF1u9N2N14/5RmvEI7Qv5Fs6FzK/IwxX4YFxLJ9pY F7OQ== X-Gm-Message-State: AOAM5337XTpBqhTCZuISfPutis/iMg1azgfF1Chai9pVatQBp5xmOEPX XT2Gr23zMWnPixMyKKp0SSH6jc+aaj0aohCnsGrAWQxDidn20w== X-Google-Smtp-Source: ABdhPJxx2ZvfFK1gQSSY7z76PEKm4hhvcCNqI5xvqUWpv3IiqxSEfl303fqg2Ujau9CvrwdQFNKOgdeIfqLAPgPfGqc= X-Received: by 2002:a37:e20d:: with SMTP id g13mr13263828qki.325.1605826536225; Thu, 19 Nov 2020 14:55:36 -0800 (PST) MIME-Version: 1.0 References: <160513169495.16356.6565556939968267867@ietfa.amsl.com> In-Reply-To: From: Todd Herr Date: Thu, 19 Nov 2020 17:55:20 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000043561a05b47da02e" Archived-At: Subject: Re: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.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: Thu, 19 Nov 2020 22:55:42 -0000 --00000000000043561a05b47da02e Content-Type: text/plain; charset="UTF-8" This thread hasn't generated any discussion or momentum yet, and I know that's not because y'all have found the proposed text for the Abstract and Introduction to be acceptable, so I'm going to add the text to this thread and see where the discussion leads. ----------------------------------------------- cut here ---------------------------------------------------- Abstract This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting. Mail-receiving organizations can in turn use these expressions of policies and preferences to inform their mail handling decisions should they choose to do so. This document obsoletes RFC 7489. [...] 1. Introduction RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: The source for this draft is maintained in GitHub at: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis) The Sender Policy Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-level authentication, and DMARC builds on these protocols. DMARC is designed to give ADminstrative Management Domains (ADMDs) that originate email the ability to publish in a DNS TXT record their email authentication policies, specify preferred handling for mail that fails authentication checks, and request reports about mail purportedly originated by the ADMD, as determined by the RFC5322.From header in the message. As with SPF and DKIM, DMARC authentication checks result in verdicts of "pass" or "fail". A DMARC pass verdict requires not only that SPF or DKIM pass for the message in question, but also that the domain validated by the SPF or DKIM check is aligned with the domain in the RFC5322.From header. In the DMARC protocol, two domains are said to be "in alignment" if they have the same Organizational Domain (a.k.a., relaxed alignment) or they are identical (a.k.a., strict alignment). A DMARC pass verdict asserts only that the RFC5322.From domain has been authenticated in that message; there is no explicit or implied value assertion attributed to a message that receives such a verdict. A mail-receiving organization that performs DMARC validation checks on inbound mail can choose to use the results and the preferences expressed by the originating domain for message disposition to inform its mail handling decision for that message. For messages that pass DMARC validation checks, the mail-receiving organization can be confident in applying handling based on its known history for similarly authenticated messages, whereas messages that fail such checks cannot be reliably associated with a domain with a history of sending DMARC-validated messages. DMARC also describes a reporting framework in which mail-receiving domains can generate regular reports containing data about messages seen that claim to be from domains that publish DMARC policies, and send those reports to the ADMD as requested by its DMARC policy record. Experience with DMARC has revealed some issues of interoperability with email in general that require due consideration before deployment, particularly with configurations that can cause mail to be rejected. These are discussed in Section 9. ----------------------------------------------- cut here ---------------------------------------------------- On Fri, Nov 13, 2020 at 2:54 PM Todd Herr wrote: > Hi. > > I wanted to call everyone's attention to how draft-ietf-dmarc-dmarcbis-00 > differs from the existing RFC 7489. > > The key differences are as follows: > > - Section 7, DMARC Feedback, has been mostly removed except for a > paragraph that mentions that reporting will be discussed in a different > document (as per current plans) > - Section 9, Privacy Considerations, has been removed (under the > expectation that they'll be discussed in the reporting documents) > - Appendix C, DMARC XML Schema, has been removed (under the > expectation that it'll be discussed in the the reporting documents) > - Remaining target references to "verifying-external-destinations", > "failure-reports", and "aggregate-reports", which were anchors in the > removed sections mentioned above, have been replaced by hand-wavy language > referencing "The DMARC reporting document(s)" > - The Abstract and Introduction section have been rewritten as an > attempt to address issue #80 > - *DMARCbis Should Have a > Clear and Concise Definition of DMARC* > > Obviously the text applicable to the first four bullet points above will > evolve over time, and it may not yet be the right time in the process to > discuss those sections. However, the proposed new text for the Abstract and > Introduction is certainly worthy of discussion at this time, I believe. > > On Wed, Nov 11, 2020 at 4:55 PM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain-based Message Authentication, >> Reporting & Conformance WG of the IETF. >> >> Title : Domain-based Message Authentication, Reporting, >> and Conformance (DMARC) >> Authors : Emil Gustafsson >> Todd M. Herr >> John Levine >> Filename : draft-ietf-dmarc-dmarcbis-00.txt >> Pages : 55 >> Date : 2020-11-11 >> >> Abstract: >> This document describes the Domain-based Message Authentication, >> Reporting, and Conformance (DMARC) protocol. >> >> DMARC is a scalable mechanism by which a mail-originating >> organization can express domain-level policies and preferences for >> message validation, disposition, and reporting. Mail-receiving >> organizations can in turn use these expressions of policies and >> preferences to inform their mail handling decisions should they >> choose to do so. >> >> This document obsoletes RFC 7489. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-00.html >> >> >> 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/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > -- > > *Todd Herr* | Sr. Technical Program Manager > *e:* todd.herr@valimail.com > *p:* 703.220.4153 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000043561a05b47da02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This thread hasn't generated any discussion or momentu= m yet, and I know that's not because y'all have found the proposed = text for the Abstract and Introduction to be acceptable, so I'm going t= o add the text to this thread and see where the discussion leads.

<= /div>
----------------------------------------------- cut here --------= --------------------------------------------

Abstract


=C2=A0=C2=A0 This document describes the Domain-based M= essage Authentication,

=C2=A0=C2=A0 Reporting, and Conformance (DMARC) protoco= l.


=C2=A0=C2=A0 DMARC is a scalable mechanism by which a m= ail-originating

=C2=A0=C2=A0 organization can express domain-level poli= cies and preferences for

=C2=A0=C2=A0 message validation, disposition, and repor= ting.=C2=A0 Mail-receivi= ng

=C2=A0=C2=A0 organizations can in turn use these expres= sions of policies and

=C2=A0=C2=A0 preferences to inform their mail handling = decisions should they

=C2=A0=C2=A0 choose to do so.


=C2=A0=C2=A0 This document obsoletes RFC 7489.


[...]



1.=C2=A0 Introduction


=C2=A0=C2=A0 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BE= FORE PUBLISHING:

= =C2=A0=C2=A0 The source for this draft is maintained in GitHub at:

=C2=A0=C2=A0 ht= tps://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis

= =C2=A0=C2=A0 (https://github= .com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis)


=C2=A0= =C2=A0 The Sender Policy Framework ([RFC7208]) and DomainKeys Identi= fied

=C2=A0=C2=A0= Mail ([RFC6376]) protocols provide domain-level authentication, and=

=C2=A0=C2=A0 DMARC builds on these protocols.=C2=A0 DMARC is designed to give

=C2=A0=C2=A0 ADminstrative Management Do= mains (ADMDs) that originate email the

=C2=A0=C2=A0 ability to publish in a DNS TXT r= ecord their email authentication

=C2=A0=C2=A0 policies, specify preferred handling f= or mail that fails

=C2=A0=C2=A0 authentication checks, and request reports about mail= purportedly

=C2= =A0=C2=A0 originated by the ADMD, as determined by the RFC5322.From = header in

=C2=A0= =C2=A0 the message.


=C2=A0=C2=A0 As with SP= F and DKIM, DMARC authentication checks result in verdicts

=C2=A0=C2=A0 of "pass= " or "fail".=C2= =A0 A DMARC pass verdict requires not only that SPF

=C2=A0=C2=A0 or DKIM pass = for the message in question, but also that the domain

=C2=A0=C2=A0 validated by the S= PF or DKIM check is aligned with the domain in the

=C2=A0=C2=A0 RFC5322.From header= .=C2=A0 In the DMARC pro= tocol, two domains are said to

=C2=A0=C2=A0 be "in alignment" if they have = the same Organizational Domain

=C2=A0=C2=A0 (a.k.a., relaxed alignment) or they are i= dentical (a.k.a., strict

=C2=A0=C2=A0 alignment).


=C2=A0=C2=A0 A DMARC pass verdict asserts only that the RFC5322.From domain has

=C2=A0=C2=A0 be= en authenticated in that message; there is no explicit or implied

=C2=A0=C2=A0 value = assertion attributed to a message that receives such a verdict.

<= p class=3D"gmail-p1" style=3D"margin:0px;font:11px Menlo;color:rgb(0,0,0)">= =C2=A0=C2=A0 A mail-r= eceiving organization that performs DMARC validation checks

<= span class=3D"gmail-Apple-converted-space">=C2=A0=C2=A0 on inbound m= ail can choose to use the results and the preferences

=C2=A0=C2=A0 expressed by the o= riginating domain for message disposition to inform

=C2=A0=C2=A0 its mail handling d= ecision for that message.=C2=A0= For messages that pass

=C2=A0=C2=A0 DMARC validation checks, the mail-receivi= ng organization can be

=C2=A0=C2=A0 confident in applying handling based on its known= history for

=C2= =A0=C2=A0 similarly authenticated messages, whereas messages that fa= il such

=C2=A0=C2= =A0 checks cannot be reliably associated with a domain with a histor= y of

=C2=A0=C2=A0= sending DMARC-validated messages.


=C2=A0=C2=A0 DMARC also describes a reporting framework in which mail-receiving

=C2=A0=C2=A0 = domains can generate regular reports containing data about messages<= /p>

=C2=A0=C2=A0 seen= that claim to be from domains that publish DMARC policies, and

<= p class=3D"gmail-p1" style=3D"margin:0px;font:11px Menlo;color:rgb(0,0,0)">= =C2=A0=C2=A0 send tho= se reports to the ADMD as requested by its DMARC policy

=C2=A0=C2=A0 record.<= /p>


=C2=A0=C2=A0 Experience with DMARC has revealed some issu= es of interoperability

=C2=A0=C2=A0 with email in general that require due considerat= ion before

=C2=A0= =C2=A0 deployment, particularly with configurations that can cause m= ail to

=C2=A0 =C2=A0be rejected.=C2=A0 These are discussed in Section 9.



---------------------= -------------------------- cut here ---------------------------------------= -------------

On Fri, Nov 13, 2020 at 2:54 PM Todd Herr <todd.herr@valimail.com> wrote:=
Hi.

I wanted to call everyone's a= ttention to how draft-ietf-dmarc-dmarcbis-00 differs from the existing RFC = 7489.

The key differences are as follows:
  • Section 7, DMARC Feedback, has be= en mostly removed except for a paragraph that mentions that reporting will = be discussed in a different document (as per current plans)
  • Section 9, Privacy Considerations, has been removed (= under the expectation that they'll be discussed in the reporting docume= nts)
  • Appendix C, DMARC XML Schema, has b= een removed (under the expectation that it'll be discussed in the the r= eporting documents)
  • Remaining target ref= erences to "verifying-external-destinations", "failure-repor= ts", and "aggregate-reports", which were anchors in the remo= ved sections mentioned above, have been replaced by hand-wavy language refe= rencing "The DMARC reporting document(s)"
  • The Abstract and Introduction section have been rewritten as an= attempt to address=C2=A0issue #80=C2=A0- DMARCbis Should Have a Clear= and Concise Definition of DMARC
Obviously the text appli= cable to the first four bullet points above will evolve over time, and it m= ay not yet be the right time in the process to discuss those sections. Howe= ver, the proposed new text for the Abstract and Introduction is certainly w= orthy of discussion at this time, I believe.

On Wed, Nov 1= 1, 2020 at 4:55 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain-based Message Authentication, Repor= ting & Conformance WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Domain-based Message Authentication, Reporting, and Conformance (DMARC) =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Emil= Gustafsson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Todd M. Herr
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Levine
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dmarc-dmarcbis-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 55
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-11-11

Abstract:
=C2=A0 =C2=A0This document describes the Domain-based Message Authenticatio= n,
=C2=A0 =C2=A0Reporting, and Conformance (DMARC) protocol.

=C2=A0 =C2=A0DMARC is a scalable mechanism by which a mail-originating
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting.=C2=A0 Mail-rec= eiving
=C2=A0 =C2=A0organizations can in turn use these expressions of policies an= d
=C2=A0 =C2=A0preferences to inform their mail handling decisions should the= y
=C2=A0 =C2=A0choose to do so.

=C2=A0 =C2=A0This document obsoletes RFC 7489.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-dmarc-dmarcbis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/dra= ft-ietf-dmarc-dmarcbis-00.html


Please note that it may take a couple of minutes from the time of submissio= n
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/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--

Todd Herr= | Sr. Technical Program Manager
e: <= a href=3D"mailto:todd.herr@valimail.com" target=3D"_blank">todd.herr@valima= il.com
p: 703.2= 20.4153

=


This email and all data transmitted wit= h it contains confidential and/or proprietary information intended solely f= or the use of individual(s) authorized to receive it. If you are not an int= ended and authorized recipient you are hereby notified of any use, disclosu= re, copying or distribution of the information included in this transmissio= n is prohibited and may be unlawful. Please immediately notify the sender b= y replying to this email and then delete it from your system.=



--

Todd Herr | Sr. Technical P= rogram Manager
= p: 703.220.4153

<= br>

This email an= d all data transmitted with it contains confidential and/or proprietary inf= ormation intended solely for the use of individual(s) authorized to receive= it. If you are not an intended and authorized recipient you are hereby not= ified of any use, disclosure, copying or distribution of the information in= cluded in this transmission is prohibited and may be unlawful. Please immed= iately notify the sender by replying to this email and then delete it from = your system.

--00000000000043561a05b47da02e-- From nobody Thu Nov 19 18:27:34 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832ED3A1679 for ; Thu, 19 Nov 2020 18:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT5vob0CbY5l for ; Thu, 19 Nov 2020 18:27:30 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B5E3A167C for ; Thu, 19 Nov 2020 18:27:30 -0800 (PST) X-ASG-Debug-ID: 1605839245-11fa313c0113450001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id q5d48OnxZDsqDSWH (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 19 Nov 2020 21:27:25 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=78i89dc54iwYhiOHjHpxF2/6+bdSgrH3MGzOko9sF8g=; b=FGXPvqkU8xZ4odvSl1Db+nqYE2k29T285PnxRLabLGIgq7RO0qA+nY707Sl01ELpn 4zv5a46R+m0U/+xMrISPbO+ualgDUVtadyGUtAbkCpptdgrDOg2H2xTPlEeEfCdkS b4loNAZeimJzewz9hHV/Z2T1Eqj7aLUHwkUMcB5qE= From: "Douglas E. Foster" To: "IETF DMARC WG" Date: Thu, 19 Nov 2020 21:27:17 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=ce57cc3e7a9f4b23879edbfb95690d0d In-Reply-To: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> References: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> X-Exim-Id: b4bcc478ce3f4bac9f4b554909c03350 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605839245 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 18553 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85992 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 02:27:33 -0000 This is a multipart message in MIME format. --ce57cc3e7a9f4b23879edbfb95690d0d Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the pointer Eric. Can someone explain why the chosen algorithm, which requires testing multip= le conditions, is preferable to a single query for a name server record=3F = Minimizing DNS traffic has been part of our recent discussion, and minimi= zing software complexity is always a good thing. Can someone also explain why the DMARC appendix takes such a strong stance = against all queries for non-existent domains, regardless of technique=3F I= t seems like the philosophical incompatibilities need to be addressed befor= e both documents advance. DMARC is specified only as a test for the RFC5322.From domain. RFC5321.Ma= ilFrom domains may also be non-existent. They will return SPF NONE, but th= at is an ambiguous result, and SPF has no organization default mechanism. = - Is there data to indicate whether evaluators have found that checking the= RFC5321.MailFrom for non-existence is useful=3F - Suppose that the NP policy becomes generalized, and a domain has asserted= a "must-exist" DMARC policy. Should a non-existent subdomain used in the= RFC5321.MailFrom address be treated skeptically=3F I can imagine a scenario where a spammer uses a bogus subdomain of a legiti= mate organization, in an attempt to get whitelisted by spam filters which p= rimarily evaluate the RFC5321.MailFrom address. This attack could be pair= ed with an unrelated and non-DMARC RFC5322.From address which is newly mint= ed or otherwise not generally known to be suspicious, So my instinct is t= hat some extension of DMARC to the SMTP address will be beneficial. Doug Foster ---------------------------------------- From: "Chudow, Eric B CIV NSA DSAW (USA)" Sent: 11/19/20 5:31 PM To: 'Doug Foster' , 'IETF DMARC WG' Cc: "'dmarc-chairs@ietf.org'" Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP Section 2.7. defines a non-existent domain as "a domain for which there is = an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a broad= er definition than that in NXDOMAIN [RFC8020]." This should be sufficient f= or determining that the domain is not intended to be used and therefore cou= ld have a more stringent policy applied. The idea of looking for a "mail-enabled domain" based on if an "MX record e= xists or SPF policy exists" is interesting. Although there may be domains t= hat send email but not receive email and so may not have an MX record. Also= , even if there is no SPF record, the domain may still send email, but then= it might be held to a more stringent DMARC policy that would further penal= ize it for not having an SPF record. Also, for the revision of the document I like the way that the three parts = of the experiment are now laid out more clearly. My only comment is that th= e title of Appendix A is overly specific to just one of the experiments and= so should be broader. Thanks, Eric Chudow DoD Cybersecurity Mitigations From: Doug Foster Sent: Tuesday, November 17, 2020 9:46 AM To: 'IETF DMARC WG' Cc: dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP I did not see a definition of a "non-existent domain" (the np policy). A = definition is needed. To my thinking, the obvious rule should be to query for a NS record for the= domain. If the record exists, then the domain owner could create a DMARC = record for that domain, or could create a default entry for the domain at t= he organizational level. If no record exists, it is because the domain own= er chose to not create one. However, the DMARC Bis document conflicts strongly with this. In section A= .4, it suggest several ways to do a test of this type, then repudiates all = of them. NS lookup is not one of the mentioned options. There is a possible second-level policy test for a "mail-enabled domain". = I would define that test as "MX record exists or SPF policy exists". Tha= t could be an additional option to NP, but should not be a replacement for = it. PSD for DMARC clearly intends for the NP policy to be a general solution to= a general problem. If there are still objections to it becoming a gener= al solution, this should be addressed soon. Doug Foster From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski Sent: Friday, November 13, 2020 1:42 PM To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd All During the IESG reviews of draft-ietf-dmarc-psd, there were several issues = raised with some of the document. Most of them are editorial but the one = big item was the description of the Experiment. The chairs sat down and b= roke out the experiment section into three separate experiments, and includ= ed language on how to capture the data to confirm how the experiment worked= . It's enough of a change that we wanted to do a second working group last ca= ll to make sure the working group agrees with our changes. The diff of the = current version with the previous version is here: https://www.ietf.org/rfcdiff=3Furl1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-= ietf-dmarc-psd-09 This starts a *one* week second working group last call for draft-ietf-dma= rc-psd Please review the changes and offer up comments to the working group. This working group last call 20 November 2020 Thanks, --ce57cc3e7a9f4b23879edbfb95690d0d Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you for the pointer Eric.

Can someone explain why the chos= en algorithm, which requires testing multiple conditions, is preferable to = a single query for a name server record=3F   Minimizing DNS traffic ha= s been part of our recent discussion, and minimizing software complexity is= always a good thing.

=
Can som= eone also explain why the DMARC appendix takes such a strong stance against= all queries for non-existent domains, regardless of technique=3F  It = seems like the philosophical incompatibilities need to be addressed before = both documents advance.

DMARC= is specified only as a test for the RFC5322.From domain.   RFC5321.Ma= ilFrom domains may also be non-existent.  They will return SPF NONE, b= ut that is an ambiguous result, and SPF has no organization default mechani= sm.   
  • I= s there data to indicate whether evaluators have found that checking the RF= C5321.MailFrom for non-existence is useful=3F   
  • Suppose that the NP policy= becomes generalized, and a domain has asserted a "must-exist" DMARC policy= .   Should a non-existent subdomain used in the RFC5321.MailFrom addre= ss be treated skeptically=3F
I can imagine a scenario where a spammer uses a bo= gus subdomain of a legitimate organization, in an attempt to get whiteliste= d by spam filters which primarily evaluate the RFC5321.MailFrom address. &n= bsp; This attack could be paired with an unrelated and non-DMARC RFC5322.Fr= om address which is newly minted or otherwise not generally known to be sus= picious,   So my instinct is that some extension of DMARC to the SMTP = address will be beneficial.

D= oug Foster




From: "Chudow,= Eric B CIV NSA DSAW (USA)" <eric.b.chudow.civ@mail.mil>
Sent: 11= /19/20 5:31 PM
= To: 'Doug Foster' <fosterd@bayviewphysicians.com>, '= IETF DMARC WG' <dmarc@ietf.org>
Cc: "'dmarc-chairs@ietf.org'" <d= marc-chairs@ietf.org>
Subject: RE: [dmarc-ietf] Second WGLC for draft-= ietf-dmarc-psd: Definition of NP

Section 2.7. defines a non-existent domain as "a domain for whic= h there is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This= is a broader definition than that in NXDOMAIN [RFC8020]." This should be s= ufficient for determining that the domain is not intended to be used and th= erefore could have a more stringent policy applied.

The idea of looking for a "mail-enabled domain" base= d on if an "MX record exists or SPF policy exists" is interesting. Although= there may be domains that send email but not receive email and so may not = have an MX record. Also, even if there is no SPF record, the domain may sti= ll send email, but then it might be held to a more stringent DMARC policy t= hat would further penalize it for not having an SPF record.

Also, for the revision of the document I l= ike the way that the three parts of the experiment are now laid out more cl= early. My only comment is that the title of Appendix A is overly specific t= o just one of the experiments and so should be broader.

Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster <fosterd@bayviewphysicians.com>
<= div fr-original-style=3D"" style=3D"box-sizing: border-box;">Sent: Tuesday,= November 17, 2020 9:46 AM
To: 'IETF DMARC WG' <dmarc@ietf.org>
Cc: dmarc-chairs@ietf= .org
Sub= ject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of = NP

I did not see a definition= of a "non-existent domain" (the np policy).   A definition is needed.=

To my thinking, the obvious = rule should be to query for a NS record for the domain.  If the record= exists, then the domain owner could create a DMARC record for that domain,= or could create a default entry for the domain at the organizational level= .  If no record exists, it is because the domain owner chose to not cr= eate one.
However, the DMARC = Bis document conflicts strongly with this.  In section A.4, it suggest= several ways to do a test of this type, then repudiates all of them.  = ;NS lookup is not one of the mentioned options.

There is a possible second-level policy test for a "mail= -enabled domain".  I would define that test as "MX record exists or SP= F policy exists".    That could be an additional option to NP, bu= t should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general so= lution to a general problem.    If there are still objections to = it becoming a general solution, this should be addressed soon.

Doug Foster


Fr= om: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, N= ovember 13, 2020 1:42 PM
To: IETF DMARC WG
Cc: dmarc-chairs@ietf.org
Subject: [dmarc-ietf] Second= WGLC for draft-ietf-dmarc-psd

All

During the IESG reviews of draft-ietf-dmar= c-psd, there were several issues raised with some of the document.   M= ost of them are editorial but the one big item was the description of the E= xperiment.   The chairs sat down and broke out the experiment section = into three separate experiments, and included language on how to capture th= e data to confirm how the experiment worked. 

It's enough of a change that we wanted to do a second= working group last call to make sure the working group agrees with our cha= nges. The diff of the current version with the previous version is here:&nb= sp;


<= div fr-original-style=3D"" style=3D"box-sizing: border-box;">This starts a = *one* week second working group last call for  draft-ietf-dmarc-psd
Please rev= iew the changes and offer up comments to the working group.

This working group last call 20 November 2= 020

Thanks,

--ce57cc3e7a9f4b23879edbfb95690d0d-- From nobody Thu Nov 19 19:44:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8A73A175F for ; Thu, 19 Nov 2020 19:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT7-p8KpSkw5 for ; Thu, 19 Nov 2020 19:44:39 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E3C3A176C for ; Thu, 19 Nov 2020 19:44:39 -0800 (PST) X-ASG-Debug-ID: 1605843874-11fa313c0113870001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id On8PrRy60VNwtHhF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Thu, 19 Nov 2020 22:44:35 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=JjI3BEdUnYcER92BF0lkGtuCeJYIS7Mj1PXOacFOrA4=; b=SBChyqP9QUwGwgRej9lDMRsDh6wHJr7Y8cCUUxBYKt+fmX2aeVZ6goEjJd/hQsddu usCPjzMke6cBpCSZ5Dd1yPYI+uqOS56aPL22Ak361ucUDJuaXeFvgFhNamLzCFY+w 5X9VkoE3yRc1JRrq9Z6BMR8wIueQNkD6yS2Ct+0WM= From: "Douglas E. Foster" To: "IETF DMARC WG" Date: Thu, 19 Nov 2020 22:44:22 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Reply-To: fosterd@bayviewphysicians.com Message-ID: <90433555c5d34c2a98744c408e617f06@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=100785ffc62f4df3a7ffa0e9c0c5b9e1 In-Reply-To: References: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> X-Exim-Id: 90433555c5d34c2a98744c408e617f06 X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605843874 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 21241 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85993 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 03:44:42 -0000 This is a multipart message in MIME format. --100785ffc62f4df3a7ffa0e9c0c5b9e1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Time to show my ignorance again. How do I check a domain for presence or absence of A, AAAA, or MX records= =3F I thought most domains were protected from enumeration, so one had to know = a name to find out if it is defined DF ---------------------------------------- From: "Douglas E. Foster" Sent: 11/19/20 9:27 PM To: "IETF DMARC WG" Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP Thank you for the pointer Eric. Can someone explain why the chosen algorithm, which requires testing multip= le conditions, is preferable to a single query for a name server record=3F = Minimizing DNS traffic has been part of our recent discussion, and minimi= zing software complexity is always a good thing. Can someone also explain why the DMARC appendix takes such a strong stance = against all queries for non-existent domains, regardless of technique=3F I= t seems like the philosophical incompatibilities need to be addressed befor= e both documents advance. DMARC is specified only as a test for the RFC5322.From domain. RFC5321.Ma= ilFrom domains may also be non-existent. They will return SPF NONE, but th= at is an ambiguous result, and SPF has no organization default mechanism. = - Is there data to indicate whether evaluators have found that checking the= RFC5321.MailFrom for non-existence is useful=3F - Suppose that the NP policy becomes generalized, and a domain has asserted= a "must-exist" DMARC policy. Should a non-existent subdomain used in the= RFC5321.MailFrom address be treated skeptically=3F I can imagine a scenario where a spammer uses a bogus subdomain of a legiti= mate organization, in an attempt to get whitelisted by spam filters which p= rimarily evaluate the RFC5321.MailFrom address. This attack could be pair= ed with an unrelated and non-DMARC RFC5322.From address which is newly mint= ed or otherwise not generally known to be suspicious, So my instinct is t= hat some extension of DMARC to the SMTP address will be beneficial. Doug Foster ---------------------------------------- From: "Chudow, Eric B CIV NSA DSAW (USA)" Sent: 11/19/20 5:31 PM To: 'Doug Foster' , 'IETF DMARC WG' Cc: "'dmarc-chairs@ietf.org'" Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP Section 2.7. defines a non-existent domain as "a domain for which there is = an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a broad= er definition than that in NXDOMAIN [RFC8020]." This should be sufficient f= or determining that the domain is not intended to be used and therefore cou= ld have a more stringent policy applied. The idea of looking for a "mail-enabled domain" based on if an "MX record e= xists or SPF policy exists" is interesting. Although there may be domains t= hat send email but not receive email and so may not have an MX record. Also= , even if there is no SPF record, the domain may still send email, but then= it might be held to a more stringent DMARC policy that would further penal= ize it for not having an SPF record. Also, for the revision of the document I like the way that the three parts = of the experiment are now laid out more clearly. My only comment is that th= e title of Appendix A is overly specific to just one of the experiments and= so should be broader. Thanks, Eric Chudow DoD Cybersecurity Mitigations From: Doug Foster Sent: Tuesday, November 17, 2020 9:46 AM To: 'IETF DMARC WG' Cc: dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP I did not see a definition of a "non-existent domain" (the np policy). A = definition is needed. To my thinking, the obvious rule should be to query for a NS record for the= domain. If the record exists, then the domain owner could create a DMARC = record for that domain, or could create a default entry for the domain at t= he organizational level. If no record exists, it is because the domain own= er chose to not create one. However, the DMARC Bis document conflicts strongly with this. In section A= .4, it suggest several ways to do a test of this type, then repudiates all = of them. NS lookup is not one of the mentioned options. There is a possible second-level policy test for a "mail-enabled domain". = I would define that test as "MX record exists or SPF policy exists". Tha= t could be an additional option to NP, but should not be a replacement for = it. PSD for DMARC clearly intends for the NP policy to be a general solution to= a general problem. If there are still objections to it becoming a gener= al solution, this should be addressed soon. Doug Foster From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski Sent: Friday, November 13, 2020 1:42 PM To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd All During the IESG reviews of draft-ietf-dmarc-psd, there were several issues = raised with some of the document. Most of them are editorial but the one = big item was the description of the Experiment. The chairs sat down and b= roke out the experiment section into three separate experiments, and includ= ed language on how to capture the data to confirm how the experiment worked= . It's enough of a change that we wanted to do a second working group last ca= ll to make sure the working group agrees with our changes. The diff of the = current version with the previous version is here: https://www.ietf.org/rfcdiff=3Furl1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-= ietf-dmarc-psd-09 This starts a *one* week second working group last call for draft-ietf-dma= rc-psd Please review the changes and offer up comments to the working group. This working group last call 20 November 2020 Thanks, --100785ffc62f4df3a7ffa0e9c0c5b9e1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Time to show my ignorance again.

How do I check a domain for pre= sence or absence of A, AAAA, or MX records=3F
I thought most domains were protect= ed from enumeration, so one had to know a name to find out if it is defined=

DF


From: "= Douglas E. Foster" <fosterd@bayviewphysicians.com>
Sent: 11/19/20 9= :27 PM
= To: "IETF DMARC WG" <dmarc@ietf.org>
Subject: RE: [dmarc= -ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
<= div fr-original-style=3D"" style=3D"box-sizing: border-box;">
Thank you for the pointer Eric.

Can someone explain why the chosen algorithm, = which requires testing multiple conditions, is preferable to a single query= for a name server record=3F   Minimizing DNS traffic has been part of= our recent discussion, and minimizing software complexity is always a good= thing.
=
Can someone also expl= ain why the DMARC appendix takes such a strong stance against all queries f= or non-existent domains, regardless of technique=3F  It seems like the= philosophical incompatibilities need to be addressed before both documents= advance.
DMARC is specified = only as a test for the RFC5322.From domain.   RFC5321.MailFrom domains= may also be non-existent.  They will return SPF NONE, but that is an = ambiguous result, and SPF has no organization default mechanism.  &nbs= p;
    <= li fr-original-style=3D"" style=3D"box-sizing: border-box;">Is there data t= o indicate whether evaluators have found that checking the RFC5321.MailFrom= for non-existence is useful=3F   
  • Suppose that the NP policy becomes gener= alized, and a domain has asserted a "must-exist" DMARC policy.   Shoul= d a non-existent subdomain used in the RFC5321.MailFrom address be treated = skeptically=3F
I can imagine a scenario where a spammer uses a bogus subdomain = of a legitimate organization, in an attempt to get whitelisted by spam filt= ers which primarily evaluate the RFC5321.MailFrom address.   This atta= ck could be paired with an unrelated and non-DMARC RFC5322.From address whi= ch is newly minted or otherwise not generally known to be suspicious,  = ; So my instinct is that some extension of DMARC to the SMTP address will b= e beneficial.

Doug Foster




From: "Chudow, Eric B CIV N= SA DSAW (USA)" <eric.b.chudow.civ@mail.mil>
Sent: 11/19/20 5:31 PM<= br fr-original-style=3D"" style=3D"box-sizing: border-box;">To: 'Doug Foster' <fosterd@bayviewphysicians.com>, 'IETF DMARC WG' = <dmarc@ietf.org>
Cc: "'dmarc-chairs@ietf.org'" <dmarc-chairs@iet= f.org>
Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:= Definition of NP

Sect= ion 2.7. defines a non-existent domain as "a domain for which there is an N= XDOMAIN or NODATA response for A, AAAA, and MX records. This is a broader d= efinition than that in NXDOMAIN [RFC8020]." This should be sufficient for d= etermining that the domain is not intended to be used and therefore could h= ave a more stringent policy applied.

The idea of looking for a "mail-enabled domain" based on if an "MX = record exists or SPF policy exists" is interesting. Although there may be d= omains that send email but not receive email and so may not have an MX reco= rd. Also, even if there is no SPF record, the domain may still send email, = but then it might be held to a more stringent DMARC policy that would furth= er penalize it for not having an SPF record.

Also, for the revision of the document I like the way that = the three parts of the experiment are now laid out more clearly. My only co= mment is that the title of Appendix A is overly specific to just one of the= experiments and so should be broader.

Thanks,

Eric Chudow=
DoD Cyb= ersecurity Mitigations

From: = Doug Foster <fosterd@bayviewphysicians.com>
Sent: Tuesday, November 17, 2020 = 9:46 AM
= To: 'IETF DMARC WG' <dmarc@ietf.org>
Cc: dmarc-chairs@ietf.org
Subject: Re: [dmarc-ie= tf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

I did not see a definition of a "non-existent= domain" (the np policy).   A definition is needed.

To my thinking, the obvious rule should be to = query for a NS record for the domain.  If the record exists, then the = domain owner could create a DMARC record for that domain, or could create a= default entry for the domain at the organizational level.  If no reco= rd exists, it is because the domain owner chose to not create one.

However, the DMARC Bis document con= flicts strongly with this.  In section A.4, it suggest several ways to= do a test of this type, then repudiates all of them.  NS lookup is no= t one of the mentioned options.

There is a possible second-level policy test for a "mail-enabled domain"= .  I would define that test as "MX record exists or SPF policy exists"= .    That could be an additional option to NP, but should not be = a replacement for it.

=
PSD for= DMARC clearly intends for the NP policy to be a general solution to a gene= ral problem.    If there are still objections to it becoming a ge= neral solution, this should be addressed soon.

Doug Foster

From: dmarc [mailto= :dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski
Sent: Friday, November 13, 2020 = 1:42 PM
= To: IETF DMARC WG
Cc: dmarc-chairs@ietf.org
Subject: [dmarc-ietf] Second WGLC for draft-ie= tf-dmarc-psd


All

During the IESG reviews of draft-ietf-dmarc-psd, there were = several issues raised with some of the document.   Most of them are ed= itorial but the one big item was the description of the Experiment.   = The chairs sat down and broke out the experiment section into three separat= e experiments, and included language on how to capture the data to confirm = how the experiment worked. 

It's enough of a change that we wanted to do a second working group las= t call to make sure the working group agrees with our changes. The diff of = the current version with the previous version is here: 

https://www.ietf.org/rfcdiff= =3Furl1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-ietf-dmarc-psd-09

This starts a *one* week second= working group last call for  draft-ietf-dmarc-psd
Please review the changes a= nd offer up comments to the working group.

This working group last call 20 November 2020

Thanks,

--100785ffc62f4df3a7ffa0e9c0c5b9e1-- From nobody Thu Nov 19 20:04:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5318D3A17C3 for ; Thu, 19 Nov 2020 20:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=MgzUIr0i; dkim=pass (2048-bit key) header.d=taugh.com header.b=P8sFbYrm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLtxWZ65kLqI for ; Thu, 19 Nov 2020 20:04:23 -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 4F7FA3A17C1 for ; Thu, 19 Nov 2020 20:04:22 -0800 (PST) Received: (qmail 78316 invoked from network); 20 Nov 2020 04:04:21 -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:cleverness; s=131ea.5fb74045.k2011; bh=mp883IPxKMUdvt1BbM1WnXVJDr7wBuWNY+J7EPaZs8E=; b=MgzUIr0iTKTx0YUzLRPVPKN9lsrQAEOBXtpTJwLofxPcjxpnwQS5WxmAwL8JPuZEbt2S/fKjCjQAf06g/YGjpetrQjedNSDpnLRH4pwxH0IMAuTyV1nI/MNSyVt681lCwMc0fR3r5WhV5dDjvjEQcJwkAaBgrz4UsEsLfzU5Cl0RK/sRTNwcvgEaI0cvq/TItXnbQTYbqUrrAOHU4C1JzircMUw2iRlC1Pc8KdU+kK8HH9ILYA0g2q9+Mz5twQUEF8WRs1tAOhRAjtuG9NtGP3w4RqKl0T7QdPrJhyDkpAvomz8okWJVzNZ35UyRWAOTdo5vVM4LMRUVzMf6D3ENfQ== 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:cleverness; s=131ea.5fb74045.k2011; bh=mp883IPxKMUdvt1BbM1WnXVJDr7wBuWNY+J7EPaZs8E=; b=P8sFbYrmJXu3OQyrrp3Yb7TuMeSP71khmmhOO+c89UXGyhrYp0sf/armFTfR+AlBhjnt8KPsrnN9f7zsIlk0A5d6cN3E7RIjZazJfmEhf2B5Ys9u+yLwI+hblnuAX5w6eFIBVqBb7WH+AC5iBFwKiNTxrDbF78u1zRuPg0l1AAep9jRxye7HJQW5BYZ+CEjvEzxRJn72xEGXJD27KxKg9bddB70W1GUhg+fPzbdJ0Qvhf7ztSKioisVo2LgbCla9Ykow6i0l4DKWa56TWa7428zyiZZvSEIzaszKGDGWYow8M5HoDirBRER5XVgHjo9l2KZFU7iQpcy5YpUkVFquPA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 20 Nov 2020 04:04:21 -0000 Received: by ary.qy (Postfix, from userid 501) id B3F4727A02FB; Thu, 19 Nov 2020 23:04:19 -0500 (EST) Date: 19 Nov 2020 23:04:19 -0500 Message-Id: <20201120040420.B3F4727A02FB@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: eric.b.chudow.civ@mail.mil In-Reply-To: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 04:04:25 -0000 In article <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX >records. This is a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the >domain is not intended to be used and therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. R's, John From nobody Thu Nov 19 20:04:58 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433573A17C3 for ; Thu, 19 Nov 2020 20:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STjzkzX5VoGa for ; Thu, 19 Nov 2020 20:04:48 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424203A1841 for ; Thu, 19 Nov 2020 20:04:36 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id q206so8955719oif.13 for ; Thu, 19 Nov 2020 20:04: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 :cc; bh=iVtzhkAw15EhIuaj/iRuZfc0hBMtneF4MaBEp2vkgyw=; b=LNF67mRsivrlwAFnuR2DVjcVK8XdbTaLH6qFZ7KriWeixFEFeXza67dlQzgZidu04W Ffi94D7HE5Ic2yyEZVTob8ol26AOxRFKZsc2kFiykwrKdbv6K82aDuw1gx9ziBMaPeen kmDtFSyE09N9QidG4w88qvDDDWAh3TDY4b+yx+4k/S1bQGI6Ju4N4htXr+MIe0X5aoy0 R34LiMT6HmZ7Tq2A5f64V6a/L6SDGltR5qgT0TmM7yMaXzmWn8KsCOFqdghmB5gK3G8Q 2x1Y3E1cIa0SUw5uvOnz9CGcQ3gC6ztbzmDjwPFnbT4CmWqgaJHs0eR7FEKXQAntyIF2 eDsg== 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=iVtzhkAw15EhIuaj/iRuZfc0hBMtneF4MaBEp2vkgyw=; b=HP6FBTKtyraVx76XvutPIghcRnYz/OtexV4irmpOCvAro2wZ4EkcsPNJwSDS7bfMFb SdLZJWggcbmHPtTzPL7EgroyzyzvgVusVujEbVg+TOwhysnLi8EBDy+nV3O7KZbfw//m dmxWGNkqM785qFWQ3Oz90AwwKpcqeGOEKeVZH2OEEinIvNzcEJYKJU71wDYCMObNTjs/ hUOfzCgBQmAHSk61JxOsFfVI3Dpd2SVJs9+C2yVU+Vr79UDGHEJnFyK5kxjT1qF2jfK9 Y0BZBJOxUURohmnkhx/cmwpcONFWzDmanlnJPzBsQCX6vd6s1oQEqiijsq0S+1d9LaPZ U/LA== X-Gm-Message-State: AOAM5331zmgRVyTrW5lXz5ynITjf39ddBotaX+0xb0neGTuj1LHnx7bD +LmHYeU/M6anVrvisluo+jBAo+dXlgSpHCCXSIA= X-Google-Smtp-Source: ABdhPJzTnQlO5Hy1ZRsd6NBr6vFBbcBU6c2Mi0GcTdA7k35ewLXbEwy6/rN2XC221r0IYy3ERboSXQMA9iUg0DzqRB4= X-Received: by 2002:aca:e155:: with SMTP id y82mr5287604oig.21.1605845075603; Thu, 19 Nov 2020 20:04:35 -0800 (PST) MIME-Version: 1.0 References: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <90433555c5d34c2a98744c408e617f06@bayviewphysicians.com> In-Reply-To: <90433555c5d34c2a98744c408e617f06@bayviewphysicians.com> From: Tim Wicinski Date: Thu, 19 Nov 2020 23:04:24 -0500 Message-ID: To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004bb33905b481f16f" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 04:04:56 -0000 --0000000000004bb33905b481f16f Content-Type: text/plain; charset="UTF-8" Doug In looking for domain presence most folks will look at the domain itself. There are a few web tools to enumerate such as https://dnschecker.org/ Some examples https://dnschecker.org/#MX/dmarc.org https://dnschecker.org/#TXT/dmarc.org https://dnschecker.org/#TXT/_dmarc.dmarc.org There are unix tools - such as 'dig' - which are also quite useful. hope this helps tim On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster wrote: > Time to show my ignorance again. > > How do I check a domain for presence or absence of A, AAAA, or MX records? > I thought most domains were protected from enumeration, so one had to know > a name to find out if it is defined > > DF > > > ------------------------------ > *From*: "Douglas E. Foster" > *Sent*: 11/19/20 9:27 PM > *To*: "IETF DMARC WG" > *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: > Definition of NP > > Thank you for the pointer Eric. > > Can someone explain why the chosen algorithm, which requires testing > multiple conditions, is preferable to a single query for a name server > record? Minimizing DNS traffic has been part of our recent discussion, > and minimizing software complexity is always a good thing. > > Can someone also explain why the DMARC appendix takes such a strong stance > against all queries for non-existent domains, regardless of technique? It > seems like the philosophical incompatibilities need to be addressed before > both documents advance. > > DMARC is specified only as a test for the RFC5322.From domain. > RFC5321.MailFrom domains may also be non-existent. They will return SPF > NONE, but that is an ambiguous result, and SPF has no organization default > mechanism. > > - Is there data to indicate whether evaluators have found that > checking the RFC5321.MailFrom for non-existence is useful? > - Suppose that the NP policy becomes generalized, and a domain has > asserted a "must-exist" DMARC policy. Should a non-existent subdomain > used in the RFC5321.MailFrom address be treated skeptically? > > I can imagine a scenario where a spammer uses a bogus subdomain of a > legitimate organization, in an attempt to get whitelisted by spam filters > which primarily evaluate the RFC5321.MailFrom address. This attack could > be paired with an unrelated and non-DMARC RFC5322.From address which is > newly minted or otherwise not generally known to be suspicious, So my > instinct is that some extension of DMARC to the SMTP address will be > beneficial. > > Doug Foster > > > > > ------------------------------ > *From*: "Chudow, Eric B CIV NSA DSAW (USA)" > *Sent*: 11/19/20 5:31 PM > *To*: 'Doug Foster' , 'IETF DMARC WG' < > dmarc@ietf.org> > *Cc*: "'dmarc-chairs@ietf.org'" > *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: > Definition of NP > > Section 2.7. defines a non-existent domain as "a domain for which there is > an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a > broader definition than that in NXDOMAIN [RFC8020]." This should be > sufficient for determining that the domain is not intended to be used and > therefore could have a more stringent policy applied. > > The idea of looking for a "mail-enabled domain" based on if an "MX record > exists or SPF policy exists" is interesting. Although there may be domains > that send email but not receive email and so may not have an MX record. > Also, even if there is no SPF record, the domain may still send email, but > then it might be held to a more stringent DMARC policy that would further > penalize it for not having an SPF record. > > Also, for the revision of the document I like the way that the three parts > of the experiment are now laid out more clearly. My only comment is that > the title of Appendix A is overly specific to just one of the experiments > and so should be broader. > > Thanks, > > Eric Chudow > DoD Cybersecurity Mitigations > > From: Doug Foster > Sent: Tuesday, November 17, 2020 9:46 AM > To: 'IETF DMARC WG' > Cc: dmarc-chairs@ietf.org > Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition > of NP > > I did not see a definition of a "non-existent domain" (the np policy). A > definition is needed. > > To my thinking, the obvious rule should be to query for a NS record for > the domain. If the record exists, then the domain owner could create a > DMARC record for that domain, or could create a default entry for the > domain at the organizational level. If no record exists, it is because the > domain owner chose to not create one. > > However, the DMARC Bis document conflicts strongly with this. In section > A.4, it suggest several ways to do a test of this type, then repudiates all > of them. NS lookup is not one of the mentioned options. > > There is a possible second-level policy test for a "mail-enabled domain". > I would define that test as "MX record exists or SPF policy exists". > That could be an additional option to NP, but should not be a replacement > for it. > > PSD for DMARC clearly intends for the NP policy to be a general solution > to a general problem. If there are still objections to it becoming a > general solution, this should be addressed soon. > > Doug Foster > > > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski > Sent: Friday, November 13, 2020 1:42 PM > To: IETF DMARC WG > Cc: dmarc-chairs@ietf.org > Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd > > > All > > During the IESG reviews of draft-ietf-dmarc-psd, there were several issues > raised with some of the document. Most of them are editorial but the one > big item was the description of the Experiment. The chairs sat down and > broke out the experiment section into three separate experiments, and > included language on how to capture the data to confirm how the experiment > worked. > > It's enough of a change that we wanted to do a second working group last > call to make sure the working group agrees with our changes. The diff of > the current version with the previous version is here: > > > https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09 > > This starts a *one* week second working group last call for > draft-ietf-dmarc-psd > Please review the changes and offer up comments to the working group. > > This working group last call 20 November 2020 > > Thanks, > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --0000000000004bb33905b481f16f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doug
<= br>
In lo= oking for domain presence most folks will look at the domain itself.=C2=A0 = There are a few web tools to enumerate
such as=C2=A0https://dnschecker.org/=C2=A0

Some examples
https://dnschecker.org/#MX/dmarc.org
https://dnschecker.org/#TXT/dmarc.org

There are unix tools - such as 'dig' - which are also quite useful= .

hope this h= elps
tim<= /div>


On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster <fosterd=3D40bayviewphysicians.com@= dmarc.ietf.org> wrote:
Time to show my ignorance again.

How do I check a domain for presence or absence= of A, AAAA, or MX records?
I tho= ught most domains were protected from enumeration, so one had to know a nam= e to find out if it is defined
DF


From: "Douglas E. = Foster" <fosterd@bayviewphysicians.com>
Sent: 11/19/20 9:27 PM
To: "IETF DMARC WG" = <dmarc@ietf.org&= gt;
Subject: RE: [dmarc-ietf] Second WGLC for draf= t-ietf-dmarc-psd: Definition of NP

Thank you for the pointer Eric.

Can someone explain why the chosen algorithm, which requires tes= ting multiple conditions, is preferable to a single query for a name server= record? =C2=A0 Minimizing DNS traffic has been part of our recent discussi= on, and minimizing software complexity is always a good thing.

Can someone also explain why the DMARC ap= pendix takes such a strong stance against all queries for non-existent doma= ins, regardless of technique?=C2=A0 It seems like the philosophical incompa= tibilities need to be addressed before both documents advance.

DMARC is specified only as a test for the= RFC5322.From domain. =C2=A0 RFC5321.MailFrom domains may also be non-exist= ent.=C2=A0 They will return SPF NONE, but that is an ambiguous result, and = SPF has no organization default mechanism. =C2=A0=C2=A0
  • Is there data to ind= icate whether evaluators have found that checking the RFC5321.MailFrom for = non-existence is useful? =C2=A0=C2=A0
  • Suppose that the NP policy becomes generalized, and a domain has asserte= d a "must-exist" DMARC policy. =C2=A0 Should a non-existent subdo= main used in the RFC5321.MailFrom address be treated skeptically?
=
I can imagine a scenario where a spamm= er uses a bogus subdomain of a legitimate organization, in an attempt to ge= t whitelisted by spam filters which primarily evaluate the RFC5321.MailFrom= address. =C2=A0 This attack could be paired with an unrelated and non-DMAR= C RFC5322.From address which is newly minted or otherwise not generally kno= wn to be suspicious, =C2=A0 So my instinct is that some extension of DMARC = to the SMTP address will be beneficial.

Doug Foster


<= br style=3D"box-sizing:border-box">

From: "Chudow, Eric B CIV NSA DSAW (USA)" <eric.b.chudow.civ@mail.mil>
Sent: 11/19/20 5:31 PM
To: 'Doug Foster' <fosterd@bayviewphysicians.com>, 'IETF= DMARC WG' <dmar= c@ietf.org>
Cc: "'dmarc-chairs@ietf.org'&q= uot; <dmarc-c= hairs@ietf.org>
Subject: RE: [dmarc-ietf] S= econd WGLC for draft-ietf-dmarc-psd: Definition of NP

Section 2.7. defines a non-existent domain = as "a domain for which there is an NXDOMAIN or NODATA response for A, = AAAA, and MX records. This is a broader definition than that in NXDOMAIN [R= FC8020]." This should be sufficient for determining that the domain is= not intended to be used and therefore could have a more stringent policy a= pplied.

The idea of looking f= or a "mail-enabled domain" based on if an "MX record exists = or SPF policy exists" is interesting. Although there may be domains th= at send email but not receive email and so may not have an MX record. Also,= even if there is no SPF record, the domain may still send email, but then = it might be held to a more stringent DMARC policy that would further penali= ze it for not having an SPF record.

Also, for the revision of the document I like the way that the three= parts of the experiment are now laid out more clearly. My only comment is = that the title of Appendix A is overly specific to just one of the experime= nts and so should be broader.
Thanks,

Eric Chudow
DoD Cybersecurity Mitigations

From: Doug Foster <fosterd@bayviewphysicians.= com>
Sent: Tuesday, Novemb= er 17, 2020 9:46 AM
To: 'IETF= DMARC WG' <dmar= c@ietf.org>
Cc: dmarc-chairs@ietf.org<= /div>
Subject: Re: [dmarc-ietf] Second = WGLC for draft-ietf-dmarc-psd: Definition of NP

I did not see a definition of a "non-existent domai= n" (the np policy). =C2=A0 A definition is needed.

To my thinking, the obvious rule should be to qu= ery for a NS record for the domain.=C2=A0 If the record exists, then the do= main owner could create a DMARC record for that domain, or could create a d= efault entry for the domain at the organizational level.=C2=A0 If no record= exists, it is because the domain owner chose to not create one.

<= div style=3D"box-sizing:border-box">However, the DMARC Bis document conflic= ts strongly with this.=C2=A0 In section A.4, it suggest several ways to do = a test of this type, then repudiates all of them.=C2=A0 NS lookup is not on= e of the mentioned options.

T= here is a possible second-level policy test for a "mail-enabled domain= ".=C2=A0 I would define that test as "MX record exists or SPF pol= icy exists". =C2=A0 =C2=A0That could be an additional option to NP, bu= t should not be a replacement for it.

PSD for DMARC clearly intends for the NP policy to be a general so= lution to a general problem. =C2=A0 =C2=A0If there are still objections to = it becoming a general solution, this should be addressed soon.

Doug Foster


From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wici= nski
Sent: Friday, November 13, 2= 020 1:42 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-= psd


All

During the IESG reviews of draft-ietf-dmarc-= psd, there were several issues raised with some of the document. =C2=A0 Mos= t of them are editorial but the one big item was the description of the Exp= eriment. =C2=A0 The chairs sat down and broke out the experiment section in= to three separate experiments, and included language on how to capture the = data to confirm how the experiment worked.=C2=A0

It's enough of a change that we wanted to do a seco= nd working group last call to make sure the working group agrees with our c= hanges. The diff of the current version with the previous version is here:= =C2=A0


This starts a *one* = week second working group last call for =C2=A0draft-ietf-dmarc-psd
Please review the changes and offer up co= mments to the working group.

= This working group last call 20 November 2020

Thanks,

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--0000000000004bb33905b481f16f-- From nobody Thu Nov 19 22:03:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A42B3A18ED for ; Thu, 19 Nov 2020 22:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00limWpG_Pu5 for ; Thu, 19 Nov 2020 22:03:19 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 611E33A18EB for ; Thu, 19 Nov 2020 22:03:19 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id f7so4417369vsh.10 for ; Thu, 19 Nov 2020 22:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gs/LDmNhx1mzs612aEAw+zeckUxqYLzAUVUIyN+URXc=; b=cLKAytWuRkx+gSXjst0ucnRk6eiBhqHeU37HjOtNver3Io3PnhXoZ4kjNw3pBq4QUW xrIvXLikTcjU/ZXQHIYYodi0xU/d/mcARfKDvxTMQ8XKMrw327F+u0YCTIztGdsrnuq5 yL/jFp+4NdhCg1TW2eOgnobNtVPwh5d6w7wIi+97/osxeu7cKEfeNVWcL5izPDHsSF/6 uzxdu4m7SejESL/jKt0ZzKhgkWTPKoMjiiihLwTgwCRzVHy72GAkTkIKdnqTC7jARcB8 Ekt+oyF6+x23pLu4rSJtfJCs8VwPhNChsV0imN3oNVCHyaHAkn8E25Ll1njJmcUEInTQ gWJQ== 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=Gs/LDmNhx1mzs612aEAw+zeckUxqYLzAUVUIyN+URXc=; b=HECHMs4zxD2kfEddM94KpGmaU7YLL8rkOLKBbjGaN6SOBdGbFq5nRexw2CkriEuElz 0K8LOl5xHe8Wmg8p3bqNfDvctgYLC0Beqj6cFiJthi2edtLC3ofjM65VvCOdqyA5lJnJ E8lglkkKCGp3bG5CLLeQweib7OkY76a+Yj/koJE3YZp+Rx1qfFlSjDLPN5qZPx/UMsvv 26/TFfhTIoDJjzier8BssGkflB0r5FF3Pxd7dHQrHt+5JNyL7xgnb8hOtxBve6ROMzEC 7vid8lKKAVDlAdsPH6vQG3HoaYsoETjX5+/00cBJHUJCov2B3ou/dOMDijLaj2eLT/KK M9mg== X-Gm-Message-State: AOAM533fHAXmIdLNiarEyQ8UZy1PORiYNFkwGoXzzyf4cQttDw707jMc iSJoT7nXAsMy3LXpIngEgLKpeHcpRMgMFlfCTzCnmvcG X-Google-Smtp-Source: ABdhPJxlJnl9rXIf1mvCITW/+HkkXAPzphqRhC61GHP2E5NxBKgY0xTEYMYpsuVRuu4D1vJHx9zrGVTPV5ovyoKRFFU= X-Received: by 2002:a67:6981:: with SMTP id e123mr12169808vsc.40.1605852198185; Thu, 19 Nov 2020 22:03:18 -0800 (PST) MIME-Version: 1.0 References: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <90433555c5d34c2a98744c408e617f06@bayviewphysicians.com> In-Reply-To: <90433555c5d34c2a98744c408e617f06@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Thu, 19 Nov 2020 22:03:06 -0800 Message-ID: To: Doug Foster Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d5b36205b4839927" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 06:03:23 -0000 --000000000000d5b36205b4839927 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 19, 2020 at 7:44 PM Douglas E. Foster wrote: > How do I check a domain for presence or absence of A, AAAA, or MX records? > I thought most domains were protected from enumeration, so one had to know > a name to find out if it is defined > Do you mean what does the DNS question look like? Or what tool can you use to make the query yourself? Or something else? -MSK --000000000000d5b36205b4839927 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 19, 2020 at 7:44 PM Douglas E= . Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
How do I check a domain for pre= sence or absence of A, AAAA, or MX records?
I thought most domains were protected from enumeration, so one had to = know a name to find out if it is defined

<= /div>
Do you mean what does the DNS question look like?=C2=A0 Or what t= ool can you use to make the query yourself?=C2=A0 Or something else?
<= div>
-MSK
--000000000000d5b36205b4839927-- From nobody Fri Nov 20 01:31:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69773A1566 for ; Fri, 20 Nov 2020 01:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbW2MJONhefH for ; Fri, 20 Nov 2020 01:31:07 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58343A1B04 for ; Fri, 20 Nov 2020 01:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1605864665; bh=HlEvRhdtH5XqJYd8McgS4hCZgceEGXjC16y6kGW1BHc=; l=3954; h=To:References:From:Date:In-Reply-To; b=CjeMolY28a5CBAiIWyH2YuG8ki6k4rUS0pNLfLna4iTJ9Xf3h7Fa+/LTNYPZwyriy C+O/Ms6/g+q1FML5c/ErkbvDqrtvbjsSeP3OUhlJJodNsxEu0/ppiw9pY3C3bo1hNd IrPv2pR1u1gquahfzM60zDDAHJQEDUahbrTpJlPIxbdJzOIXSuUy7Ctj72gCz Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FB78CD9.000021FF; Fri, 20 Nov 2020 10:31:05 +0100 To: dmarc@ietf.org References: <20201118204436.5BE81278D997@ary.qy> <2cabc3c3-3f72-f3f8-0909-860112d25141@dcrocker.net> From: Alessandro Vesely Message-ID: Date: Fri, 20 Nov 2020 10:31:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] org domain and levine-dbound and dns-perimeter drafts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 09:31:12 -0000 On 19/11/2020 21:33, Todd Herr wrote: > On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely wrote: >> On 18/11/2020 22:33, John R Levine wrote: >>>> On 11/18/2020 12:44 PM, John Levine wrote: >>>>> so I encourage the group to limit the debate to the existing Org/PSL >>>>> kludge and a tree walk. >>>> >>>> "and a tree walk" is not a minor 'and'. neither conceptually nor >>>> operationally. assurances to the contrary notwithstanding. >>> >>> I didn't say they were equivalent. But I do think they are the only >>> options that are likely to get much interest from the WG. >> >> I don't think tree walk is a viable option, as it distorts semantics. >> > Forgive me, but I don't know what you mean by the phrase "distorts > semantics"; can you please help me understand? The current semantics considers an Organizational Domain to be the expression of the organization itself, the organization's master domain. That's quite nearly what the PSL strive for. Tree walk, instead, discards any organizational boundary. > As for the viability of a tree walk, it is possible in complex environments > to have something resembling the following: > > - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent > - _dmarc.b.foo.com record exists, p=x, rua=r1 > - _dmarc.foo.com record exists, p=y, rua=r2 - _dmarc.com record doesn't exist, for the time being. > On the other hand, one might infer from the DNS records that are published > that their intent was for a.b.foo.com to inherit x for the policy and r1 as > the destination for aggregate reports from the b.foo.com record; this would > be an error on their part, because DMARC does not currently support > discovery of the record at _dmarc.b.foo.com in this case. Without asking them directly, we could also infer that folks at b.foo.com are sneakily trying to divert feedback traffic. > The way I see it, we can choose one of three paths here: > > 1. Keep things as they are, where if there is no policy published for > RFC5322.From, the policy is inherited from the org domain, if a policy is > published there Easiest and safest option. > 2. Change the spec so that the only policy lookup done is for the > RFC5322.From domain, and if there's no policy there, then DMARC doesn't > exist for that domain SPF experience shows that large domains don't have the ability to maintain a script that defines suitable DNS records for all their subdomains. This would force inconsistent usage of '*' domains. BTW, as of your example, we have: ale@pcale:~$ dig _dmarc.b.foo.com txt ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> _dmarc.b.foo.com txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44418 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ab33c1fc9c9860b18b1294575fb788126f7a88216eadcab7 (good) ;; QUESTION SECTION: ;_dmarc.b.foo.com. IN TXT ;; ANSWER SECTION: _dmarc.b.foo.com. 600 IN TXT "v=spf1 -all" ;; AUTHORITY SECTION: foo.com. 250 IN NS ns2.digimedia.com. foo.com. 250 IN NS ns1.digimedia.com. ;; ADDITIONAL SECTION: ns1.digimedia.com. 172450 IN A 23.21.242.88 ns2.digimedia.com. 172450 IN A 23.21.243.119 > 3. Change the spec so that policies published between the RFC5322.From > domain and the organizational domain can be discovered, in order to support > the most flexibility across organizations. Besides making a lot of confusion about where policies and feedback addresses might come from, this feature inflates DNS queries more than it is desirable. If you have From: DoS you have to look up each subdomain in the required order. (Maybe you can check if z exists, and in case if m.n.o. ... x.y.z exists, and so on in a dichotomic anti-DoS tactic. Hm...) Best Ale -- From nobody Fri Nov 20 03:29:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C4E3A1C3C for ; Fri, 20 Nov 2020 03:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail.mil Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYCeL2znjxik for ; Fri, 20 Nov 2020 03:29:36 -0800 (PST) Received: from UPDC19PA21.eemsg.mail.mil (UPDC19PA21.eemsg.mail.mil [214.24.27.196]) (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 99BD43A1C3B for ; Fri, 20 Nov 2020 03:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1605871775; x=1637407775; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=n9omQvlOCKKiHK3BUzxX35PsskwFU8gXS0k0XH1FxIE=; b=GQQIau3O70YvKqMPmnChLsOumVsqRZDimVlugtupWBGdkDymmPjM3WSs /3W0XDFQvcYNE9ageBwBzxjbIWk6Dyxzy5Ai3zvnEWj2SIu5r5rDOnEgv b8rJbmcls2GMQGQV9IhwWWe6cFX/m0LyH+nP8Elxj3ZIqMwCZDMbDU2+O 2fi8U69Kd0xAHhQtudGL1EvwCsypmlq1qvgf+f3YzL8Q50Fi4EhIlB9Vj gN0NsK43JIolzRKJFToGhRmKkVyrkIgAozYPCl+Nez/s0SJSi+8JtApU/ EPIiLlrCHCn15/xH+LGLbwlDngeJldFsAKTwwro2LiffOZHMk7iiFtS+G A==; X-EEMSG-check-017: 148943052|UPDC19PA21_ESA_OUT03.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.78,356,1599523200"; d="scan'208";a="148943052" Received: from edge-mech02.mail.mil ([214.21.130.230]) by UPDC19PA21.eemsg.mail.mil with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2020 11:29:32 +0000 Received: from UMECHPAOY.easf.csd.disa.mil (214.21.130.168) by edge-mech02.mail.mil (214.21.130.230) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 20 Nov 2020 11:29:30 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.6.95]) by umechpaoy.easf.csd.disa.mil ([214.21.130.168]) with mapi id 14.03.0487.000; Fri, 20 Nov 2020 11:29:29 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: 'John Levine' , "'dmarc@ietf.org'" Thread-Topic: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thread-Index: AQHWvvJ/iKPnnZi5u022rWTX/j/mmKnQ4SXg Date: Fri, 20 Nov 2020 11:29:29 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> In-Reply-To: <20201120040420.B3F4727A02FB@ary.qy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.44.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 11:29:37 -0000 VGhhbmsgeW91LCBKb2huLiBJIGFncmVlIHRoYXQgaXQncyBhbiBlZGdlIGNhc2UgYW5kIG5vdCB3 b3J0aCBhZGRyZXNzaW5nIHNlcGFyYXRlbHkuIA0KDQpFcmljIENodWRvdw0KRG9EIEN5YmVyc2Vj dXJpdHkgTWl0aWdhdGlvbnMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpv aG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb20+IA0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE5 LCAyMDIwIDExOjA0IFBNDQpUbzogZG1hcmNAaWV0Zi5vcmcNCkNjOiBDaHVkb3csIEVyaWMgQiBD SVYgTlNBIERTQVcgKFVTQSkgPGVyaWMuYi5jaHVkb3cuY2l2QG1haWwubWlsPg0KU3ViamVjdDog UmU6IFtkbWFyYy1pZXRmXSBTZWNvbmQgV0dMQyBmb3IgZHJhZnQtaWV0Zi1kbWFyYy1wc2Q6IERl ZmluaXRpb24gb2YgTlANCg0KSW4gYXJ0aWNsZSA8NTUzRDQzQzhEOTYxQzE0QkIyN0M2MTRBQzQ4 RkMwMzEyODExNjQ5NEBVTUVDSFBBN0QuZWFzZi5jc2QuZGlzYS5taWw+IHlvdSB3cml0ZToNCj5T ZWN0aW9uIDIuNy4gZGVmaW5lcyBhIG5vbi1leGlzdGVudCBkb21haW4gYXMgImEgZG9tYWluIGZv ciB3aGljaCB0aGVyZSANCj5pcyBhbiBOWERPTUFJTiBvciBOT0RBVEEgcmVzcG9uc2UgZm9yIEEs IEFBQUEsIGFuZCBNWCByZWNvcmRzLiAgVGhpcyBpcyANCj5hIGJyb2FkZXIgZGVmaW5pdGlvbiB0 aGFuIHRoYXQgaW4gTlhET01BSU4gW1JGQzgwMjBdLiIgVGhpcyBzaG91bGQgYmUgc3VmZmljaWVu dCBmb3IgZGV0ZXJtaW5pbmcgdGhhdCB0aGUgZG9tYWluIGlzIG5vdCBpbnRlbmRlZCB0byBiZSB1 c2VkIGFuZCB0aGVyZWZvcmUgY291bGQgaGF2ZSBhIG1vcmUgc3RyaW5nZW50IHBvbGljeSBhcHBs aWVkLg0KPg0KPlRoZSBpZGVhIG9mIGxvb2tpbmcgZm9yIGEgIm1haWwtZW5hYmxlZCBkb21haW4i IGJhc2VkIG9uIGlmIGFuICJNWCByZWNvcmQgZXhpc3RzIG9yIFNQRiBwb2xpY3kgZXhpc3RzIiBp cyBpbnRlcmVzdGluZy4NCj5BbHRob3VnaCB0aGVyZSBtYXkgYmUgZG9tYWlucyB0aGF0IHNlbmQg ZW1haWwgYnV0IG5vdCByZWNlaXZlIGVtYWlsIGFuZCBzbyBtYXkgbm90IGhhdmUgYW4gTVggcmVj b3JkLg0KDQpUaGVzZSBkYXlzIEkgdGhpbmsgeW91IHdpbGwgZmluZCB0aGF0IGlmIHRoZSBkb21h aW5zIGluIHlvdXIgYm91bmNlIGFkZHJlc3MgYW5kIHlvdXIgRnJvbTogaGVhZGVycyBkb24ndCBo YXZlIGFuIE1YIG9yIEEgcmVjb3JkLCB2ZXJ5IGZldyByZWNpcGllbnRzIHdpbGwgYWNjZXB0IHlv dXIgbWFpbC4gVGhpcyBzZWVtcyBsaWtlIGFuIGVkZ2UgY2FzZS4gSW4gcHJhY3RpY2UgSSBmaW5k IHRoYXQgdGhlIGRvbWFpbnMgY2F1Z2h0IGJ5IHRoZSBPcmcgZG9tYWluIG9yIEkgc3VwcG9zZSBQ U0QgaGF2ZSBBIHJlY29yZHMgYnV0IG5vIG1haWwgc2VydmVyIGJlY2F1c2UgdGhleSdyZSBhY3R1 YWxseSB3ZWIgaG9zdHMgcmF0aGVyIHRoYW4gbWFpbCBob3N0cy4NCg0KV2UgaGF2ZSB0aGUgTnVs bCBNWCB0byBpbmRpY2F0ZSB0aGF0IGEgZG9tYWluIHJlY2VpdmVzIG5vIG1haWwgYW5kIFNQRiBw bGFpbiAtYWxsIHRvIGluZGljYXRlIHRoYXQgaXQgc2VuZHMgbm8gbWFpbCBzbyBJIGhvcGUgd2Ug ZG9uJ3QgdHJ5IHRvIHJlaW52ZW50IHRoZXNlIHBhcnRpY3VsYXIgd2hlZWxzLg0KDQpSJ3MsDQpK b2huDQoNCg0K From nobody Fri Nov 20 03:57:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425A23A1C7E for ; Fri, 20 Nov 2020 03:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TW-Q_J3waWu for ; Fri, 20 Nov 2020 03:57:29 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEF63A1C7D for ; Fri, 20 Nov 2020 03:57:28 -0800 (PST) X-ASG-Debug-ID: 1605873447-11fa313c0114d40001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id E3fS1yI7Qnbm1Yo1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 20 Nov 2020 06:57:27 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=3uSVoVN6Fo7I+evKXDW4n/5eNaeYz+WcnD3HXh3BwCU=; b=PRRvjjX221l3JHRRadhG5ecHJjrYbxA95aY2y4QhSL1iu8oNq9DP0C8SfGrthFtMs w6a6bzC66PoXeY/F/5XSxQA+D4onzooLy/O6zdxg0qKF3uJymJvdhMYdqGU8oNIHP G35chCQExhS2009Wfu49HYAoda8wSHvCi/Jd4NCC0= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Fri, 20 Nov 2020 06:57:20 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=57129732e30a4267b81501dd0b27b450 In-Reply-To: <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> X-Exim-Id: f3b54fdb25b24549a40105c6e4a31c6c X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605873447 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 13875 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.85999 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 11:57:31 -0000 This is a multipart message in MIME format. --57129732e30a4267b81501dd0b27b450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I fear that I muddied the waters by asking about the RFC5321.MailFrom addre= ss. Let's return to the main issue of the RFC5322.From address which DMAR= C protects. This is not an edge case. If spam filters were already blocking messages = with RFC5322.From addresses with non-existent domains, we would not be havi= ng this discussion. The RFC5322.From address can be very ethereal. Consider the following sit= uation: The marketing department of Example.com hires a mass mailer to do a campaig= n from marketing@ChristmasSale.Example.com. ChristmasSale.Example.Com does not currently exist. The email service provider does its due diligence during account setup: - The client has sent email communication from example.com and account pape= rwork for the same organization. I have the client identified correctly,. - The client has no DMARC policy on Christmas.Example.com, and an organizat= ion or PSD DMARC policy of SP=3Dnone, so I do not need to acquire a DKIM si= gning key. - But the organization or PSD policy does specify NP, so I need the client = to prove that ChristmasSale.Example.Com exists. Requiring the client to create a bogus host record with a bogus IP address = makes no sense, and is likely to be rejected by the client DNS administrato= r. Requiring the client to create a name server record to prove domain existen= ce does make sense, and should be easily approved and implemented by the cl= ient DNS administrator. Ergo, defining the NP policy based on A, AAAA, and MX is not appropriate. Doug Foster ---------------------------------------- From: eric.b.chudow.civ=3D40mail.mil@dmarc.ietf.org Sent: 11/20/20 6:30 AM To: 'John Levine' , "'dmarc@ietf.org'" Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP Thank you, John. I agree that it's an edge case and not worth addressing se= parately. Eric Chudow DoD Cybersecurity Mitigations -----Original Message----- From: John Levine Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP In article <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.dis= a.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be suff= icient for determining that the domain is not intended to be used and there= fore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record = exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so= may not have an MX record. These days I think you will find that if the domains in your bounce address= and your From: headers don't have an MX or A record, very few recipients w= ill accept your mail. This seems like an edge case. In practice I find that= the domains caught by the Org domain or I suppose PSD have A records but n= o mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plai= n -all to indicate that it sends no mail so I hope we don't try to reinvent= these particular wheels. R's, John =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --57129732e30a4267b81501dd0b27b450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I fear that I muddied the waters by= asking about the RFC5321.MailFrom address.   Let's return to the main= issue of the RFC5322.From address which DMARC protects.

This is not an edge case.   If spam filte= rs were already blocking messages with RFC5322.From addresses with non-exis= tent domains, we would not be having this discussion.

The RFC5322.From address can be very ethereal. &nb= sp; Consider the following situation:

The marketing department of Example.com hires a mass mailer to do a campaign from marketing@ChristmasSale.Example.com.   
ChristmasSale.Example.Com does not c= urrently exist.
The email service provider does its due diligence during account se= tup:
- The client has sent em= ail communication from example.com and account paperwork for the same organ= ization.   I have the client identified correctly,.
- The client has no DMARC = policy on Christmas.Example.com, and an organization or PSD DMARC policy of= SP=3Dnone, so I do not need to acquire a DKIM signing key.
- But the organization = or PSD policy does specify NP, so I need the client to prove that ChristmasSale.Example= .Com exists.

Requiring th= e client to create a bogus host record with a bogus IP address makes no sen= se, and is likely to be rejected by the client DNS administrator.

Requiring the client to create a name = server record to prove domain existence does make sense, and should be easi= ly approved and implemented by the client DNS administrator.

Ergo, defining the NP policy based on A, A= AAA, and MX is not appropriate.

Doug Foster

<= div fr-original-style=3D"" style=3D"box-sizing: border-box;">
From: eric.b.chudow.civ=3D40mail.mil@dmar= c.ietf.org
Sent: 11/20/20 6:30 AM
To: 'John Levine' <johnl@taugh.com= >, "'dmarc@ietf.org'" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf]= Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Thank you, John. I agree that it's an edg= e case and not worth addressing separately.

Eric Chudow
DoD Cybersecurity Mitigations

-----Original Message-----
From: John Levine <johnl@taugh.= com>
= Sent: Thursday, November 19, 2020 11:04 PM
To: dmarc@ietf.org
Cc: Chudow, Eric B CIV NSA DS= AW (USA) <eric.b.chudow.civ@mail.mil>
Subject: Re: [dmarc-ietf] Second WGLC f= or draft-ietf-dmarc-psd: Definition of NP

In article <553D43C8D961C14BB27C614AC48FC03128116494@UMECHP= A7D.easf.csd.disa.mil> you write:
>Section 2.7. defines a non-existent domain= as "a domain for which there
>is an NXDOMAIN or NODATA response for A, AAAA, an= d MX records. This is
>a broader definition than that in NXDOMAIN [RFC8020]." Th= is should be sufficient for determining that the domain is not intended to = be used and therefore could have a more stringent policy applied.
>
>The idea of look= ing for a "mail-enabled domain" based on if an "MX record exists or SPF pol= icy exists" is interesting.
>Although there may be domains that send email but n= ot receive email and so may not have an MX record.

These days I think you will find that if the domains = in your bounce address and your From: headers don't have an MX or A record,= very few recipients will accept your mail. This seems like an edge case. I= n practice I find that the domains caught by the Org domain or I suppose PS= D have A records but no mail server because they're actually web hosts rath= er than mail hosts.

We have t= he Null MX to indicate that a domain receives no mail and SPF plain -all to= indicate that it sends no mail so I hope we don't try to reinvent these pa= rticular wheels.

R's,
John


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
d= marc mailing list
dmarc@ietf.org

--57129732e30a4267b81501dd0b27b450-- From nobody Fri Nov 20 05:57:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7273A09B7 for ; Fri, 20 Nov 2020 05:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uubd-s26Ni4f for ; Fri, 20 Nov 2020 05:57:31 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA7E3A09B5 for ; Fri, 20 Nov 2020 05:57:30 -0800 (PST) X-ASG-Debug-ID: 1605880645-11fa313c0116df0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id pkLdnttCbxjrg1qL (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Fri, 20 Nov 2020 08:57:26 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=3sln6w9FNkf6P/1JV2QufL+f39DkeRnZ1U+oQ4XjEDM=; b=Q4Iifbl5cuF6QBK7o/r9oEQx69BZ0K6DreXkMgGdT/Lqr3bGOdhnyf9EEEo8wqcwg fcKuxuH8pORE94SeeuuJa3eQKZGP06eiNvwKAexagYVxQgU6vPbU2UQs9td7Bn1hF lmbdYCHY30QcLJh2gx/TPl/9nCjhN/JqnUkLkFoRQ= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Fri, 20 Nov 2020 08:57:18 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> In-Reply-To: <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> Date: Fri, 20 Nov 2020 08:57:18 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Message-ID: <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMRkJ651mMtwaRq5ZOwhYGq3kYYqwGhop7wAr1KT5ynOGU88A== Content-Language: en-us X-Exim-Id: 000001d6bf45$0f62cc30$2e286490$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605880646 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 4165 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86000 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 13:57:33 -0000 To return briefly to the muddy waters that I created. John is correct that "mail enabled" is not useful for the RFC5322.From address, and my last note expanded on reasons why that is correct. However, spoofing of non-existent subdomains is a potential problem for the RFC5321.MailFrom domain, which then becomes an attack vector for the RFC5322.From address as well. The problem exists because because SPF has no organizational default. We need to think about intermediate nodes, non-mail leaf nodes, and non-existent subdomains. Assume that a spammer tries to spoof a legitimate organization by using a non-mail or non-existing node for both the SMTP MailFrom address and the message From Address. The message will be evaluated as - SPF=None, - DomainAligned=True, and - (if checked by some unknown algorithm) OrganizationReputation=good. Can we assume that all such messages will be blocked by all recipients? It seems better to have a published policy to say that it should be blocked. Based on existing specifications, the organization has these defenses: - All possibilities are protected if the organization DMARC sp policy is enforceable (p<>none and pct<>0). However, we know that this is problematic for many organizations. - Mail-enabled nodes should have an SPF record, so those domains will be protected. - Existing but non-mail domains are only protected if they have an SPF -ALL policy. This may be difficult and error-prone for the organization to maintain. Conclusions: Assuming that many organizations are still at sp=none, we have an attack surface from non-existent domains. The "must exist" policy provides the only defense for non-existent nodes when the DMARC sp policy is non-enforcing. Assuming that many organizations will have trouble managing deployment of SPF -ALL universally, we have an attack surface for non-mail subdomains. The "must be mail enabled" policy provides a simpler defense mechanism than deploying SPF -ALL to every non-mail node. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Chudow, Eric B CIV NSA DSAW (USA) Sent: Friday, November 20, 2020 6:29 AM To: 'John Levine'; 'dmarc@ietf.org' Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thank you, John. I agree that it's an edge case and not worth addressing separately. Eric Chudow DoD Cybersecurity Mitigations -----Original Message----- From: John Levine Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP In article <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find that the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plain -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Nov 20 08:53:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B218E3A0EB4 for ; Fri, 20 Nov 2020 08:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lknpyZNRZRFP for ; Fri, 20 Nov 2020 08:52:54 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF073A0EAA for ; Fri, 20 Nov 2020 08:52:54 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id q1so9123754ilt.6 for ; Fri, 20 Nov 2020 08:52:54 -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=xyG4O3ieAU/qFZdUg+luL8NHjyLCo9NDcXPdmFttk+I=; b=AP9fGGELRNKJTbu+etX6MjHkXIWdV4vnlIsIyzl/s9gbqAZg36A+cS01IkDvqFC7Nz icBXd30WYYin/yQ3STVDt7kZuNAOHQmaGtz/HJpobMj7wR4LqPD0WFOhnLghpBVsVI4v LwpRuVbZC0srfbhMt420OXL340ESNhk2JuRjc= 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=xyG4O3ieAU/qFZdUg+luL8NHjyLCo9NDcXPdmFttk+I=; b=L2/7WgqK+Ai8DOd+2ODoxMn/1o58k7Xd4iOBLYh+vXV8RC3Oh/jyDz66r95PdwlXO/ q57rm0J8F7j4DMlluSoPeTls8sd/A6sJrrEmA4HbKxdsSq8cgjBAHZAym5UuSnlBSa4k ydtyoSD7f37XlZ6zvoTVwh7IKQMHOpdJY5xaTGQsuDaApoC8skGV8gSFKSe5ivoswBNK kA7SDkquASfWvAUwijzkdYuJgaBnzjwq+lUeupcVvTNEXZI+dXVD11SPMKV1nLIYES7C mlVMNFYv2kpSPiaH1HPgvsyA7XAYbEto4Kx5ZewgDLfCCZ9FSqtjjVSp9WEP1bhQjkUB ElUQ== X-Gm-Message-State: AOAM532kW08LqTLmmyqSWTO081QrDJNe8ip5gkQKxTThIcNoEmmu04ql yo6c9DG/IL/9a/FlTCSXYpyukGMHfL1FQ88oF6YrcQ== X-Google-Smtp-Source: ABdhPJz3F6BaSf8fho6DSvNfvlVpERT1ehDY9cZWIq+rlxk1ztW6obYLDi/iIWLtr2HRdavNXlyJc2ttOz0NAjPDi7w= X-Received: by 2002:a05:6e02:481:: with SMTP id b1mr27697491ils.104.1605891173984; Fri, 20 Nov 2020 08:52:53 -0800 (PST) MIME-Version: 1.0 References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> In-Reply-To: <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> From: "Kurt Andersen (b)" Date: Fri, 20 Nov 2020 08:52:41 -0800 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f93c9905b48cac04" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 20 Nov 2020 16:52:58 -0000 --000000000000f93c9905b48cac04 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 20, 2020 at 5:57 AM Doug Foster wrote: > > However, spoofing of non-existent subdomains is a potential problem for the > RFC5321.MailFrom domain, which then becomes an attack vector for the > RFC5322.From address as well. The problem exists because because SPF has > no > organizational default. > > We need to think about intermediate nodes, non-mail leaf nodes, and > non-existent subdomains. Assume that a spammer tries to spoof a legitimate > organization by using a non-mail or non-existing node for both the SMTP > MailFrom address and the message From Address. The message will be > evaluated as > - SPF=None, > - DomainAligned=True, and > - (if checked by some unknown algorithm) OrganizationReputation=good. > > Presuming no DKIM signature is involved, SPF=None is not the required "PASS" that DMARC enforces so I don't see the point of your argument. --Kurt --000000000000f93c9905b48cac04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 20, 2020 at 5:57 AM Doug Fost= er <fosterd=3D= 40bayviewphysicians.com@dmarc.ietf.org> wrote:

However, spoofing of non-existent subdomains is a potential problem for the=
RFC5321.MailFrom domain, which then becomes an attack vector for the
RFC5322.From address as well.=C2=A0 The problem exists because because SPF = has no
organizational default.=C2=A0 =C2=A0

We need to think about intermediate nodes, non-mail leaf nodes, and
non-existent subdomains.=C2=A0 Assume that a spammer tries to spoof a legit= imate
organization by using a non-mail=C2=A0 or non-existing node for both the SM= TP
MailFrom address and the message From Address.=C2=A0 =C2=A0The message will= be
evaluated as
- SPF=3DNone,
- DomainAligned=3DTrue, and
- (if checked by some unknown algorithm)=C2=A0 OrganizationReputation=3Dgoo= d.=C2=A0 =C2=A0 =C2=A0

Presuming no DK= IM signature is involved, SPF=3DNone is not the required "PASS" t= hat DMARC enforces so I don't see the point of your argument.

--Kurt=C2=A0
--000000000000f93c9905b48cac04-- From nobody Fri Nov 20 16:02:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078E73A0CD2 for ; Fri, 20 Nov 2020 16:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=AHeWPDVJ; dkim=pass (2048-bit key) header.d=taugh.com header.b=StrTRvGQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ4l2CFyFZWU for ; Fri, 20 Nov 2020 16:02:23 -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 1EA373A0CD1 for ; Fri, 20 Nov 2020 16:02:22 -0800 (PST) Received: (qmail 62682 invoked from network); 21 Nov 2020 00:02:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type; s=f4d7.5fb8590d.k2011; i=johnl-iecc.com@submit.iecc.com; bh=QL/Ql2tPkklFibrNPAKOmWScL9O4DxO8eccd5wXgw+4=; b=AHeWPDVJlJ7OjJCbE98YDRLTqu1Pqy6SrEeDPwp+EVlRCAfTscvG0FGrI7VWdItuD1ntyMgDzsqUxGIWNlqHgpeF/Mg3+umi5WBwqzKufd91dhr5rpn0tIxBIV4sYVLt5UAb8svX7Svl9X2/B2If4m6OUP0GsxEeAY5uPI6gHdipcSJj6zitASAHcbCvJ6is+GVIjK9VZYDqzdajjNjma0+gzuBKJzFslEpKM2DcHmoGXMJHkZNHT1F9w1C8afAgSO6EF2y35efIFH4m6l7VO0XUFsjjea72vaYOLAOe2kIAIc59IfGlQ96aV2Rda7uojDqeT6DFDLmNMrdJUVYAnA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type; s=f4d7.5fb8590d.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=QL/Ql2tPkklFibrNPAKOmWScL9O4DxO8eccd5wXgw+4=; b=StrTRvGQzgQ41F+HGoHiobpcLgVSk1zIfM8Y5jVOpyr947YyPcoHMGSeCXNhVboU1INev5NfGFmVmhLjFCwJkdfmDJt+/vxynqp3hXyhvYC7ePh4XDp7m74nTGEkWY36sP0SKzBc9vY/adk+2TgiuXaEzQqOc8BOzPYgWxdgY6qvHELKK3BQeFnM5rOpftrJ4J/6LUX0UbCXZjN1Kq7TMv2FDZchS91diXc41ELtNd+ILtHOjG1fO5ckKuNXkL/Yo7w8LBxylDuobX3+Oud8CWh06H/CTQY3M8b/3T6DslIF3qWvw1HnVuAZRL1dYkhp6izoK2VeBOmGjDCLME4leQ== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 21 Nov 2020 00:02:21 -0000 Date: 20 Nov 2020 19:02:20 -0500 Message-ID: From: "John R Levine" To: "IETF DMARC WG" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2020 00:02:25 -0000 Here's a draft about how DMARC might do a tree walk rather than look up an organizational domain in the PSL. https://datatracker.ietf.org/doc/draft-levine-dmarcwalk/ Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Nov 21 09:02:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5183A08AF for ; Sat, 21 Nov 2020 09:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OgmAcvsvqW5 for ; Sat, 21 Nov 2020 09:02:15 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32AA3A08A9 for ; Sat, 21 Nov 2020 09:02:15 -0800 (PST) X-ASG-Debug-ID: 1605978130-11fa313c01269c0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id Vv2IHoAax1KPG8WT (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sat, 21 Nov 2020 12:02:10 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=J01QFu2RunnbAnp516w57RzWDLdu+wJLD5DcUQYM4MM=; b=eLDWafuOkCXiQgjQSuzpkuTBie/d2vBJ9VKz1dRdgVBNGfvw6oWjBYhVZQ9grmSRj xIBeYqwYx+VQsfw04m3zvmB1mZ1cIi2zeOa8CktX4DqqhaTWKUqthOKf7KkYuHzun UK+CIGReznVdNWKRG3o+mP7nsYNy0MJJDdYJea0z0= From: "Douglas E. Foster" To: , Date: Sat, 21 Nov 2020 12:02:03 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=673e488ee984482cbcce9c00f0c85316 In-Reply-To: <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> X-Exim-Id: b6f2bf756f9146daafa717c2645ed58d X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605978130 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 27408 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86027 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2020 17:02:19 -0000 This is a multipart message in MIME format. --673e488ee984482cbcce9c00f0c85316 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Restating what we all know: - The Internet is dependent on the reliable operation of the DNS name syste= m. - The DNS name system is dependent on the reliable operation of the name re= gistration processes. - The registrars are given ownership of all unregistered domain names withi= n their portion of the hierarchy. - The public evidence of registration is the existence of a DNS entry, and = a NS record is always the first one configured. Conclusions - Unregistered use of any domain name is an attack on the architecture of t= he Internet. - PSD for DMARC is asking us to give public suffix operators what they are = supposed to already have: control over unregistered names. - We should implement new and universal policies:- Unregistered names used = as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.- Unregiste= red names used as message From header addresses MUST generate DMARC FAIL an= d SHOULD be rejected. Protecting the integrity of the name registration system is not an optional= activity to be implemented by a few organizations with the most sophistica= ted implementations of the DMARC specification. It should be a mandatory = duty of every legitimate participant on the network. Starting from the assumption that unregistered domains might be allowable c= reates many problems when trying to design solutions for protecting the nam= es that are registered. This assumption needs to be rejected. Addressing some straw-man questions: Q: The idea is fine for public suffixes, but my organization doesn't need = to do that for subdomains under its control. A: Every level of the DNS tree needs coordination of name usage. Publis= hing an NS record for an organization subdomain proves that the organizatio= n's process has been followed. Besides, the boundary between public suffi= xes and organizational domains is imprecise, so recipients cannot be expect= ed to apply differential expectations. Q: My business partner and I exchange information using unregistered subdom= ains, and it is working fine. Leave me alone. A: Of course, senders can register with recipients, to obtain a filtering e= xception, as an alternative to registering in the public DNS. But the def= ault behavior should be to block messages. Note that private use of unreg= istered subdomains may cause subsequent conflicts if the organization assig= ns the name to another purpose. Q. How do we get all incoming filters to change to default block for unregi= stered domain names=3F A. I would suggest using the CVE/CCE process. Q. What does this mean for the PSD for DMARC process=3F A. I think it becomes unnecessary. Getting all participants to block all= unregistered domains is a better goal, and can probably be achieved more e= asily. It should involve relatively simple software changes, minimal DNS = load, and minimal evaluation-time overhead. Doug Foster ---------------------------------------- From: fosterd=3D40bayviewphysicians.com@dmarc.ietf.org Sent: 11/20/20 8:58 AM To: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP To return briefly to the muddy waters that I created. John is correct that "mail enabled" is not useful for the RFC5322.From address, and my last note expanded on reasons why that is correct. However, spoofing of non-existent subdomains is a potential problem for the RFC5321.MailFrom domain, which then becomes an attack vector for the RFC5322.From address as well. The problem exists because because SPF has no organizational default. We need to think about intermediate nodes, non-mail leaf nodes, and non-existent subdomains. Assume that a spammer tries to spoof a legitimate organization by using a non-mail or non-existing node for both the SMTP MailFrom address and the message From Address. The message will be evaluated as - SPF=3DNone, - DomainAligned=3DTrue, and - (if checked by some unknown algorithm) OrganizationReputation=3Dgood. Can we assume that all such messages will be blocked by all recipients=3F I= t seems better to have a published policy to say that it should be blocked. Based on existing specifications, the organization has these defenses: - All possibilities are protected if the organization DMARC sp policy is enforceable (p<>none and pct<>0). However, we know that this is problematic for many organizations. - Mail-enabled nodes should have an SPF record, so those domains will be protected. - Existing but non-mail domains are only protected if they have an SPF -ALL policy. This may be difficult and error-prone for the organization to maintain. Conclusions: Assuming that many organizations are still at sp=3Dnone, we have an attack surface from non-existent domains. The "must exist" policy provides the only defense for non-existent nodes when the DMARC sp policy is non-enforcing. Assuming that many organizations will have trouble managing deployment of SPF -ALL universally, we have an attack surface for non-mail subdomains. The "must be mail enabled" policy provides a simpler defense mechanism than deploying SPF -ALL to every non-mail node. DF -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Chudow, Eric B CIV NSA DSAW (USA) Sent: Friday, November 20, 2020 6:29 AM To: 'John Levine'; 'dmarc@ietf.org' Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Thank you, John. I agree that it's an edge case and not worth addressing separately. Eric Chudow DoD Cybersecurity Mitigations -----Original Message----- From: John Levine Sent: Thursday, November 19, 2020 11:04 PM To: dmarc@ietf.org Cc: Chudow, Eric B CIV NSA DSAW (USA) Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP In article <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> you write: >Section 2.7. defines a non-existent domain as "a domain for which there >is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is >a broader definition than that in NXDOMAIN [RFC8020]." This should be sufficient for determining that the domain is not intended to be used and therefore could have a more stringent policy applied. > >The idea of looking for a "mail-enabled domain" based on if an "MX record exists or SPF policy exists" is interesting. >Although there may be domains that send email but not receive email and so may not have an MX record. These days I think you will find that if the domains in your bounce address and your From: headers don't have an MX or A record, very few recipients will accept your mail. This seems like an edge case. In practice I find tha= t the domains caught by the Org domain or I suppose PSD have A records but no mail server because they're actually web hosts rather than mail hosts. We have the Null MX to indicate that a domain receives no mail and SPF plai= n -all to indicate that it sends no mail so I hope we don't try to reinvent these particular wheels. R's, John =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --673e488ee984482cbcce9c00f0c85316 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Restating what we all know:
- The Internet = is dependent on the reliable operation of the DNS name system.
- The DNS name syste= m is dependent on the reliable operation of the name registration processes= .
- The = registrars are given ownership of all unregistered domain names within thei= r portion of the hierarchy.
- The public evidence of registration is the existence = of a DNS entry, and a NS record is always the first one configured. 

Conclusions
- Unregistered use of any = domain name is an attack on the architecture of the Internet.
- PSD for DMARC is as= king us to give public suffix operators what they are supposed to already h= ave:   control over unregistered names.
- We should implement new and universa= l policies:
    - Unregistered names used as SMTP addresses MUST generate= SPF FAIL and SHOULD be rejected.
    - Unregistered names used as messag= e From header addresses MUST generate DMARC FAIL and SHOULD be rejected.

Protecting the integrity of the= name registration system is not an optional activity to be implemented by = a few organizations with the most sophisticated implementations of the DMAR= C specification.   It should be a mandatory duty of every legitimate p= articipant on the network.

St= arting from the assumption that unregistered domains might be allowable cre= ates many problems when trying to design solutions for protecting the names= that are registered.   This assumption needs to be rejected.

Addressing some straw-man questions= :
Q: &nb= sp;The idea is fine for public suffixes, but my organization doesn't need t= o do that for subdomains under its control.
A:  Every level of the DNS tree ne= eds coordination of name usage.    Publishing an NS record for an= organization subdomain proves that the organization's process has been fol= lowed.   Besides, the boundary between public suffixes and organizatio= nal domains is imprecise, so recipients cannot be expected to apply differe= ntial expectations.

Q: My bus= iness partner and I exchange information using unregistered subdomains, and= it is working fine.   Leave me alone.
A: Of course, senders can register with= recipients, to obtain a filtering exception, as an alternative to register= ing in the public DNS.   But the default behavior should be to block m= essages.   Note that private use of unregistered subdomains may cause = subsequent conflicts if the organization assigns the name to another purpos= e.

Q. How do we get all incom= ing filters to change to default block for unregistered domain names=3F
A.  I = would suggest using the CVE/CCE process.

Q. What does this mean for the PSD for DMARC process=3F
A.  I thin= k it becomes unnecessary.   Getting all participants to block all unre= gistered domains is a better goal, and can probably be achieved more easily= .   It should involve relatively simple software changes, minimal DNS = load, and minimal evaluation-time overhead.

Doug Foster
 

From: fosterd=3D40bayviewphys= icians.com@dmarc.ietf.org
Sent: 11/20/20 8:58 AM
To: <dmarc@ietf.org= >
Su= bject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Defi= nition of NP

To return= briefly to the muddy waters that I created. John is correct that
"mail enabled" is= not useful for the RFC5322.From address, and my last note
expanded on reasons why = that is correct.

However, spo= ofing of non-existent subdomains is a potential problem for the
RFC5321.MailFrom do= main, which then becomes an attack vector for the
RFC5322.From address as well. The= problem exists because because SPF has no
organizational default.

We need to think about intermediate nodes, no= n-mail leaf nodes, and
non-existent subdomains. Assume that a spammer tries to spoo= f a legitimate
organization by using a non-mail or non-existing node for both the S= MTP
Mail= >From address and the message From Address. The message will be
evaluated as
- SPF=3DNone,
- DomainA= ligned=3DTrue, and
- (if checked by some unknown algorithm) OrganizationReputation= =3Dgood.

Can we assume that a= ll such messages will be blocked by all recipients=3F It
seems better to have a pub= lished policy to say that it should be blocked.
Based on existing specifications, t= he organization has these defenses:

- All possibilities are protected if the organization DMARC sp poli= cy is
en= forceable (p<>none and pct<>0). However, we know that this is
problemat= ic for many organizations.

- = Mail-enabled nodes should have an SPF record, so those domains will be
protected.

- Existing but non-mail domain= s are only protected if they have an SPF -ALL
policy. This may be difficult and e= rror-prone for the organization to
maintain.

Conclusions:
Assuming that many organizations are still at sp=3Dnone, we = have an attack
surface from non-existent domains. The "must exist" policy provides = the
only= defense for non-existent nodes when the DMARC sp policy is
non-enforcing.

Assuming that many organizations wi= ll have trouble managing deployment of
SPF -ALL universally, we have an attack surf= ace for non-mail subdomains.
The "must be mail enabled" policy provides a simpler d= efense mechanism than
deploying SPF -ALL to every non-mail node.

DF




-----Original Message-----
From: dmarc [mailto:dmarc-bounces@ietf.or= g] On Behalf Of Chudow, Eric B CIV
NSA DSAW (USA)
Sent: Friday, November 20, 2020 6:29 AM=
To: 'Jo= hn Levine'; 'dmarc@ietf.org'
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-d= marc-psd: Definition
of NP

Thank you,= John. I agree that it's an edge case and not worth addressing
separately.

Eric Chudow
DoD Cybersecurity Mitigations

-----Original Message-----
From: John = Levine <johnl@taugh.com>
Sent: Thursday, November 19, 2020 11:04 PM
To: dmarc@ietf.or= g
Cc: Ch= udow, Eric B CIV NSA DSAW (USA) <eric.b.chudow.civ@mail.mil>
Subject: Re: [dm= arc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
of NP

In article
<553D43C8D961C14BB27C614AC48FC0312811649= 4@UMECHPA7D.easf.csd.disa.mil> you
write:
>Section 2.7. defines a non-existent domain= as "a domain for which there
>is an NXDOMAIN or NODATA response for A, AAAA, an= d MX records. This is
>a broader definition than that in NXDOMAIN [RFC8020]." Th= is should be
sufficient for determining that the domain is not intended to be used = and
ther= efore could have a more stringent policy applied.
>
>The idea of looking for a "mail= -enabled domain" based on if an "MX record
exists or SPF policy exists" is interest= ing.
>= ;Although there may be domains that send email but not receive email and so=
may not= have an MX record.

These day= s I think you will find that if the domains in your bounce address
and your From: h= eaders don't have an MX or A record, very few recipients
will accept your mail. Thi= s seems like an edge case. In practice I find that
the domains caught by the Org do= main or I suppose PSD have A records but no
mail server because they're actually we= b hosts rather than mail hosts.

We have the Null MX to indicate that a domain receives no mail and SPF p= lain
-al= l to indicate that it sends no mail so I hope we don't try to reinvent
these partic= ular wheels.

R's,
John


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
dmar= c mailing list
dmarc@ietf.org



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
dmarc mailing list
dmarc@ietf.org

--673e488ee984482cbcce9c00f0c85316-- From nobody Sat Nov 21 11:12:09 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03593A0B62 for ; Sat, 21 Nov 2020 11:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9am44kcwpDH for ; Sat, 21 Nov 2020 11:12:04 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE823A0B6B for ; Sat, 21 Nov 2020 11:12:04 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id r5so6943963vsp.7 for ; Sat, 21 Nov 2020 11:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EjyInUOn/td7+pKw0dWGe7GZ0UwWNV0ipN/lokOWzT4=; b=aFzvnbIzLY8p6newkocHpjUOXMBRMLKfmB1x9c2QW//IhSpczS6QTN/dj0FXinc3Oj zEW1aVUUkex6cp3Qf2wn6tiCTLXnbGRpxySjN4K4Q7l7kyZbsyJpiBo+tFzVeHkyIhI4 BrRzLz9XIP9xBAAjPhjLPR0DKNiznd3n3JAhri/d6J9oCqlpopjz0dgSe9Sw8LdV/1Z+ hQc8nzCKaSls+hlX6U1CCfG2vGxbo/gKMcLU3qT438vkPGEUy42nEJfRSgxhEhesAZgg 6xWtVfSW+mJuLCeVaUvyv3LBJrweDusAQQ5aScPxw8+48IskSe4PneEdNP8JEYRDk6oX Y+SQ== 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=EjyInUOn/td7+pKw0dWGe7GZ0UwWNV0ipN/lokOWzT4=; b=I/leg0u/bRZdzQHc5Ho5hV8kQ+21c5MXWCnG06hiQKu2nMBarz5JmSEajrdkWZtmM9 LZOtb9GoV2PEr1ls9A9UJy7UD0bM1TsPZJSZzwMnI4acY/xVRd7yoyMFchJPTSfQfeHI 22JF8ohXqHjyEg4gv0X5PlCJCjInDKs2p+b83EIXmKDEMeBwCj5jcbz3L/0ZYC+EV2/a DMkU9Rol6A6FYoo+tylB1aSSzMOmhiIfo78n46SlvYrOzBgsZk+HzINuN67+XZtZkJiv X8JF7wm+i7d21bvTb6Vk8ZGvhTgYzeISx51VaY0JD40uIsVjlIh/Yo5CVOQsOA+kQWak AImA== X-Gm-Message-State: AOAM5310z6msPGIE1+WUkW7LO5ciLb2KbtZwyxy+Pvf9d66vDUF/PGUP fO8aTYoM/JICD+XGw/foB3gm9S0yRqsnoCBrFQM= X-Google-Smtp-Source: ABdhPJzLRz51WO7Tqn0hIh9X8BtGroJDI/6GAV29RtP0+72IhSpbyepjy4U8jz7T/z615WKtRL6hmM1ejvuDDre3K18= X-Received: by 2002:a67:f1c7:: with SMTP id v7mr949581vsm.40.1605985923499; Sat, 21 Nov 2020 11:12:03 -0800 (PST) MIME-Version: 1.0 References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 21 Nov 2020 11:11:49 -0800 Message-ID: To: Doug Foster Cc: Doug Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000007c08c405b4a2bc86" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2020 19:12:09 -0000 --0000000000007c08c405b4a2bc86 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster wrote: > Restating what we all know: > - The Internet is dependent on the reliable operation of the DNS name > system. > - The DNS name system is dependent on the reliable operation of the name > registration processes. > - The registrars are given ownership of all unregistered domain names > within their portion of the hierarchy. > - The public evidence of registration is the existence of a DNS entry, and > a NS record is always the first one configured. > > Conclusions > - Unregistered use of any domain name is an attack on the architecture of > the Internet. > - PSD for DMARC is asking us to give public suffix operators what they are > supposed to already have: control over unregistered names. > - We should implement new and universal policies: > - Unregistered names used as SMTP addresses MUST generate SPF FAIL and > SHOULD be rejected. > That is certainly a defensible assertion, but I would claim it is out of scope for DMARC. You're talking about a detail of SPF or perhaps of SMTP in general, although one could also even argue that this is a local policy decision and outside the scope of those protocols. I suspect the SMTP greybeards would claim that this is not part of SMTP, but rather an enforcement choice made by implementations. I believe this falls within the realm of what the IETF calls an Applicability Statement, which would be a standards track document (if you could get consensus for it). You could also include this in the DMARC usage document, or as non-normative advice in DMARC itself with an explanation of why it's a good idea, if you can develop consensus to do so. You also need to account for transient DNS outages. If your resolver temporarily thinks "gmail.com" doesn't exist, you will bounce all mail coming from that domain, and you might seriously piss off your users. There's a backscatter problem here too: If I send mail to a list you're on and you temporarily think my domain doesn't exist and you bounce mail coming from me, the list will unsubscribe you. - Unregistered names used as message From header addresses MUST > generate DMARC FAIL and SHOULD be rejected. > This is more in scope for DMARC discussions, though also arguably outside of the protocol itself, for the same reasons. I would suggest that it's a viable discussion for the DMARC usage document, whenever we get around to working on that again. But you could certainly test the working group opinion on this point. Protecting the integrity of the name registration system is not an optional > activity to be implemented by a few organizations with the most > sophisticated implementations of the DMARC specification. It should be a > mandatory duty of every legitimate participant on the network. > > Starting from the assumption that unregistered domains might be allowable > creates many problems when trying to design solutions for protecting the > names that are registered. This assumption needs to be rejected. > These are both probably true statements, but is DMARC the right place to wage this battle? For example, isn't it also true for TCP connections for which PTR records make false claims (or no claim)? Addressing some straw-man questions: > Q: The idea is fine for public suffixes, but my organization doesn't need > to do that for subdomains under its control. > A: Every level of the DNS tree needs coordination of name usage. > Publishing an NS record for an organization subdomain proves that the > organization's process has been followed. Besides, the boundary between > public suffixes and organizational domains is imprecise, so recipients > cannot be expected to apply differential expectations. > I still don't understand what the presence or absence of NS tells you that the presence or absence of MX/A/AAAA doesn't. If you have a message that fails the latter test but passes the former, does that change your handling decision? If not, why do it? Q. How do we get all incoming filters to change to default block for > unregistered domain names? > A. I would suggest using the CVE/CCE process. > That seems like a big hammer, and certainly outside of the IETF's purview. We're not the protocol police. You might try having this discussion in a context like M3AAWG though; many large operators congregate there to discuss stuff like this. -MSK --0000000000007c08c405b4a2bc86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 21, 2020 at 9:02 AM Douglas E= . Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
Restating what we all know:
- The Internet is dependent on the reliable operation of the DNS name syst= em.
- The DNS name system is depe= ndent on the reliable operation of the name registration processes.
- The registrars are given ownership of = all unregistered domain names within their portion of the hierarchy.
<= div style=3D"box-sizing:border-box">- The public evidence of registration i= s the existence of a DNS entry, and a NS record is always the first one con= figured.=C2=A0

Conclusions
- Unregistered use of any domain na= me is an attack on the architecture of the Internet.
- PSD for DMARC is asking us to give public suffix oper= ators what they are supposed to already have: =C2=A0 control over unregiste= red names.
- We should implement = new and universal policies:
=C2= =A0 =C2=A0 - Unregistered names used as SMTP addresses MUST generate SPF FA= IL and SHOULD be rejected.

That= is certainly a defensible assertion, but I would claim it is out of scope = for DMARC.=C2=A0 You're talking about a detail of SPF or perhaps of SMT= P in general, although one could also even argue that this is a local polic= y decision and outside the scope of those protocols.=C2=A0 I suspect the SM= TP greybeards would claim that this is not part of SMTP, but rather an enfo= rcement choice made by implementations.

I beli= eve this falls within the realm of what the IETF calls an Applicability Sta= tement, which would be a standards track document (if you could get consens= us for it).=C2=A0 You could also include this in the DMARC usage document, = or as non-normative advice in DMARC itself with an explanation of why it= 9;s a good idea, if you can develop consensus to do so.

You also need to account for transient DNS outages.=C2=A0 If your res= olver temporarily thinks "gmail.com&q= uot; doesn't exist, you will bounce all mail coming from that domain, a= nd you might seriously piss off your users.=C2=A0 There's a backscatter= problem here too: If I send mail to a list you're on and you temporari= ly think my domain doesn't exist and you bounce mail coming from me, th= e list will unsubscribe you.

=C2=A0 =C2=A0 - Unregistered names u= sed as message From header addresses MUST generate DMARC FAIL and SHOULD be= rejected.

This is more in scop= e for DMARC discussions, though also arguably outside of the protocol itsel= f, for the same reasons.=C2=A0 I would suggest that it's a viable discu= ssion for the DMARC usage document, whenever we get around to working on th= at again.=C2=A0 But you could certainly test the working group opinion on t= his point.

Protecting = the integrity of the name registration system is not an optional activity t= o be implemented by a few organizations with the most sophisticated impleme= ntations of the DMARC specification. =C2=A0 It should be a mandatory duty o= f every legitimate participant on the network.

Starting from the assumption that unregiste= red domains might be allowable creates many problems when trying to design = solutions for protecting the names that are registered. =C2=A0 This assumpt= ion needs to be rejected.

These= are both probably true statements, but is DMARC the right place to wage th= is battle?=C2=A0 For example, isn't it also true for TCP connections fo= r which PTR records make false claims (or no claim)?

Addressing s= ome straw-man questions:
Q: =C2= =A0The idea is fine for public suffixes, but my organization doesn't ne= ed to do that for subdomains under its control.
A: =C2=A0Every level of the DNS tree needs coordination of n= ame usage. =C2=A0 =C2=A0Publishing an NS record for an organization subdoma= in proves that the organization's process has been followed. =C2=A0 Bes= ides, the boundary between public suffixes and organizational domains is im= precise, so recipients cannot be expected to apply differential expectation= s.

I still don't understand what= the presence or absence of NS tells you that the presence or absence of MX= /A/AAAA doesn't.=C2=A0 If you have a message that fails the latter test= but passes the former, does that change your handling decision?=C2=A0 If n= ot, why do it?

Q. How do we get all incoming filters= to change to default block for unregistered domain names?
A.=C2=A0 I would suggest using the CVE/CCE process.

That seems like a big hammer, and = certainly outside of the IETF's purview.=C2=A0 We're not the protoc= ol police.=C2=A0 You might try having this discussion in a context like M3A= AWG though; many large operators congregate there to discuss stuff like thi= s.

-MSK
--0000000000007c08c405b4a2bc86-- From nobody Sat Nov 21 11:26:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5174D3A0C00 for ; Sat, 21 Nov 2020 11:26:12 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t47uhf11NzZV for ; Sat, 21 Nov 2020 11:26:10 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471FF3A0BFF for ; Sat, 21 Nov 2020 11:26:10 -0800 (PST) X-ASG-Debug-ID: 1605986768-11fa313c0127700001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id vCao3z0L1nx8zVLy (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Sat, 21 Nov 2020 14:26:08 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=T+j9+FPOCLtjOY4lWtHqnM7120wyHDi56qnfqjN7LFw=; b=pJ5xCFGgIxk9WcNNEZV8i6DA7Dvi32pgZiK5C8u8J3jaf0haG6/gHatlFUX+sEcYi Bc8pJCQAS/8MV3a/d0HUcoL1Eet4NjlNOxALh4AQe621ctFxdkCIfNBYq3T/Pw5Cr Fsk0hh8fiqAeP+5Yz895wu36L3enyAetYaRE+LP2Q= Received: by webmail.bayviewphysicians.com via HTTP; Sat, 21 Nov 2020 14:25:59 -0500 To: "Murray S. Kucherawy" Cc: Doug Foster , IETF DMARC WG Date: Sat, 21 Nov 2020 14:25:57 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Message-ID: MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=15c6bc21cfad4a32adcb2021868ffffa SavedFromEmail: fosterd@bayviewphysicians.com Importance: normal From: "Douglas E. Foster" X-Exim-Id: fcad08d6f98649359d9d8d400b88c8df X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1605986768 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 12652 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86029 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2020 19:26:12 -0000 This is a multipart message in MIME format. --15c6bc21cfad4a32adcb2021868ffffa Content-Type: multipart/alternative; boundary=472d6a6269ed4665ad7bf6da33a6086a --472d6a6269ed4665ad7bf6da33a6086a Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Does a transient outage report NXDOMAIN, or a different status?
-------- Original message --------
From: "Murray S. Kucherawy"
Date: 11/21/20 2:12 PM (GMT-05:00)
To: Doug Foster
Cc: Doug Foster , IETF DMARC WG
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster wrote: > Restating what we all know: > - The Internet is dependent on the reliable operation of the DNS name > system. > - The DNS name system is dependent on the reliable operation of the name > registration processes. > - The registrars are given ownership of all unregistered domain names > within their portion of the hierarchy. > - The public evidence of registration is the existence of a DNS entry, and > a NS record is always the first one configured. > > Conclusions > - Unregistered use of any domain name is an attack on the architecture of > the Internet. > - PSD for DMARC is asking us to give public suffix operators what they are > supposed to already have: control over unregistered names. > - We should implement new and universal policies: > - Unregistered names used as SMTP addresses MUST generate SPF FAIL and > SHOULD be rejected. > That is certainly a defensible assertion, but I would claim it is out of scope for DMARC. You're talking about a detail of SPF or perhaps of SMTP in general, although one could also even argue that this is a local policy decision and outside the scope of those protocols. I suspect the SMTP greybeards would claim that this is not part of SMTP, but rather an enforcement choice made by implementations. I believe this falls within the realm of what the IETF calls an Applicability Statement, which would be a standards track document (if you could get consensus for it). You could also include this in the DMARC usage document, or as non-normative advice in DMARC itself with an explanation of why it's a good idea, if you can develop consensus to do so. You also need to account for transient DNS outages. If your resolver temporarily thinks "gmail.com" doesn't exist, you will bounce all mail coming from that domain, and you might seriously piss off your users. There's a backscatter problem here too: If I send mail to a list you're on and you temporarily think my domain doesn't exist and you bounce mail coming from me, the list will unsubscribe you. - Unregistered names used as message From header addresses MUST > generate DMARC FAIL and SHOULD be rejected. > This is more in scope for DMARC discussions, though also arguably outside of the protocol itself, for the same reasons. I would suggest that it's a viable discussion for the DMARC usage document, whenever we get around to working on that again. But you could certainly test the working group opinion on this point. Protecting the integrity of the name registration system is not an optional > activity to be implemented by a few organizations with the most > sophisticated implementations of the DMARC specification. It should be a > mandatory duty of every legitimate participant on the network. > > Starting from the assumption that unregistered domains might be allowable > creates many problems when trying to design solutions for protecting the > names that are registered. This assumption needs to be rejected. > These are both probably true statements, but is DMARC the right place to wage this battle? For example, isn't it also true for TCP connections for which PTR records make false claims (or no claim)? Addressing some straw-man questions: > Q: The idea is fine for public suffixes, but my organization doesn't need > to do that for subdomains under its control. > A: Every level of the DNS tree needs coordination of name usage. > Publishing an NS record for an organization subdomain proves that the > organization's process has been followed. Besides, the boundary between > public suffixes and organizational domains is imprecise, so recipients > cannot be expected to apply differential expectations. > I still don't understand what the presence or absence of NS tells you that the presence or absence of MX/A/AAAA doesn't. If you have a message that fails the latter test but passes the former, does that change your handling decision? If not, why do it? Q. How do we get all incoming filters to change to default block for > unregistered domain names? > A. I would suggest using the CVE/CCE process. > That seems like a big hammer, and certainly outside of the IETF's purview. We're not the protocol police. You might try having this discussion in a context like M3AAWG though; many large operators congregate there to discuss stuff like this. -MSK --472d6a6269ed4665ad7bf6da33a6086a Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does a transient outa= ge report NXDOMAIN, or a different status=3F



-------- Orig= inal message --------
From: "Murray S. Kucherawy" <superuser@g= mail.com>
Date: 11/21/20 2:12 PM (GMT-05:00)
To:= Doug Foster <fosterd@bayviewphysicians.com>
Cc: Doug Fost= er <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org>, IETF DMARC WG = <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Second WGLC for= draft-ietf-dmarc-psd: Definition of NP

On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster <f= osterd=3D40bayvie= wphysicians.com@dmarc.ietf.org> wrote:
Res= tating what we all know:
- The In= ternet is dependent on the reliable operation of the DNS name system.
=
- The DNS name system is dependent on = the reliable operation of the name registration processes.
- The registrars are given ownership of all unre= gistered domain names within their portion of the hierarchy.
- The public evidence of registration is the ex= istence of a DNS entry, and a NS record is always the first one configured.= =A0

Conclusions
- Unregistered use of any domain name is an at= tack on the architecture of the Internet.
- PSD for DMARC is asking us to give public suffix operators what = they are supposed to already have: =A0 control over unregistered names.
- We should implement new and univer= sal policies:
=A0 =A0 - Unregiste= red names used as SMTP addresses MUST generate SPF FAIL and SHOULD be rejec= ted.

That is certainly a defens= ible assertion, but I would claim it is out of scope for DMARC.=A0 You'= re talking about a detail of SPF or perhaps of SMTP in general, although on= e could also even argue that this is a local policy decision and outside th= e scope of those protocols.=A0 I suspect the SMTP greybeards would claim th= at this is not part of SMTP, but rather an enforcement choice made by imple= mentations.

I believe this falls within the re= alm of what the IETF calls an Applicability Statement, which would be a sta= ndards track document (if you could get consensus for it).=A0 You could als= o include this in the DMARC usage document, or as non-normative advice in D= MARC itself with an explanation of why it's a good idea, if you can dev= elop consensus to do so.

You also need to account = for transient DNS outages.=A0 If your resolver temporarily thinks "gmail.com" doesn't exist, you will b= ounce all mail coming from that domain, and you might seriously piss off yo= ur users.=A0 There's a backscatter problem here too: If I send mail to = a list you're on and you temporarily think my domain doesn't exist = and you bounce mail coming from me, the list will unsubscribe you.

=A0 =A0 - Unregistered names used as message From header addresses MUST= generate DMARC FAIL and SHOULD be rejected.
<= br>
This is more in scope for DMARC discussions, though also argu= ably outside of the protocol itself, for the same reasons.=A0 I would sugge= st that it's a viable discussion for the DMARC usage document, whenever= we get around to working on that again.=A0 But you could certainly test th= e working group opinion on this point.

Protecting the integrity of the name registration system = is not an optional activity to be implemented by a few organizations with t= he most sophisticated implementations of the DMARC specification. =A0 It sh= ould be a mandatory duty of every legitimate participant on the network.
Starting from t= he assumption that unregistered domains might be allowable creates many pro= blems when trying to design solutions for protecting the names that are reg= istered. =A0 This assumption needs to be rejected.
=

These are both probably true statements, but is DMARC t= he right place to wage this battle=3F=A0 For example, isn't it also tru= e for TCP connections for which PTR records make false claims (or no claim)= =3F

Addressing some straw-man questions:
Q: =A0The idea is fine for public suffixes, but my orga= nization doesn't need to do that for subdomains under its control.
A: =A0Every level of the DNS tree nee= ds coordination of name usage. =A0 =A0Publishing an NS record for an organi= zation subdomain proves that the organization's process has been follow= ed. =A0 Besides, the boundary between public suffixes and organizational do= mains is imprecise, so recipients cannot be expected to apply differential = expectations.

I still don't unde= rstand what the presence or absence of NS tells you that the presence or ab= sence of MX/A/AAAA doesn't.=A0 If you have a message that fails the lat= ter test but passes the former, does that change your handling decision=3F= =A0 If not, why do it=3F

<= div class=3D"gmail=5Fquote">
Q. How do we get all i= ncoming filters to change to default block for unregistered domain names=3F=
A.=A0 I would suggest using the CVE/CC= E process.

That seems like a bi= g hammer, and certainly outside of the IETF's purview.=A0 We're not= the protocol police.=A0 You might try having this discussion in a context = like M3AAWG though; many large operators congregate there to discuss stuff = like this.

-MSK
--472d6a6269ed4665ad7bf6da33a6086a-- --15c6bc21cfad4a32adcb2021868ffffa-- From nobody Sat Nov 21 13:33:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CE93A0E09 for ; Sat, 21 Nov 2020 13:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.345 X-Spam-Level: X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DRUGS_ERECTILE=1.994, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 8FCJj-LY8miW for ; Sat, 21 Nov 2020 13:32:58 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 290D13A0E07 for ; Sat, 21 Nov 2020 13:32:57 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id l11so6828763plt.1 for ; Sat, 21 Nov 2020 13:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=YgdLbrbWy1tAW2zyNu3U0QaOtE+htVH0a9GR81eRbQ4=; b=upsheV/GNDlawbzKhA+3vd9eNZ6baNHom7NPBcDZxS/wpipyDgKwkRltTonGfgnwbV c+CxMYYKGh/cfyaAe8FDJAdtsiSPkZQ6u1bIs6HimWsfcAgeSSyHZJjOqv8zuPiuOivK gTJqXoYo6gVDTYlbx/y4N7SSPoJkt2JErrJ7ppXstX6gqGwcIwSZ4VS07HzLADyVNwAx 9W0yriQ5PucssgcJzxsvErNJqDXXf9rGKi5+wgjgkC7Jz+utq5wBzMK7VG8Jf/R0/XX8 Hi8WgEZGegNC852pVh5LkZowU199Tx8RjEpDDaAy0bz5z4VDexupRUbYIlwr1YLbgMLh hQAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=YgdLbrbWy1tAW2zyNu3U0QaOtE+htVH0a9GR81eRbQ4=; b=UMheBqXzkW+9HAdewRNEYQrORBoR/5XF3Lbzx7PtXD+aA2rvpwAOdhw6otHQBwNuq0 wIv8omUuXd4KMZ/pFuHWRXU846f3588uvUy2DnwcYmjER5HFz6fJIFJnGM/bAqAY4Kac nKMhHYkX9m9vwayjhQii/YB/cxG/2izPKd9J1gfVX5gq6cWweqCOaqF478kWZ7STz3TN uOi8jddEsDc3Jx5jL+MAYZzrixgwjMD9F8irpjrx0nA4bWoRPiImZr6amLyoH06m+flV hCZee6BuFCaJHpQ0gERnjcYQ5hx27/V6NvIjkxqaIGy18O6gqiJWOVJ4jjD8hEZF7UM3 L6uw== X-Gm-Message-State: AOAM531gp9JyY89DegGGjYO5aCm0N5zYCqMkToVZS2lg8AgAcxxrwVD2 h5qFSLu39A8JFMla+1W6seumf6ytrIhWRg== X-Google-Smtp-Source: ABdhPJzkS8C/2Hl3d80AIsMBNckAw7xFegSiYR962Ep1eKBzNfwedEzTPJ+ScDGUlK8jQQ2I4PnFUQ== X-Received: by 2002:a17:902:b209:b029:d8:e7a4:bf10 with SMTP id t9-20020a170902b209b02900d8e7a4bf10mr18745185plr.77.1605994376888; Sat, 21 Nov 2020 13:32:56 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id y81sm8080650pfc.25.2020.11.21.13.32.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Nov 2020 13:32:56 -0800 (PST) To: dmarc@ietf.org From: Michael Thomas Message-ID: Date: Sat, 21 Nov 2020 13:32:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2020 21:33:00 -0000 Hi all, long time. I finally read through the ARC spec after seeing it accidentally in mail headers wondering what it was, especially since it was so DKIM like. My barely informed take is that it allows intermediaries to say "this is what it looked like to me at this point [and before i messed it]". So far, so good. It seems that a receiver can then verify that the ARC signature especially if the "original" DKIM signature is broken. So far, so good again. If I'm a receiver who is going to be making some filtering decisions based on ARC, I see that it passed by some authenticator along the way which is fine, but my question is why I should trust that intermediary in general? I mean, this is easy if it's gmail since I know google has an interest in good email practices out of band, but what if the ARC signer is actually an attacker that I have no idea who they are? Which is to say, how do I go about trusting the ARC signer to not be doing something bad? I don't have a specific attack in mind (still too new to this), but say if spam.com ARC signs a message it adulters to its advantage how do I know that I should disregard its ARC results? Or maybe not so much disregard results per se, but not want to "accept" the changes to the original message? Ok, maybe here is an attack. Suppose this message is scrapped by a spammer since this is a public email list. It has a broken original DKIM signature but a valid ARC signature from ietf.org. The attacker takes the message, adds the Viagra scams in the body to the ARC signed message and reinjects the new message toward the targets of their choice (? mailing list members only? not sure). Or did I miss where ARC resigns the body? Or is there a tie in for ARC with the mailing list's resigned DKIM signature for the new message? Sorry so many questions, and probably misunderstanding what's going on. Mike From nobody Sat Nov 21 15:12:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAD73A0992 for ; Sat, 21 Nov 2020 15:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5zIvfdmtUzi for ; Sat, 21 Nov 2020 15:12:34 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7218C3A0991 for ; Sat, 21 Nov 2020 15:12:34 -0800 (PST) X-ASG-Debug-ID: 1606000348-11fa313c0128540001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id HyGGM9asIXPZBxhV (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 21 Nov 2020 18:12:29 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=ugb+59zLRk0SxzBa+s8qGHNk08bbTLW+FN8bJLQ/oYc=; b=HTclz90SKaZViiC6I7LiXXHCg12isEQpW3QjGbgnzqlrWCVDwYiojcpCiwD1EN/00 CR2w19gMbEvtaJg1BhhTnMZ5Dg51BOecnQWBHvwVxhL06RfBHEfy87PX1v301joDq LU6RHD822xgZw9W69geF73QmHfo9GalOcXAtILoYo= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 21 Nov 2020 18:12:22 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Reply-To: fosterd@bayviewphysicians.com Message-ID: <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=bdb369a70840487b874da643964f1745 In-Reply-To: References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> X-Exim-Id: 52963338956e4396b746beccd2f0b78f X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606000349 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 20595 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86032 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Nov 2020 23:12:37 -0000 This is a multipart message in MIME format. --bdb369a70840487b874da643964f1745 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What are the complications to DMARC of tolerating unregistered domains=3F - If unregistered domains are tolerated, PSD for DMARC helps address the pr= oblem of a unauthorized domains underneath a public suffix, such as "exampl= e.uk". But what DMARC policy will solve the problem of an invalid TLD, suc= h as "example.q"=3F - If unregistered domains are tolerated, then a limited-scope tree walk bec= omes unusable. A spammer would be able to fabricate a few levels of non-= existent subdomains, and suddenly PayPal.com becomes a domain tree with no = detectable DMARC policy. Besides, a scope-limited tree walk conflicts wit= h the requirements of PSD for DMARC. An unlimited-scope tree walk has per= formance risks to both the evaluator and the DNS infrastructure. Doug Foster ---------------------------------------- From: "Murray S. Kucherawy" Sent: 11/21/20 2:12 PM To: Doug Foster Cc: Doug Foster , IETF DM= ARC WG Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster wrote: Restating what we all know: - The Internet is dependent on the reliable operation of the DNS name syste= m. - The DNS name system is dependent on the reliable operation of the name re= gistration processes. - The registrars are given ownership of all unregistered domain names withi= n their portion of the hierarchy. - The public evidence of registration is the existence of a DNS entry, and = a NS record is always the first one configured. Conclusions - Unregistered use of any domain name is an attack on the architecture of t= he Internet. - PSD for DMARC is asking us to give public suffix operators what they are = supposed to already have: control over unregistered names. - We should implement new and universal policies:- Unregistered names used = as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected. That is certainly a defensible assertion, but I would claim it is out of sc= ope for DMARC. You're talking about a detail of SPF or perhaps of SMTP in = general, although one could also even argue that this is a local policy dec= ision and outside the scope of those protocols. I suspect the SMTP greybea= rds would claim that this is not part of SMTP, but rather an enforcement ch= oice made by implementations. I believe this falls within the realm of what the IETF calls an Applicabili= ty Statement, which would be a standards track document (if you could get c= onsensus for it). You could also include this in the DMARC usage document,= or as non-normative advice in DMARC itself with an explanation of why it's= a good idea, if you can develop consensus to do so. You also need to account for transient DNS outages. If your resolver tempo= rarily thinks "gmail.com" doesn't exist, you will bounce all mail coming fr= om that domain, and you might seriously piss off your users. There's a bac= kscatter problem here too: If I send mail to a list you're on and you tempo= rarily think my domain doesn't exist and you bounce mail coming from me, th= e list will unsubscribe you. - Unregistered names used as message From header addresses MUST generate DM= ARC FAIL and SHOULD be rejected. This is more in scope for DMARC discussions, though also arguably outside o= f the protocol itself, for the same reasons. I would suggest that it's a v= iable discussion for the DMARC usage document, whenever we get around to wo= rking on that again. But you could certainly test the working group opinio= n on this point. Protecting the integrity of the name registration system is not an optional= activity to be implemented by a few organizations with the most sophistica= ted implementations of the DMARC specification. It should be a mandatory = duty of every legitimate participant on the network. Starting from the assumption that unregistered domains might be allowable c= reates many problems when trying to design solutions for protecting the nam= es that are registered. This assumption needs to be rejected. These are both probably true statements, but is DMARC the right place to wa= ge this battle=3F For example, isn't it also true for TCP connections for = which PTR records make false claims (or no claim)=3F Addressing some straw-man questions: Q: The idea is fine for public suffixes, but my organization doesn't need = to do that for subdomains under its control. A: Every level of the DNS tree needs coordination of name usage. Publis= hing an NS record for an organization subdomain proves that the organizatio= n's process has been followed. Besides, the boundary between public suffi= xes and organizational domains is imprecise, so recipients cannot be expect= ed to apply differential expectations. I still don't understand what the presence or absence of NS tells you that = the presence or absence of MX/A/AAAA doesn't. If you have a message that f= ails the latter test but passes the former, does that change your handling = decision=3F If not, why do it=3F Q. How do we get all incoming filters to change to default block for unregi= stered domain names=3F A. I would suggest using the CVE/CCE process. That seems like a big hammer, and certainly outside of the IETF's purview. = We're not the protocol police. You might try having this discussion in a = context like M3AAWG though; many large operators congregate there to discus= s stuff like this. -MSK --bdb369a70840487b874da643964f1745 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What are the complications to DMARC= of tolerating unregistered domains=3F

- If unregistered domains are tolerated, PSD for DMARC helps addr= ess the problem of a unauthorized domains underneath a public suffix, such = as "example.uk".  But what DMARC policy will solve the problem of an i= nvalid TLD, such as "example.q"=3F

- If unregistered domains are tolerated, then a limited-scope tree = walk becomes unusable.   A spammer would be able to  fabricate a = few levels of non-existent subdomains, and suddenly PayPal.com becomes a do= main tree with no detectable DMARC policy.   Besides, a scope-limited = tree walk conflicts with the requirements of PSD for DMARC.   An unlim= ited-scope tree walk has performance risks to both the evaluator and the DN= S infrastructure.

Doug Foster=





From: "Murray S. Kucherawy" <superuser@gma= il.com>
Sent: 11/21/20 2:12 PM
To: Doug Foster <fosterd@bayviewph= ysicians.com>
Cc: Doug Foster <fosterd=3D40bayviewphysicians.com@dm= arc.ietf.org>, IETF DMARC WG <dmarc@ietf.org>
Subject: Re: [dmar= c-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
=

On Sat, Nov 21, 2020 at= 9:02 AM Douglas E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
Restating what we all know:
- The Internet is dependent on th= e reliable operation of the DNS name system.
- The DNS name sy= stem is dependent on the reliable operation of the name registration proces= ses.
- The registrars are given ownership of all unregistered = domain names within their portion of the hierarchy.
- The publ= ic evidence of registration is the existence of a DNS entry, and a NS recor= d is always the first one configured. 

Conclusions
- Unregistered use of any domain name is an att= ack on the architecture of the Internet.
- PSD for DMARC is as= king us to give public suffix operators what they are supposed to already h= ave:   control over unregistered names.
- We should imple= ment new and universal policies:
    - Unregistered = names used as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected.=

That is c= ertainly a defensible assertion, but I would claim it is out of scope for D= MARC.  You're talking about a detail of SPF or perhaps of SMTP in gene= ral, although one could also even argue that this is a local policy decisio= n and outside the scope of those protocols.  I suspect the SMTP greybe= ards would claim that this is not part of SMTP, but rather an enforcement c= hoice made by implementations.



    = - Unregistered names used as message From header addresses MUST generate DM= ARC FAIL and SHOULD be rejected.



These are both probably true statements, but is DMARC the righ= t place to wage this battle=3F  For example, isn't it also true for TC= P connections for which PTR records make false claims (or no claim)=3F

Addressing some straw-man ques= tions:
Q:  The idea is fine for public suffixes, but my o= rganization doesn't need to do that for subdomains under its control.
=
A:  Every level of the DNS tree needs coordination of name usa= ge.    Publishing an NS record for an organization subdomain prov= es that the organization's process has been followed.   Besides, the b= oundary between public suffixes and organizational domains is imprecise, so= recipients cannot be expected to apply differential expectations.

I sti= ll don't understand what the presence or absence of NS tells you that the p= resence or absence of MX/A/AAAA doesn't.  If you have a message that f= ails the latter test but passes the former, does that change your handling = decision=3F  If not, why do it=3F

--bdb369a70840487b874da643964f1745-- From nobody Sat Nov 21 16:56:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9DD3A0A49 for ; Sat, 21 Nov 2020 16:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsfJLP1xG4WO for ; Sat, 21 Nov 2020 16:56:24 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 E1A3F3A0A3E for ; Sat, 21 Nov 2020 16:56:23 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id h185so7216253vsc.3 for ; Sat, 21 Nov 2020 16:56:23 -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=dBtVRbXt+lRW1ns7UIS35vGP7E1Pu4Rz17vLD36oQPE=; b=ipm1tMHrSICqX3ajzP+00Cnv05c6435F/nVyE2vdJ2ezBG+koP5geJD3JbSlzgmm9X bQ6+Koo9gkjdnQbJlViZqxMlJfbmiCC/O8Ir7Qpp34Kdy38t859qFSZ++O7gGZQSDJP1 deKvxe8ZtSyDhlrcx2uZldqbLSZRZ5Tw8Jrdjql/R5u5bWZEPMTpLxsvD0m4yzrFEm2a CyHFcEQKV93eeRh9qjNSy1ZvzUDIZ63U7uglnHh3Pze5JVC5H9XOG0xjkph+apdLaD7G dzYCSvOQCdCK1ShYrNGJFAsvR1NKsG/FHeiCd1ocVdjC8iYSYfc4jVMuDJF3uOV3SHrw qF3Q== 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=dBtVRbXt+lRW1ns7UIS35vGP7E1Pu4Rz17vLD36oQPE=; b=Zx4cIerAG/Tdo7XhUfGhIumf6TruiAfkg4NH9hljYUrftHF/NngDR5ffeINKh3N8Aj oU76LQ8nDfhmjBf6r5RARcqJe23gKH+qxr3Ig9lYpKHNM1XUakLEzYsNpbl29BWK0cNA u63cz96LTRaAHa89xVaunfkwDNwTCHbjuYOGGLQSO/f5Ay2yiuptwZdj2AdkyZWn8/PR sHIUtq/k2/pne1Qa896Xjq2LAThZyF8G2a18J1xXw9x/jFjZWJ0KLqJXrTniuu+gJHnd jtGRzQ1jJ3qW9HXEkOjMeKcmbO7aOTj1Q5AyuwNnZmUqnGkfpmY7vZiytmKWCXE/jPR+ ASmw== X-Gm-Message-State: AOAM530hN1/GRSTdQlLLFmLdtFXH5l0PEQzaPcaZpKnmcpEOztpHhOxE /xOVLmoyAvGyissKNpp+svyTdL59CBAmCgxZSp065zxe X-Google-Smtp-Source: ABdhPJwAO40YfErRd8xT+nY7iH8z10DAm+sJ32R9lx4yx+qB1fAH53dAY37w0Yk4Bmb+4QHDAaStx2qHyWYd1oBj6us= X-Received: by 2002:a67:783:: with SMTP id 125mr16466960vsh.15.1606006582539; Sat, 21 Nov 2020 16:56:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 21 Nov 2020 16:56:08 -0800 Message-ID: To: "Douglas E. Foster" Cc: Doug Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000dbfa9a05b4a78b9c" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 00:56:25 -0000 --000000000000dbfa9a05b4a78b9c Content-Type: text/plain; charset="UTF-8" On Sat, Nov 21, 2020 at 11:26 AM Douglas E. Foster < fosterd@bayviewphysicians.com> wrote: > Does a transient outage report NXDOMAIN, or a different status? > Depends on the nature of the outage, I suppose. An unreachable nameserver should typically result in a SERVFAIL, but I can imagine misconfigurations that result in an errant NXDOMAIN. -MSK --000000000000dbfa9a05b4a78b9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does a transient outage report NXDOMAIN, or a different status?
<= /div>

Depends on the nature of the outage, = I suppose.=C2=A0 An unreachable nameserver should typically result in a SER= VFAIL, but I can imagine misconfigurations that result in an errant NXDOMAI= N.

-MSK
--000000000000dbfa9a05b4a78b9c-- From nobody Sat Nov 21 17:03:07 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75CF3A0AA7 for ; Sat, 21 Nov 2020 17:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJVHF_AOkCF8 for ; Sat, 21 Nov 2020 17:03:01 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 69A743A0AA3 for ; Sat, 21 Nov 2020 17:03:01 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id l22so7211175vsa.4 for ; Sat, 21 Nov 2020 17:03:01 -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=0ds2cDVKNXez6U0Q5krZt5Wj11FyBbSLghWjgN5qvU8=; b=OA4uweujraAu4NvVF9oNJvmkioZCBy2LProvC3+BqbksnDICFzeJnCy5YjuwrcwWV0 6sgeTGYAAjEIu/MjwNx8NYRS8zxlTYXT5jKDjPg/mDQnAUvAJ3FsviG92gQWQTp0owVl oV4mFi2w3Jw+JwsBeCAKbyl2CdiPLE6dPiTKD4AF5nJOLy6BLwsG3tNqivX90fzGWq6Q dCc+kJoPdgj0YsIwmU4OsWfOUpagqlv2tSrqBGdJMy16Lri/CQ0JrPAp/P0e18vn+6AE ucsWbM29mzpdkmh9py42XnDDe05ExDXSsGYJucQaGEN0kA1U47xArDEjgukDJwC/bxq9 pFTA== 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=0ds2cDVKNXez6U0Q5krZt5Wj11FyBbSLghWjgN5qvU8=; b=pO0KOlibWJzm9ZPRw+nB5tbT664hioA5r4bVZ7RSEpntPS5zNLQo3/9ulYkZdzDhov GA15FaPzlrA1Wqm6pMSoTPzAQjHz5x1Oo7p4569lffv1Byj+9FNF+mSwRbqTkHvNU/50 dBV/Fu7gDjLI49xBwRR+dNP02USHlXskv8aOSuG0A182a/T526HcsWFxbuMUfh0HFLly CNFwRCo72/BrJEJlAw4t09hkMgBzbB+FHkmYmk2yYDAYrQz3vBpWhLZVHe2YQMVOX/kb 4hfb2AtNLIYK3K3ZJbhgKk5Vh4KgbWlmKT48lL9qCWBas6ocrcY7L47dJe+45QKDId9g eu4w== X-Gm-Message-State: AOAM531Z3rrtxXpQlS/91Vc2GmLKvd4HOefGA8t30WBCiMKlWLykjsZi VgWO2xJzhRJsKK44y6ZgtB1o7aAwrH+n0CLa43/vjC6ar5I= X-Google-Smtp-Source: ABdhPJx7w8vA5WpmPRWJIg4I6NzQzktwlimhyCjooqhf5UCcnyHY0J/xwgMhCElMv2LC6384YVOCUFYKBQOYXTC7vY8= X-Received: by 2002:a67:f1c7:: with SMTP id v7mr1345883vsm.40.1606006980177; Sat, 21 Nov 2020 17:03:00 -0800 (PST) MIME-Version: 1.0 References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> In-Reply-To: <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Sat, 21 Nov 2020 17:02:47 -0800 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008f711a05b4a7a3f6" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 01:03:06 -0000 --0000000000008f711a05b4a7a3f6 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster wrote: > - If unregistered domains are tolerated, PSD for DMARC helps address the > problem of a unauthorized domains underneath a public suffix, such as " > example.uk". But what DMARC policy will solve the problem of an invalid > TLD, such as "example.q"? > Why is this a DMARC problem that needs solving? - If unregistered domains are tolerated, then a limited-scope tree walk > becomes unusable. A spammer would be able to fabricate a few levels of > non-existent subdomains, and suddenly PayPal.com becomes a domain tree with > no detectable DMARC policy. > You're going to have to give us an example of what you're imagining here. Presumably fabricating a few levels of non-existent subdomains of paypal.com would look like foo.bar.baz.paypal.com; a simple tree walk then would be to look for records in these places: foo.bar.baz.paypal.com bar.baz.paypal.com baz.paypal.com paypal.com I would expect a policy to be present at least at "paypal.com", so the walk stops there. How is that "unusable"? The PSL mechanism is a heuristic allowing a short-cut from the top one to the bottom one, so there are only two lookups, based on the PSL which provides a hint about where to jump after the first query. But the PSL has aspects of its management that are not desirable, and the tree walk is an alternative. Besides, a scope-limited tree walk conflicts with the requirements of PSD > for DMARC. > Well sure; as I understand it, a tree walk would obviate the need for PSD. An unlimited-scope tree walk has performance risks to both the evaluator > and the DNS infrastructure. > So the theory goes. I believe what John is saying is that he's asked the DNS community, and they no longer think it's a concern, which means we don't need to worry at least about the latter, and the former is probably at least partially resolved by caching. -MSK --0000000000008f711a05b4a7a3f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 21, 2020 at 3:12 PM Douglas E= . Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrote:
- If unregistered domains are t= olerated, PSD for DMARC helps address the problem of a unauthorized domains= underneath a public suffix, such as "example.uk".=C2=A0 But what DMARC policy will solv= e the problem of an invalid TLD, such as "example.q"?

Why is this a DMARC problem that needs solving?<= br>

=
- If unregistered domains are tolerated, then a limited-scope tre= e walk becomes unusable. =C2=A0 A spammer would be able to =C2=A0fabricate = a few levels of non-existent subdomains, and suddenly PayPal.com becomes a = domain tree with no detectable DMARC policy.
<= br>
You're going to have to give us an example of what you're imag= ining here.=C2=A0 Presumably fabricating a few levels of non-existent subdo= mains of paypal.com would look like foo.bar.baz.paypal.com; a simple t= ree walk then would be to look for records in these places:

foo.bar.baz.paypal.com
=
<= a href=3D"http://paypal.com">paypal.com

I would exp= ect a policy to be present at least at "= paypal.com", so the walk stops there.=C2=A0 How is that "unus= able"?

The PSL mechanism is a heuristic allow= ing a short-cut from the top one to the bottom one, so there are only two l= ookups, based on the PSL which provides a hint about where to jump after th= e first query.=C2=A0 But the PSL has aspects of its management that are not= desirable, and the tree walk is an alternative.

Besides, a scope-= limited tree walk conflicts with the requirements of PSD for DMARC.

Well sure; as I understand it, a tree = walk would obviate the need for PSD.

An unlimited-scope tree walk has= performance risks to both the evaluator and the DNS infrastructure.
<= /div>

So the theory goes.=C2=A0 I believe w= hat John is saying is that he's asked the DNS community, and they no lo= nger think it's a concern, which means we don't need to worry at le= ast about the latter, and the former is probably at least partially resolve= d by caching.

-MSK
--0000000000008f711a05b4a7a3f6-- From nobody Sat Nov 21 17:05:13 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11BA3A0AB7 for ; Sat, 21 Nov 2020 17:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csaDn7A7PgU7 for ; Sat, 21 Nov 2020 17:05:10 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 24B913A0AB6 for ; Sat, 21 Nov 2020 17:05:10 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id r23so4497443uak.0 for ; Sat, 21 Nov 2020 17:05:09 -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=0jT5ouao6GQa9GMRX6Q0i55r5w6I1R7EMgbt1pcUCok=; b=qr/7qro0m1oCgPuphGZ5GouhjSxyIoSyScg8yaowe8SbihhBSh53hs9WuG3iElpvVV pNMUrvqglgV70odLLb0CwJlzaM8NU6TaXw7OZ83d4ucVTD4D+Ui6EAYACQVz05lT+glj 4RBMXD5288dbntSfxeDuOdFFwPF0NLq4qpraZEc1Tg8SyHggiVIN/uZg79YVt5AU6TXl 25QX24ruKT6H38NPZSZ4J8U96BkGVXXQ6o5LIkuNVVeqPpr9/3SvW0BWuCOMq171kidu CCD5Ot+P/wz0YLO7KzWiH3nYm+2D56whmF6+eW55RmzchBXMvmRCYiby9I9kKxOYGhVt v1Tw== 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=0jT5ouao6GQa9GMRX6Q0i55r5w6I1R7EMgbt1pcUCok=; b=hriauAZH7l6YPMzby23fs8YkDV4hnDfdTQoxRMZjTGLEbb3xQAXl3oxN8NJWV9enJf oPvS67BIdza3XSN5YCcVOuSYdDhW9TJ35M5VyKttIIK+pFVXuOIVJuDfuki+JwkWoOep NGoaGiDQpGjbs9CbhKZUC69Xus3xDOiSKVUsO2CpMhMg14zqiSM/m1nEUI3cWEyxBGJ8 3AWNh34vhtfa/3QxrA3q82evwZpsLjkl970HqqYcWpy4kltJJT40xKPP1PTx4Ko4bSY5 LANjaAPWQznGsF9fVdc8pf7eITgjZD6YL7t0EBr2pbXouuR8C3VEV2GIDif6ugNqYO3V KdRQ== X-Gm-Message-State: AOAM530PQYXcBOGEg7hrGjLu+BSJTIQbsc8D4+H48z8jgnaseI9bnhzA pJLEeeyb2QC1N1321vifTxbDn7UWGKsrByT/R00= X-Google-Smtp-Source: ABdhPJwUna8YwVLL7WwEJts4MrKpuCRR7y5YB6UotRdBvaqUkENs4XRtbrIcJc7EXBrKBIkmp21lE7eqEmzP55EQ8sA= X-Received: by 2002:ab0:b3:: with SMTP id 48mr17826784uaj.101.1606007108967; Sat, 21 Nov 2020 17:05:08 -0800 (PST) MIME-Version: 1.0 References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Sat, 21 Nov 2020 17:04:56 -0800 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003ca15d05b4a7abe4" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 01:05:12 -0000 --0000000000003ca15d05b4a7abe4 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy wrote: > On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster 40bayviewphysicians.com@dmarc.ietf.org> wrote: > >> - If unregistered domains are tolerated, PSD for DMARC helps address the >> problem of a unauthorized domains underneath a public suffix, such as " >> example.uk". But what DMARC policy will solve the problem of an invalid >> TLD, such as "example.q"? >> > > Why is this a DMARC problem that needs solving? > > - If unregistered domains are tolerated, then a limited-scope tree walk >> becomes unusable. A spammer would be able to fabricate a few levels of >> non-existent subdomains, and suddenly PayPal.com becomes a domain tree with >> no detectable DMARC policy. >> > > You're going to have to give us an example of what you're imagining here. > Presumably fabricating a few levels of non-existent subdomains of > paypal.com would look like foo.bar.baz.paypal.com; a simple tree walk > then would be to look for records in these places: > > foo.bar.baz.paypal.com > bar.baz.paypal.com > baz.paypal.com > paypal.com > > I would expect a policy to be present at least at "paypal.com", so the > walk stops there. How is that "unusable"? > Someone in DNSOP, I think, proposed doing the tree walk in the other direction. The reason: If you're going to get an NXDOMAIN, it is more likely to come earlier, and it's dispositive that way. For instance, if the above sequence is reversed, you would probably get an NXDOMAIN at the second query ("baz.paypal.com") and then you know you don't need to look any further. -MSK --0000000000003ca15d05b4a7abe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 21, 2020 at 5:02 PM Murray S.= Kucherawy <superuser@gmail.com> wrote:
- If unregistered domains are tolerated, PSD for DMARC helps ad= dress the problem of a unauthorized domains underneath a public suffix, suc= h as "example.uk&q= uot;.=C2=A0 But what DMARC policy will solve the problem of an invalid TLD,= such as "example.q"?

Why i= s this a DMARC problem that needs solving?

- If unregistered doma= ins are tolerated, then a limited-scope tree walk becomes unusable. =C2=A0 = A spammer would be able to =C2=A0fabricate a few levels of non-existent sub= domains, and suddenly PayPal.com becomes a domain tree with no detectable D= MARC policy.

You're going to have to give us an example of what you're imag= ining here.=C2=A0 Presumably fabricating a few levels of non-existent subdo= mains of paypal.com wou= ld look like fo= o.bar.baz.paypal.com; a simple tree walk then would be to look for reco= rds in these places:

<= /div>

Someone in DNSOP, I think, proposed d= oing the tree walk in the other direction.=C2=A0 The reason: If you're = going to get an NXDOMAIN, it is more likely to come earlier, and it's d= ispositive that way.=C2=A0 For instance, if the above sequence is reversed,= you would probably get an NXDOMAIN at the second query ("baz.paypal.com") and then you know you don&#= 39;t need to look any further.

-MSK
--0000000000003ca15d05b4a7abe4-- From nobody Sat Nov 21 17:32:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FD63A0B62 for ; Sat, 21 Nov 2020 17:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnwqGZaBZu1i for ; Sat, 21 Nov 2020 17:32:18 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978D23A0B60 for ; Sat, 21 Nov 2020 17:32:18 -0800 (PST) X-ASG-Debug-ID: 1606008733-11fa313c0128b30001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id wq2wEDVbCmVDx8Vm (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sat, 21 Nov 2020 20:32:13 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=8Ngply0qTZAcGBXTwNLbA5nckqTeOi6alaCeFwfnVuU=; b=SDbhn8KmiiaAlw7rbXR8NNqgbKJAK9bqSzMdbUfM74XpqEwdebHeAh+uF18Kb9y8p fBc2M6zH33kuI73/0zYJZjin+E54Tmg0b6FS58AHHDyqBB6/InYl7nfjmQjQ2Wcok qHsPo9BWAJ60V47OO0ydX2RP4bKv+sooKYGqOEe60= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Sat, 21 Nov 2020 20:32:06 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Reply-To: fosterd@bayviewphysicians.com Message-ID: <1331a357df2645b29f326783bd83a697@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3e7d0500fd8543d893a1b51123d2aa24 In-Reply-To: References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> X-Exim-Id: 1331a357df2645b29f326783bd83a697 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606008733 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 17136 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86034 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 01:32:21 -0000 This is a multipart message in MIME format. --3e7d0500fd8543d893a1b51123d2aa24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am arguing for the position that all unregistered domains are inherently = invalid, because they are not registered. PSD for DMARC proposes that non-existent domains should be blocked. In t= heir discussions, I remember the UK government reporting that they had regi= stered 27,000 domains simply so they could publish SPF -ALL, in an attempt = to block spammers from spoofing their government agencies. I have a probl= em with the definition they chose in their document, but I fully agree that= this is a problem that should be fixed. They have also suggested that their "np" policy has general applicability, = an argument which I find compelling. By "general", I mean non-existent TL= Ds, non-existent public suffixes below the TLD, non-existent organizations,= and non-existent subdomains of organizations. Their experience demonstrates that an undefined domain is very difficult to= protect. .... On tree walk, I was working from John Levine's proposal, which assumes that= a tree walk has to be distance limited for performance reasons. He tenta= tively proposed four levels. If you walk up the tree and find no DMARC en= try, the walk stops with the conclusion that no policy has been issued. T= his approach works if (and only if) the tree exists, so that the organizati= on can place a policy at every fourth level. The approach cannot work if = the tree can be extended with non-existent domains. It also conflicts wi= th the PSD proposal which requires checking the top of the tree structure. I had considered the top-down approach also, for the same reasons as you me= ntioned. I assumed that it would be rejected because of the load placed o= n upper levels of the DNS hierarchy. But when mulling the PSD problem with the tree-walk problem, I realized the= unifying problem in all of these scenarios was unregistered domains. Eve= ntually the problem became further defined as, "Why should unregistered dom= ains be considered acceptable by default, despite a network-wide requiremen= t for all domains to be registered." For the moment, it is a DMARC issue to me because DMARC has accepted the no= tion that unregistered domains are acceptable by default. If that can be = changed, I agree that there are other documents that need to be updated as = well. DF ---------------------------------------- From: "Murray S. Kucherawy" Sent: 11/21/20 8:05 PM To: Doug Foster Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition = of NP On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy w= rote: On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster wrote: - If unregistered domains are tolerated, PSD for DMARC helps address the pr= oblem of a unauthorized domains underneath a public suffix, such as "exampl= e.uk". But what DMARC policy will solve the problem of an invalid TLD, suc= h as "example.q"=3F Why is this a DMARC problem that needs solving=3F - If unregistered domains are tolerated, then a limited-scope tree walk bec= omes unusable. A spammer would be able to fabricate a few levels of non-= existent subdomains, and suddenly PayPal.com becomes a domain tree with no = detectable DMARC policy. You're going to have to give us an example of what you're imagining here. = Presumably fabricating a few levels of non-existent subdomains of paypal.co= m would look like foo.bar.baz.paypal.com; a simple tree walk then would be = to look for records in these places: foo.bar.baz.paypal.com bar.baz.paypal.com baz.paypal.com paypal.com I would expect a policy to be present at least at "paypal.com", so the walk= stops there. How is that "unusable"=3F Someone in DNSOP, I think, proposed doing the tree walk in the other direct= ion. The reason: If you're going to get an NXDOMAIN, it is more likely to = come earlier, and it's dispositive that way. For instance, if the above se= quence is reversed, you would probably get an NXDOMAIN at the second query = ("baz.paypal.com") and then you know you don't need to look any further. -MSK --3e7d0500fd8543d893a1b51123d2aa24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am arguing for the position that = all unregistered domains are inherently invalid, because they are not regis= tered.
<= br fr-original-style=3D"" style=3D"box-sizing: border-box;">
PSD for DMARC proposes= that non-existent domains should be blocked.    In their discuss= ions, I remember the UK government reporting that they had registered 27,00= 0 domains simply so they could publish SPF -ALL, in an attempt to block spa= mmers from spoofing their government agencies.   I have a problem with= the definition they chose in their document, but I fully agree that this i= s a problem that should be fixed.

They have also suggested that their "np" policy has general applicabil= ity, an argument which I find compelling.   By "general", I mean non-e= xistent TLDs, non-existent public suffixes below the TLD, non-existent orga= nizations, and non-existent subdomains of organizations.

Their experience demonstrates that an undefine= d domain is very difficult to protect.
....

On tree walk, I was working from John Levine's proposal, which assu= mes that a tree walk has to be distance limited for performance reasons. &n= bsp; He tentatively proposed four levels.   If you walk up the tree an= d find no DMARC entry, the walk stops with the conclusion that no policy ha= s been issued.   This approach works if (and only if) the tree exists,= so that the organization can place a policy at every fourth level.   = The approach cannot work if the tree can be extended with non-existent doma= ins.    It also conflicts with the PSD proposal which requires ch= ecking the top of the tree structure.

I had considered the top-down approach also, for the same reasons = as you mentioned.   I assumed that it would be rejected because of the= load placed on upper levels of the DNS hierarchy.

But when mulling the PSD problem with the tree-walk p= roblem, I realized the unifying problem in all of these scenarios was unreg= istered domains.   Eventually the problem became further defined as, "= Why should unregistered domains be considered acceptable by default, despit= e a network-wide requirement for all domains to be registered."

For the moment, it is a DMARC issue to m= e because DMARC has accepted the notion that unregistered domains are accep= table by default.   If that can be changed, I agree that there are oth= er documents that need to be updated as well.

DF

=
From: "Murray S= . Kucherawy" <superuser@gmail.com>
Sent: 11/21/20 8:05 PM
To: Dou= g Foster <fosterd@bayviewphysicians.com>
Cc: "dmarc@ietf.org" <d= marc@ietf.org>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dm= arc-psd: Definition of NP

On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org>= wrote:
=
- If unregistered = domains are tolerated, PSD for DMARC helps address the problem of a unautho= rized domains underneath a public suffix, such as "example.uk= ".  But what DMARC policy will solve the problem of an invalid TLD, su= ch as "example.q"=3F

Why is this a DMARC problem that needs solving=3F

- If unr= egistered domains are tolerated, then a limited-scope tree walk becomes unu= sable.   A spammer would be able to  fabricate a few levels of no= n-existent subdomains, and suddenly PayPal.com becomes a domain tree with n= o detectable DMARC policy.

You're going to have to give us an example of what you're imagining h= ere.  Presumably fabricating a few levels of non-existent subdomains o= f paypal.com would look like foo.bar.= baz.paypal.com; a simple tree walk then would be to look for records in= these places:
=

I would expect a policy to be present at least at "= paypal.com", so the walk stops there.  How is that "unusable"=3F

Someo= ne in DNSOP, I think, proposed doing the tree walk in the other direction. =  The reason: If you're going to get an NXDOMAIN, it is more likely to = come earlier, and it's dispositive that way.  For instance, if the abo= ve sequence is reversed, you would probably get an NXDOMAIN at the second q= uery ("baz.paypal.com") and then you know you don't need = to look any further.

<= /div>
-MSK
--3e7d0500fd8543d893a1b51123d2aa24-- From nobody Sat Nov 21 18:14:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042573A0C3F for ; Sat, 21 Nov 2020 18:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=m/kjyELD; dkim=pass (2048-bit key) header.d=taugh.com header.b=ZMmf6Fq7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb7AjqlaYTja for ; Sat, 21 Nov 2020 18:14:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC273A0C38 for ; Sat, 21 Nov 2020 18:14:20 -0800 (PST) Received: (qmail 21600 invoked from network); 22 Nov 2020 02:14:18 -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:cleverness; s=545e.5fb9c97a.k2011; bh=52PlwGT2bfgBMl5uOKDGbvErcGpAKz6EPfw0rQyzHdU=; b=m/kjyELDcz+e3a3Uq3sjh2rTtSX8cZas4b6tZRUE9poKMgXT/JhXQ+X/ZZxvAw3RP5iEV7y5IOpAn1uIf5KUEHtnkbvWb5ufQH8/a5NVAuARCyjShMv/C8ZrQITjxejmpUlXCyLdaCX4BY+JBPMR7oF4dVIl0YopPgtcBXM3SPG/pYKP5M+MFJkC8DVvzvNPuoX8PH+8myrOlxfymVJO/sw0i4+T1FCTscNnlNLIStqakVYyzOVgncaSMpepqqK9p998la4OkXU5I/xlnuA+WW0A3AYpfh4R4AA9xrIAVorGji4kVO7vvRW4vDH/v8GcaME9hukTjLvQ02t4J62dCg== 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:cleverness; s=545e.5fb9c97a.k2011; bh=52PlwGT2bfgBMl5uOKDGbvErcGpAKz6EPfw0rQyzHdU=; b=ZMmf6Fq7X2Tr/OUrltzFZT/LlAZyK2lIOHRydbcgfXJEatryPyDssDKmXlUlfvYkiI1xeEbI93Up+gyhJ6PHIoz0rjfpTfuZKY5ywkW+YcZoiqPNAJWRhWtfIrDo55ImrllZCr046HdfNlhPISlwmLbR7Rvn/mnNU9xVMeeYEjxCdixLAngoaJvtiMZgVwa/Ni2cuSuCEsB32sZrGraQ/sMDZdLa7UADKxOUwps/hSb2BIrJdhDKaKx7G0b0Ooa8zG4jO+GG2UNiKz7nrjcKpj6eRajzA8qykXCbBn5mJwyMiwUyPMtAIiq+v7g3tlLZoH73QNssmSiwi80WzzdaPg== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Nov 2020 02:14:18 -0000 Received: by ary.qy (Postfix, from userid 501) id B5E6E27B3E59; Sat, 21 Nov 2020 21:14:17 -0500 (EST) Date: 21 Nov 2020 21:14:17 -0500 Message-Id: <20201122021417.B5E6E27B3E59@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 02:14:23 -0000 In article you write: >If I'm a receiver who is going to be making some filtering decisions >based on ARC, I see that it passed by some authenticator along the way >which is fine, but my question is why I should trust that intermediary >in general? The short answer is that you shouldn't, any more than you should trust random DKIM signatures. When people were designing ARC, it seemd overcomplicated to me. Large mail systems know where all the mailing lists are so why not just whitelist them and be done with it? The answer is that legit lists leak a lot of spam and it is common for a formerly well-behaved list to start spewing spam. Most lists do little filtering beyond verifying that the From: address is a subscriber, so when a spambot steals an address book that contains both the list address and some subscribers to that list, a lot of spam leaks through. ARC lets recipient systems do retroactive filtering that the forwarding system didn't. For example, although the overall error rate of rejecting mail due to SPF -all or DMARC p=reject can be high, on incoming mail to mailing lists both are quite reliable since the kind of forwarding that breaks them is rare in that context. If I ever get around to adding ARC checks to my filters, that's the sort of thing I'll be looking for. This also means that ARC isn't useful if you don't have a reputation system to tell you where the lists and other forwarders that might add legit ARC signatures are. There's been some handwaving about how we might come up with shared DNSWLs of mailing list hosts, but it hasn't happened yet. R's, John From nobody Sat Nov 21 18:23:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9B3A0C77 for ; Sat, 21 Nov 2020 18:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=iecc.com header.b=gN36HmUi; dkim=pass (2048-bit key) header.d=taugh.com header.b=a/LpcnXL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aijj3uvK3MIp for ; Sat, 21 Nov 2020 18:23:49 -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 187743A0C6B for ; Sat, 21 Nov 2020 18:23:48 -0800 (PST) Received: (qmail 22810 invoked from network); 22 Nov 2020 02:23:47 -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:cleverness; s=5918.5fb9cbb3.k2011; bh=JgU+U7wrFBBRQlJy0wXY/b7+kEW1sLjB17uayA8uVDw=; b=gN36HmUi6gMkTpFgdGRfq3ARuNXGecGnAIsJSbiGUbwZJT5659qi1ysw1m8G3Rhz6xtk1v+54SUcGrpCOrO2IetKh/RqsHP3JAdMstjDRD+7gbnRS3Y83BRDP3Sp4BVXfyucPCOF8KGFpt6tC+ScSBLIrysrOecbBn8gUV/IUQyPtq1N9yfoLjB3UEFA7T5TRuO0NEqfLU+4ADgDmKNLrI0awiccANQzhZwMpU2NiQtU7NpMWUzwxuPcQFzy4yCBxrHxmxnYNaRffvbSGFwWigej6yBvHHouEB8RrS05n+YbsQqLdzIOwiRcoK/lIbXp840yzPVTuD1K9ogwOoGR5g== 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:cleverness; s=5918.5fb9cbb3.k2011; bh=JgU+U7wrFBBRQlJy0wXY/b7+kEW1sLjB17uayA8uVDw=; b=a/LpcnXLLqPelAQhqcJB4CPGnLizbNG7zd2Q13WJxqyW6cSeVKGkjPa2NkO0rH3EK3ykqhKWKGoo/ZT5DY0+l+CtAxGZpUUaolyEfNBhud7GRmVqXAhrZK9Yb04YbjWE6kDJclENOeAL9vrvKnroVsfr02BZdTbjDrgG+sgvkjD8FJtjlOwWuKzTnI/C2Su+weQGqG6zx5G2VqBfnw/3Lzr2UDkUQG7iXCaqFEPSJf5qsc7l5z8n2ux4TMH+OtKBqLiHq/8+ytfOBLf36oRzePvXe7Hv7hjNYH5vPNCQUtvRBL9SX5kdbMZc7kICsLaoR2usDDvLQOVF2avxbhKWlQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Nov 2020 02:23:47 -0000 Received: by ary.qy (Postfix, from userid 501) id C039627B3EF9; Sat, 21 Nov 2020 21:23:46 -0500 (EST) Date: 21 Nov 2020 21:23:46 -0500 Message-Id: <20201122022346.C039627B3EF9@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 02:23:51 -0000 In article you write: >Someone in DNSOP, I think, proposed doing the tree walk in the other >direction. Turns out that won't work because here's what you'd be checking: > _dmarc.paypal.com > _dmarc.baz.paypal.com > _dmarc.bar.baz.paypal.com > _dmarc.foo.bar.baz.paypal.com You can have a NXDOMAIN at _dmarc.paypal.com but a TXT record at _dmarc.bar.baz.paypal.com. You could certainly add heuristics and check plain baz.paypal.com to see if it gives you an NXDOMAIN stop but I have no reason to think that on average it'd actually save queries. It is my impression that most real From: domains are pretty short. I don't think I've ever seen one more than four labels long that wasn't deliberately contrived. Anyone got data on that? R's, John root@18.183.57.64.in-addr.arpa From nobody Sat Nov 21 21:59:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFAE3A10AA for ; Sat, 21 Nov 2020 21:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3nEp8zP42nX for ; Sat, 21 Nov 2020 21:59:20 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 A835D3A10A9 for ; Sat, 21 Nov 2020 21:59:20 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id r23so4612432uak.0 for ; Sat, 21 Nov 2020 21:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C/APZWUr2y8trYeAByArDvlouGrJAP7/HMtE585x4QA=; b=DVRRfY9sQB2+ZWSCsB5pbSOHaUCSrHc0h5ANVz0SKjy1jrifUJ0V3Qi9RyyjA0PYed xEfPzW2knYCLQnoki2ZVIIKmmBk26n1whmBRwLPsK6Tt7BzGzB9cx16v+579VI/aH0SV tjE6n76pbBOqy+sk6ELfvXQYM4IgoDVC2m6F7mkaksqOOJMcHafKmxwKKAd9/cQNLddt bUIlfvWStegCxb9o2VcAg7aqJrb0b8rmWLFYRmQtnRBEzyrz4zlsmCcYxp7fTyoRDkr3 KebTOP6J/ONww664wvhcZV0P+/+4gzT6BBNWciX37I5KAb/vFi6cRQ77yTmmxrtMxgcp HRgA== 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=C/APZWUr2y8trYeAByArDvlouGrJAP7/HMtE585x4QA=; b=ozd0fBpVeQoasYAcb/R9pPU0G9YsCUCvMJ8KRo6HIr4wevCi5Tbdaf0sOgSDsMYFCV WaFoBDRsA5g4HHDFiOJ6OdF/FjZTSlkTtp7XHguKW84koOe41412laEX/5PsXopxaFx9 DbYAmQNH9xnwE7MZIgf5M3bFz0gLQdtdPpyO8idrtEvbTYVShtMYqobGboV7l3ReTsHA BvxLdVWqiM7ykNS2Io6Ka/hiQD0SmfFbMuq0k2yWye8fd7AouWlhbz5/8zmz4RdSxXG7 x0Wx0ZI5bZUAaR6Mu938RnH1j7G7h5FGw8R/y5KzBF/eKROXfvNXx1ou44RZq7CCLucQ 059A== X-Gm-Message-State: AOAM5304leIgiMLFfJqBV9hsyVxfF+9H2vYPZ/KVueRIUUHEYbkpFH7q PyVHz/khCYy+dI+li+nHVPFL7f2ScaQ10S1F4acal+Nr X-Google-Smtp-Source: ABdhPJy9BbPXYWlh2JyPMXfC+nTSscLJKfxuNL1WEJGmDFn2+qcS4oRUEExasGfPlAb4BIInb4qyNlPphEBq9GyooI4= X-Received: by 2002:ab0:2e9:: with SMTP id 96mr4909829uah.87.1606024759415; Sat, 21 Nov 2020 21:59:19 -0800 (PST) MIME-Version: 1.0 References: <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <20201120040420.B3F4727A02FB@ary.qy> <553D43C8D961C14BB27C614AC48FC03128116528@UMECHPA7D.easf.csd.disa.mil> <000001d6bf45$0f62cc30$2e286490$@bayviewphysicians.com> <52963338956e4396b746beccd2f0b78f@bayviewphysicians.com> <1331a357df2645b29f326783bd83a697@bayviewphysicians.com> In-Reply-To: <1331a357df2645b29f326783bd83a697@bayviewphysicians.com> From: "Murray S. Kucherawy" Date: Sat, 21 Nov 2020 21:59:06 -0800 Message-ID: To: Doug Foster Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000491af205b4abc772" Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 05:59:23 -0000 --000000000000491af205b4abc772 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 21, 2020 at 5:32 PM Douglas E. Foster wrote: > On tree walk, I was working from John Levine's proposal, which assumes > that a tree walk has to be distance limited for performance reasons. He > tentatively proposed four levels. If you walk up the tree and find no > DMARC entry, the walk stops with the conclusion that no policy has been > issued. This approach works if (and only if) the tree exists, so that the > organization can place a policy at every fourth level. The approach > cannot work if the tree can be extended with non-existent domains. It > also conflicts with the PSD proposal which requires checking the top of the > tree structure. > What does "extended with non-existent domains" mean in the context of a tree walk? You're going to have to give an example. I had considered the top-down approach also, for the same reasons as you > mentioned. I assumed that it would be rejected because of the load placed > on upper levels of the DNS hierarchy. > It strikes me that the infrastructure near the root of the tree is likely very robust compared to that at many leaf nodes. For the moment, it is a DMARC issue to me because DMARC has accepted the > notion that unregistered domains are acceptable by default. If that can > be changed, I agree that there are other documents that need to be updated > as well. > I think that assertion goes too far. As I recall, DMARC doesn't claim that unregistered domains are acceptable by default. Rather, it cannot make an assertion about a domain for which a policy cannot be found. That's certainly true of an unregistered domain. DMARC follows DKIM and SPF in this regard; they can only make assertions about a message when the parts fall into place. When they don't, none of those protocols can form a conclusion. That's different from deciding something is "acceptable". In any case, it's unclear to me whether "bounce/discard anything from a domain that appears not to exist" fits inside DMARC. If you believe the entire ecosystem should be doing this, not just DMARC-aware operators, then I suggest these are the wrong documents in which to push for it. -MSK --000000000000491af205b4abc772 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 21, 2020 at 5:32 PM Douglas E= . Foster <fosterd=3D40bayviewphysicians.com@dmarc.ietf.org> wrot= e:
On tree walk, I was working from John Levine's proposal, which as= sumes that a tree walk has to be distance limited for performance reasons. = =C2=A0 He tentatively proposed four levels. =C2=A0 If you walk up the tree = and find no DMARC entry, the walk stops with the conclusion that no policy = has been issued. =C2=A0 This approach works if (and only if) the tree exist= s, so that the organization can place a policy at every fourth level. =C2= =A0 The approach cannot work if the tree can be extended with non-existent = domains. =C2=A0 =C2=A0It also conflicts with the PSD proposal which require= s checking the top of the tree structure.

=
What does "extended with non-existent domains" mean in the c= ontext of a tree walk?=C2=A0 You're going to have to give an example.

<= div style=3D"font-family:arial;font-size:14px">
I had considered the top-down approach also, for the same reasons = as you mentioned. =C2=A0 I assumed that it would be rejected because of the= load placed on upper levels of the DNS hierarchy.
=

It strikes me that the infrastructure near the root of = the tree is likely very robust compared to that at many leaf nodes.

For the moment, it is a DMARC issue t= o me because DMARC has accepted the notion that unregistered domains are ac= ceptable by default. =C2=A0 If that can be changed, I agree that there are = other documents that need to be updated as well.
I think that assertion goes too far.=C2=A0 As I recall, DMARC d= oesn't claim that unregistered domains are acceptable by default.=C2=A0= Rather, it cannot make an assertion about a domain for which a policy cann= ot be found.=C2=A0 That's certainly true of an unregistered domain.=C2= =A0 DMARC follows DKIM and SPF in this regard; they can only make assertion= s about a message when the parts fall into place.=C2=A0 When they don't= , none of those protocols can form a conclusion.=C2=A0 That's different= from deciding something is "acceptable".

In = any case, it's unclear to me whether "bounce/discard anything from= a domain that appears not to exist" fits inside DMARC.=C2=A0 If you b= elieve the entire ecosystem should be doing this, not just DMARC-aware oper= ators, then I suggest these are the wrong documents in which to push for it= .

=
-MSK
--000000000000491af205b4abc772-- From nobody Sat Nov 21 22:07:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549343A10D4 for ; Sat, 21 Nov 2020 22:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N00LeXKU5JOr for ; Sat, 21 Nov 2020 22:07:11 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 8CC4C3A10D2 for ; Sat, 21 Nov 2020 22:07:10 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id u24so7366100vsl.9 for ; Sat, 21 Nov 2020 22:07:10 -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=O2B0aWanuGNuEfPnP0jGrFNWvqa4oIFSWYCFyM9KvIM=; b=IzlEOsxV6VQG6m5oVOaRSTcBGXn1yfXgMXPdN+q86lxZUwDMkeJIX0uceMMW+kZUSE KU0cYfFZf1+AEC42XtlKl2H7Oo6zBAdZJwZbbpy56VKwUarsTxGHursfSJEmIAIZlRq4 xthkhdlPgXseNwcl5ZS0Nhh4NCcBmF3RWBRgdMxY1Nt1i5OkHOZ1eJWTrHx8vfwQ9r+q EJn+Jl/9kbVQCcK6A1A3JNwd4slQNtjSWZJ9zSHijRdEhEA1x6A/Y2jHd46Frux9PZcS FwfZgTtijoz+4wvzGWctQtmjoi6lHhIrXjMiFZgePe0qIebYm60/wVerQNJNFXr62yfq nIBQ== 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=O2B0aWanuGNuEfPnP0jGrFNWvqa4oIFSWYCFyM9KvIM=; b=lLg/fDwDqxAQ90+UrpHJmedVzfwzJSCGM1XGOLcoPy/5UQGmJuwUmMl0Px014nNffc STOx4ulwyM5EtVAi1DizNO5alVzX6WGpbJ05zJnlwrGgfPszyzKnjGLAaoPCUjdsUZD1 mJEmZ4BQAIIXyHjCfCoWgLhZVi2lbnRDZhBqYL1kgBpxuNdZGF8nzJjtkXsvHDQjhDZA PASa7lJEEUzVuTfy6qAUFmzUUpCwH3Ggm5noAuJojOJ6SIKnvtXO1WRmNmgE7D9RfeGX vnOdM5iFfoCB3TZVbsjq6z/NMjQhHyX+AshLM1vKLqnZNRqFkHtKU6Z1/4/MfSJekECx 36sw== X-Gm-Message-State: AOAM532ecGF4YA3JP8J2IURGocESgAkWpQtdNUcWBIKq5Jn+2Xl7fN/7 hXULqu4EGW9IIOWYNW1kFNKn2iSZLH0eoQvmXPZFRDcy X-Google-Smtp-Source: ABdhPJwa3rkYliMdRk6qjn3bYGNXmmulNHWbrfuxjVQbiusrQcLRoD9jHvV57m8Ze1TNct4Wo4871QtNeWXowquTdcg= X-Received: by 2002:a67:f7c8:: with SMTP id a8mr15391281vsp.54.1606025229183; Sat, 21 Nov 2020 22:07:09 -0800 (PST) MIME-Version: 1.0 References: <20201122022346.C039627B3EF9@ary.qy> In-Reply-To: <20201122022346.C039627B3EF9@ary.qy> From: "Murray S. Kucherawy" Date: Sat, 21 Nov 2020 22:06:56 -0800 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000492ecc05b4abe368" Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 06:07:13 -0000 --000000000000492ecc05b4abe368 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 21, 2020 at 6:23 PM John Levine wrote: > It is my impression that most real From: domains are pretty short. I > don't think I've ever seen one more than four labels long that wasn't > deliberately contrived. Anyone got data on that? > I'd bet there are some in .gov or .mil, especially the latter, but otherwise I think the longest one I've seen is five, and that was not a host that receives mail. I'm sure we can all scrape our own mail logs for evidence either way. -MSK --000000000000492ecc05b4abe368 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 21, 2020 at 6:23 PM John Levi= ne <johnl@taugh.com> wrote:
It is my impression that most real From: domains are pretty shor= t. I
don't think I've ever seen one more than four labels long that wasn= 't
deliberately contrived. Anyone got data on that?

<= /div>
I'd bet there are some in .gov or .mil, especially the latter= , but otherwise I think the longest one I've seen is five, and that was= not a host that receives mail.

I'm sure we ca= n all scrape our own mail logs for evidence either way.

<= /div>
-MSK
--000000000000492ecc05b4abe368-- From nobody Sun Nov 22 03:02:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B993A1403 for ; Sun, 22 Nov 2020 03:02:40 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i71Kx9tECdJU for ; Sun, 22 Nov 2020 03:02:38 -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 0F3843A1341 for ; Sun, 22 Nov 2020 03:02:37 -0800 (PST) Received: (qmail 23650 invoked by uid 100); 22 Nov 2020 11:02:36 -0000 Date: 22 Nov 2020 11:00:57 -0000 Message-ID: <20201122110057.23150.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 22 06:02:35 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 11:02:41 -0000 Count | Bytes | Who ------------+----------------+------- 13 (21.3%) | 122003 (18.5%) | Murray S. Kucherawy 10 (16.4%) | 208118 (31.5%) | Doug Foster 8 (13.1%) | 39471 ( 6.0%) | John Levine 6 ( 9.8%) | 105091 (15.9%) | Todd Herr 4 ( 6.6%) | 13999 ( 2.1%) | Dave Crocker 3 ( 4.9%) | 22124 ( 3.4%) | Kurt Andersen (b) 3 ( 4.9%) | 20923 ( 3.2%) | Chudow, Eric B CIV NSA DSAW (USA) 3 ( 4.9%) | 18496 ( 2.8%) | Alessandro Vesely 2 ( 3.3%) | 39866 ( 6.0%) | Tim Wicinski 2 ( 3.3%) | 14037 ( 2.1%) | Jim Fenton 1 ( 1.6%) | 16436 ( 2.5%) | Craig Schwartz 1 ( 1.6%) | 7830 ( 1.2%) | Dotzero 1 ( 1.6%) | 7693 ( 1.2%) | Dale R. Worley 1 ( 1.6%) | 6556 ( 1.0%) | Gene Hightower 1 ( 1.6%) | 6531 ( 1.0%) | Michael Thomas 1 ( 1.6%) | 6485 ( 1.0%) | Alwin de Bruin 1 ( 1.6%) | 4404 ( 0.7%) | Gren Elliot From nobody Sun Nov 22 10:42:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8D3A09C0 for ; Sun, 22 Nov 2020 10:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s97Lk0LAw8yd for ; Sun, 22 Nov 2020 10:42:13 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 225053A09C1 for ; Sun, 22 Nov 2020 10:42:12 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id r17so1878962ilo.11 for ; Sun, 22 Nov 2020 10:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HA9di1VkNpxlR+w9KTw+1wFImid5hKqWJ31E0zhOX+o=; b=gWmEfv41mk6Gqggxm2rOfbbXFk43hObOG4t84Iargz2BJx6TdqKwa6UnnykEBNlGyU cX5I6H5d9NBk556Z378nTGJc7EzVSUbS7VX/0vTcDiIFnxV9I8hkiSSkJp7xWcfXKMWh UqM7JiDtbkmoCsK68wcVDEsWF+VcKVKsqkeC8= 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=HA9di1VkNpxlR+w9KTw+1wFImid5hKqWJ31E0zhOX+o=; b=ZM/ssfIWBtHaTBvnNiyJM5B2NzJ1V5ENjxoe2LTFkYHHsp2P5JlpjKj1bt0uZW6Ldo SweH+fwTqzZfzvgKdzINj14OIRnpo26HHeegnrO6oVruUmSdYHMOdOLcfYn/dAvWbqtF 38tn2vzmIgCfkq1BjBgDhChx90II9+rxikXF4D7xB/0p2M0URQsiaFzEUJIdJEQMagbw 83E7q4o96nvqYSFhpSgXubyZLeAxtglTyf+cnChEDhDwJX763fDrLUV91I9qFsI9rw94 f08NfsX4+vOc5TbCwuSPTr4u2/63LR7P7QyT17d/ZPukS5lB3k3/kiZm7G8iWK50Frlf OMXA== X-Gm-Message-State: AOAM530pZwhXbeVBFyexuU0I50Bg/aJbYrKRR4kVnvJe9F+tOd5fy01E BvnyW1oTpTn5xBwctyxBifxmBrv+u8DvTmfYemDZnA== X-Google-Smtp-Source: ABdhPJzrFEINjh5jAYBvM/EypUEJg6KaRoiIZnVLSDWUTwsZPKT1KdO/7ggVVmtbz+nuh0YBVxP8q8USJAbwSX5NuU0= X-Received: by 2002:a92:3f0f:: with SMTP id m15mr8652599ila.103.1606070527835; Sun, 22 Nov 2020 10:42:07 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> In-Reply-To: <20201122021417.B5E6E27B3E59@ary.qy> From: "Kurt Andersen (b)" Date: Sun, 22 Nov 2020 11:41:56 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , mike@mtcc.com Content-Type: multipart/alternative; boundary="000000000000535fb705b4b66f01" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 18:42:15 -0000 --000000000000535fb705b4b66f01 Content-Type: text/plain; charset="UTF-8" As usual, John has pretty well nailed the response, but there was one other part of your question (Mike) that I thought deserved explanation: On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > In article you write: > >If I'm a receiver who is going to be making some filtering decisions > >based on ARC, I see that it passed by some authenticator along the way > >which is fine, but my question is why I should trust that intermediary > >in general? > > The short answer is that you shouldn't, any more than you should trust > random DKIM signatures. > > This also means that ARC isn't useful if you don't have a reputation > system to tell you where the lists and other forwarders that might add > legit ARC signatures are. > On Sat, Nov 21, 2020 at 2:33 PM Michael Thomas wrote: > > Or did I miss where ARC resigns the body? Or is there a tie in for ARC > with the mailing list's resigned DKIM signature for the new message? > The ARC-Message-Signature (referred to as the AMS) includes a signature over the newly modified message (headers & body) in a way very similar to a DKIM-Signature. But this does not solve the problem of a malicious forwarder that does a wholesale replacement of the (presumably) good content with spam. That's were your own reputation and content analysis has to come in. --Kurt --000000000000535fb705b4b66f01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As usual, John has pretty well nailed the= response, but there was one other part of your question (Mike) that I thou= ght deserved explanation:

On Sat, Nov 21, 2020 at 7:14 PM John Levine <johnl@taugh.com> wrote:
In article <dcc2= 65f9-a143-5093-eba0-94ee059c7cc7@mtcc.com> you write:
>If I'm a receiver who is going to be making some filtering decision= s
>based on ARC, I see that it passed by some authenticator along the way =
>which is fine, but my question is why I should trust that intermediary =
>in general?

The short answer is that you shouldn't, any more than you should trust<= br> random DKIM signatures.

This also means that ARC isn't useful if you don't have a reputatio= n
system to tell you where the lists and other forwarders that might add
legit ARC signatures are.=C2=A0

On Sat, Nov 21, 2020 at 2:33 PM Michael Thomas &l= t;mike@mtcc.com> wrote:

Or did I miss where ARC= resigns the body? Or is there a tie in for ARC
with the mailing list's resigned DKIM signature for the new message?

The ARC-Message-Signature (referred to as= the AMS) includes a signature over the newly modified message (headers &am= p; body) in a way very similar to a DKIM-Signature. But this does not solve= the problem of a malicious forwarder that does a wholesale replacement of = the (presumably) good content with spam. That's were your own reputatio= n and content analysis has to come in.

--Kurt=C2= =A0
=C2=A0
--000000000000535fb705b4b66f01-- From nobody Sun Nov 22 10:51:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A793B3A09EB for ; Sun, 22 Nov 2020 10:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 Vpg2fdMTx5T7 for ; Sun, 22 Nov 2020 10:50:59 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 4291F3A09EA for ; Sun, 22 Nov 2020 10:50:59 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id s63so2277838pgc.8 for ; Sun, 22 Nov 2020 10:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=fhdAcVE7u8XPxfSXbei/fzoBum10RPVat4HUCSQOQdQ=; b=vEq6aNj0dBpXoAFhPHOR2ZnrgjRq4Lr5Ls3tjz8umz0s+xYFq0wjbVHRt6MrrFa/kS UZ9wJWRoGo7KzuZCiyWh6X7mXkO7UaD5vGAMl+2zsJWjjAjR2YNxqhsmFWagDwBNz6bU xWqA0RKcLvO+/gXV1zth5QEJ8mnXDegIzqypKaKjjlzAgLQLom+6nHW8D2q37QFQ++Ti NBy25pUgePXUfNlwUxcx0dNAA05V/yknRoujxrVVLmsgSuJ/tSGPgo+1oZ/GCO4g49EG yLJ3Vnpp88cvgOKhqPG8t7cYAj6akIJE+k5p0j78q3fOrYbBTWDXofUG0ZxlL6tGLp/V wg2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=fhdAcVE7u8XPxfSXbei/fzoBum10RPVat4HUCSQOQdQ=; b=jhSU3WmYcxcJoHW9F5A1rRwr+Cdj5Iic7CSeerCMmOiCBUZtr/prtc5K7YBDqvdDfF LgY3+RjtS+fnkAcR39xOz3DHCpJMCp9wQnaYZk1eNgZ/ux1xhajTyhHv3qojaT50+eDz KRTjEDXi8fULNt0h/K7/BPtTsM1JpI64gRSSAshvpbAVnZ3GABX71sft67Cuv8o+PK4G fZjgsDExHYE+Ml2O7Xy8H9Hg3EFA6cP2jcS+PJn2JxenFyUz55D1OCnUKt42BBLgbgBG C0IiFPZ7elIGor/35jK5vYtSbLqMyAgFFYYdQVZKNjc0k9pLK3XD+ej2eQI73jZdIAPz +/Iw== X-Gm-Message-State: AOAM5325L7zX7vGQmL2ZpfmytUZWjhK0AI7jocpU9XVSSHVhU1/RAx7v xFA+fTcnUvhl4rp3WYzpsAbBse5ooWzM7A== X-Google-Smtp-Source: ABdhPJyqWDG5fhPGfwE5mL0DKpfiC2iloU3/7MCrfH1eMn+Vmv+icBwD86eVqTjO46BQtfClxsLI0Q== X-Received: by 2002:a17:90a:4497:: with SMTP id t23mr20999627pjg.39.1606071058192; Sun, 22 Nov 2020 10:50:58 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id c191sm9647084pfc.166.2020.11.22.10.50.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Nov 2020 10:50:57 -0800 (PST) To: "Kurt Andersen (b)" , John Levine Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> From: Michael Thomas Message-ID: <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> Date: Sun, 22 Nov 2020 10:50:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------163CE033ED04755FAC7F93A0" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 18:51:01 -0000 This is a multi-part message in MIME format. --------------163CE033ED04755FAC7F93A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/22/20 10:41 AM, Kurt Andersen (b) wrote: > As usual, John has pretty well nailed the response, but there was one > other part of your question (Mike) that I thought deserved explanation: > > On Sat, Nov 21, 2020 at 7:14 PM John Levine > wrote: > > In article > you write: > >If I'm a receiver who is going to be making some filtering decisions > >based on ARC, I see that it passed by some authenticator along > the way > >which is fine, but my question is why I should trust that > intermediary > >in general? > > The short answer is that you shouldn't, any more than you should trust > random DKIM signatures. > > This also means that ARC isn't useful if you don't have a reputation > system to tell you where the lists and other forwarders that might add > legit ARC signatures are. > > > On Sat, Nov 21, 2020 at 2:33 PM Michael Thomas > wrote: > > > Or did I miss where ARC resigns the body? Or is there a tie in for > ARC > with the mailing list's resigned DKIM signature for the new message? > > > The ARC-Message-Signature (referred to as the AMS) includes a > signature over the newly modified message (headers & body) in a way > very similar to a DKIM-Signature. But this does not solve the problem > of a malicious forwarder that does a wholesale replacement of the > (presumably) good content with spam. That's were your own reputation > and content analysis has to come in. > Is there a reason that there is a separate ARC-signature rather than just using the DKIM signature that is normally created for the new message? Since ARC is new, you'd not want the intermediary to stop DKIM signing the message so you end up with essentially two signatures doing essentially the same thing? Mike --------------163CE033ED04755FAC7F93A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/22/20 10:41 AM, Kurt Andersen (b) wrote:
As usual, John has pretty well nailed the response, but there was one other part of your question (Mike) that I thought deserved explanation:

On Sat, Nov 21, 2020 at 7:14 PM John Levine <johnl@taugh.com> wrote:
In article <dcc265f9-a143-5093-eba0-94ee059c7cc7@mtcc.com> you write:
>If I'm a receiver who is going to be making some filtering decisions
>based on ARC, I see that it passed by some authenticator along the way
>which is fine, but my question is why I should trust that intermediary
>in general?

The short answer is that you shouldn't, any more than you should trust
random DKIM signatures.

This also means that ARC isn't useful if you don't have a reputation
system to tell you where the lists and other forwarders that might add
legit ARC signatures are. 

On Sat, Nov 21, 2020 at 2:33 PM Michael Thomas <mike@mtcc.com> wrote:

Or did I miss where ARC resigns the body? Or is there a tie in for ARC
with the mailing list's resigned DKIM signature for the new message?

The ARC-Message-Signature (referred to as the AMS) includes a signature over the newly modified message (headers & body) in a way very similar to a DKIM-Signature. But this does not solve the problem of a malicious forwarder that does a wholesale replacement of the (presumably) good content with spam. That's were your own reputation and content analysis has to come in.

Is there a reason that there is a separate ARC-signature rather than just using the DKIM signature that is normally created for the new message? Since ARC is new, you'd not want the intermediary to stop DKIM signing the message so you end up with essentially two signatures doing essentially the same thing?

Mike

--------------163CE033ED04755FAC7F93A0-- From nobody Sun Nov 22 11:14:09 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5597B3A0AD8 for ; Sun, 22 Nov 2020 11:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=RUuYkT2/; dkim=pass (2048-bit key) header.d=taugh.com header.b=lu59KnXR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUTULtIA9_lq for ; Sun, 22 Nov 2020 11:14: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 3ACF33A0AC6 for ; Sun, 22 Nov 2020 11:14:05 -0800 (PST) Received: (qmail 16714 invoked from network); 22 Nov 2020 19:14:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=4148.5fbab87c.k2011; i=johnl-iecc.com@submit.iecc.com; bh=GLZN2iJBH2F86w1rf8AB8lxIxJvZ0PGBtzzXRlcXWbs=; b=RUuYkT2/diCDy6Yk06AmvObcmyNicTcOb4djYJThKHSoFKt04Zri0ttLB99nriIGcBHcKHGV0EjDbYAM9OvtmNdFWf8T4Qqdw1cMQeJ9OGZskJD5Jqn62LlJgyGyu2cvCh6J7/FMlxaE+dzkibYCvwOwC6WD28aS4+GNPgZZCuEBLsY/xcm2dzU7ES12rDOuKP2lc2I0VS/B36uwpPOY6SazYES0/nCaWndvz8ecByne+Ds8mbcv3ZAk7v3UVu7b5jXNe6HgXtGbWc8b0oj0YBTZetxvPOFqAx3NbphRIr8Ibxe4ad3XKpjKMYBiKMaHac7AdhAl90+78wyfp+Xt6w== 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; s=4148.5fbab87c.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=GLZN2iJBH2F86w1rf8AB8lxIxJvZ0PGBtzzXRlcXWbs=; b=lu59KnXRi7hcmpaOgkB1t7GIKf6ro0jorYUrIzqiJpTfS9l+MLz6BU3+bMidlNiNaO4k4GwVPGQr50TOt4BUMmsazQHgEkc3YzP3Z/+PrNrBtZZoHN8V1BNz0PY6YMKTDyDvxOrywLus8vnW6IAMN73xas2UBP6HnYZ+WVNw5jMsQ/oJFZ7odOU0lUeS40BI//LUyuZ8bj9vSJhRi6Lporu8v0tEK5xPNg60XiaeQqaKnfrpAQ8iUBa4aYFlvqYsoGalsO5qghtz8LTXOqJVlhuaUGUHhz4J2C6RjqoOrEfvUThvZYty8s3awbpi0tLoRp2TMa5Tb4yNYHprk0wegg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 Nov 2020 19:14:04 -0000 Date: 22 Nov 2020 14:14:04 -0500 Message-ID: <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> From: "John R Levine" To: "Michael Thomas" , "Kurt Andersen (b)" Cc: "dmarc@ietf.org" In-Reply-To: <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:14:08 -0000 > Is there a reason that there is a separate ARC-signature rather than just > using the DKIM signature that is normally created for the new message? Since > ARC is new, you'd not want the intermediary to stop DKIM signing the message > so you end up with essentially two signatures doing essentially the same > thing? The ARC signature has a sequence number so you can track the chain of custody. You are right that it is similar to the DKIM signature but the extra ovehead doesn't seem excessive. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Nov 22 11:19:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E153A0AF1 for ; Sun, 22 Nov 2020 11:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnCNVdRT--99 for ; Sun, 22 Nov 2020 11:18:57 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25883A0AEE for ; Sun, 22 Nov 2020 11:18:56 -0800 (PST) X-ASG-Debug-ID: 1606072735-11fa313c012bc50001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 9kU9jH1BTTT4juXN (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 22 Nov 2020 14:18:55 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=oKgKSkeexsc7nLyELU4UgFDJNEZbUyNDbCtIq8oIcfM=; b=kdAlurxUiN3IIC+CcRZqxE72wsGoYrazjzc0/O9GLl6ud+OARUSDqKOi9e5hDH7oo QQ9/kcr/0l4QpGtio+GXqpC7uFkOoJmJXvHM/a1AlUIPgCpFZOAOcfU+93w47g/xQ 7EOK92ktgSowwvxwFyfy5YozRKYqcHf+zsh1MJPKY= Received: by webmail.bayviewphysicians.com via HTTP; Sun, 22 Nov 2020 14:18:46 -0500 To: IETF DMARC WG Date: Sun, 22 Nov 2020 14:18:44 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] ARC questions Message-ID: <2d4e1d382d8c4f669a15267d8877d65d@com> MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=2b35cce13c3b428aa89c01182bf4714c SavedFromEmail: fosterd@bayviewphysicians.com Importance: normal From: "Douglas E. Foster" X-Exim-Id: 2d4e1d382d8c4f669a15267d8877d65d X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606072735 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 3378 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86052 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:18:59 -0000 This is a multipart message in MIME format. --2b35cce13c3b428aa89c01182bf4714c Content-Type: multipart/alternative; boundary=168186a6cd894e51af699de2f9a6e90b --168186a6cd894e51af699de2f9a6e90b Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ARC has a very limited set of items included in the signature.=A0 =A0Body h= ash is purposefully excluded.=A0 So it is the same signature algorithm but = with different parameters and a different purpose.=A0 Therefore it has a di= fferent header label .Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
=
From: John R Levine
Date: 11/22/20 2:14 = PM (GMT-05:00)
To: Michael Thomas , "Kurt Anders= en (b)"
Cc: dmarc@ietf.org
Subject= : Re: [dmarc-ietf] ARC questions
> Is there a reason that there is a separate ARC-signature rather tha= n just > using the DKIM signature that is normally created for the new message=3F = Since > ARC is new, you'd not want the intermediary to stop DKIM signing the mess= age > so you end up with essentially two signatures doing essentially the same > thing=3F The ARC signature has a sequence number so you can track the chain of custody. You are right that it is similar to the DKIM signature but the extra ovehead doesn't seem excessive. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --168186a6cd894e51af699de2f9a6e90b Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ARC has a very limite= d set of items included in the signature.   Body hash is purposef= ully excluded.  So it is the same signature algorithm but with differe= nt parameters and a different purpose.  Therefore it has a different h= eader label .


=
Sent from my Verizon, Samsung Galaxy smartphone<= /div>



-------- Original message --------
From: J= ohn R Levine <johnl@taugh.com>
Date: 11/22/20 2:14 PM (G= MT-05:00)
To: Michael Thomas <mike@mtcc.com>, "Kurt Anders= en (b)" <kboth@drkurt.com>
Cc: dmarc@ietf.org
S= ubject: Re: [dmarc-ietf] ARC questions

> Is there a = reason that there is a separate ARC-signature rather than just
> usin= g the DKIM signature that is normally created for the new message=3F Since =
> ARC is new, you'd not want the intermediary to stop DKIM signing th= e message
> so you end up with essentially two signatures doing essen= tially the same
> thing=3F

The ARC signature has a sequence nu= mber so you can track the chain of
custody. You are right that it is s= imilar to the DKIM signature but the
extra ovehead doesn't seem excessi= ve.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, = Trumansburg NY
Please consider the environment before reading this e-mai= l. https://jl.ly

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
dmarc mailing list
dmarc@ietf.org
https://www.ietf= .org/mailman/listinfo/dmarc

--168186a6cd894e51af699de2f9a6e90b-- --2b35cce13c3b428aa89c01182bf4714c-- From nobody Sun Nov 22 11:29:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFAD3A0B15 for ; Sun, 22 Nov 2020 11:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 Ej8XFygKoDjA for ; Sun, 22 Nov 2020 11:29:29 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DAE3A0B12 for ; Sun, 22 Nov 2020 11:29:29 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id n137so2813999pfd.3 for ; Sun, 22 Nov 2020 11:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=LlIzTFLCLL5iIuRhglkyjtbOO96RK/WjRKn5xG292KM=; b=WKcmMLSbrevVDxvSYwQd+vVcP5MQpFr7FuDnQm/7aXa6E0pp2X97MQAl81DnM/NMOH 5n/aBASVrxJ/uL5XX1xcnQYAcde08r5ty4EhAWFKP4dN4oRkHipkB8eqUOVVq/rwTbCV k3wCsxQabKMsrTsupFQRZswv601OqpeYXeht49waON09hjnQoJpADSrWDBZAtIzkOnYx ki530KRNE3rlOTA76k9//zt+Xt2FMLWueJ+m1l4MANPY0y1DqTDf4UE6/w1VWa2ZWXVk 1gancJtpV4iaXvsh456GxAcdwP4EocyvAupx+JFDtsvlam0c0kiNcNU6U8pF4vI4Adr2 zypA== 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-transfer-encoding :content-language; bh=LlIzTFLCLL5iIuRhglkyjtbOO96RK/WjRKn5xG292KM=; b=ELlOsZLF5kW1fDRwk8wS2xu6DXJ/GnMR3W87Japyao2fw//MxkBZwJoulV0Cbe89pd s10UB75+WWN/0PRJDGfqdvDGbcv+M/N9OHjLLqQHY8rhw6dg8EAyDpxIqdrk32cUHeHf xtMyAxNRPBVc6SSTXEy01xR3nIh2xO51A4P9C/WwXPt4x1FJrBPQxhWc5kcC48vEEHTF 1hexSk9LYFTGlG60OT1OJuEVnQLCNRwhHJHFj6TNxqw3m5EDaee4NEe699PqfZ6gBF03 yzpqUzlj+xq15Gs9kn9yc52AZOfmiqW8XT9bWq/IwDkZnUT3HcnBgZVqhLPGHkbZ3M9J pdEQ== X-Gm-Message-State: AOAM530xl5wQVnhAG7KTPpAGvK0USFRt/SoW+9PMR4IJ1HmygHPVLMPG +uyv3OncIr5ISKNiNDgGR4JpQnQOPS3efg== X-Google-Smtp-Source: ABdhPJz4gRFR9omcfq8JDA/LtBKjW7eGde80d5Hi3yaymZlpTs36iGty/MfMf6jhILQgWxe1FGrtEg== X-Received: by 2002:a63:3845:: with SMTP id h5mr23119183pgn.405.1606073368505; Sun, 22 Nov 2020 11:29:28 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id v7sm9489067pfu.39.2020.11.22.11.29.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Nov 2020 11:29:27 -0800 (PST) To: John R Levine , "Kurt Andersen (b)" Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> From: Michael Thomas Message-ID: <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> Date: Sun, 22 Nov 2020 11:29:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:29:31 -0000 On 11/22/20 11:14 AM, John R Levine wrote: >> Is there a reason that there is a separate ARC-signature rather than >> just using the DKIM signature that is normally created for the new >> message? Since ARC is new, you'd not want the intermediary to stop >> DKIM signing the message so you end up with essentially two >> signatures doing essentially the same thing? > > The ARC signature has a sequence number so you can track the chain of > custody.  You are right that it is similar to the DKIM signature but > the extra ovehead doesn't seem excessive. > Did the wg consider just grafting that onto the DKIM signature itself instead of having essentially a duplicate signature? Receivers are already supposed to ignore any tags they don't understand so it shouldn't hurt backward compatibility. Mike From nobody Sun Nov 22 11:31:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471CE3A0B1A for ; Sun, 22 Nov 2020 11:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 lgraVUZcuZUX for ; Sun, 22 Nov 2020 11:31:26 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D673A0B18 for ; Sun, 22 Nov 2020 11:31:26 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id v12so12825753pfm.13 for ; Sun, 22 Nov 2020 11:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=sM9PCp8nLoIBrd6R6Hh8N2n+ZusjATDrU0xt+4Cpy0U=; b=1ktSbf4iLch0ScFaM+pB46U0AbUD+ks1BbZo9SrCFxGfZ5Oa99kJ7WfqIvYF7IY+nj rfrDyJLdAXam7WhwGjHYkjkKpGjAh+Z9euykoVTwtNpJsfb1TodvYcm3ERm3KEr+0bDx 9obJvYo1pgu3OBvRRYMmGodRY9WtNtwsoAiRS1/c4WactNXWwrbrBNKHPGQpeysqecmz okvJPSwbmAOUXDfavqL0EkRY4kZ3LZ1whyEOhd8u+5TMd6dw2Bj/7U8SPj/VwzccovSE RUT2Acq3wrdrXoajOgfhVfKKwxCE8+2lKmCsbex7f4MRfaSdr4UJOZsLHsRIPL0VAQDm dmRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=sM9PCp8nLoIBrd6R6Hh8N2n+ZusjATDrU0xt+4Cpy0U=; b=IAHMPlYSlIEeDAFj8+j3geUCOEvECYU3FgQhPx8nrZDKwcX2tLn66gzXmDMlhkEgNS aC8rWig28sgz5hMzBGX4qFhcG8YPaxhrTFNuYWZVvBaZcjPSDCuEr/jf6KfQU8yWI4e4 DbZoyh4V0PHXDRaw/VEfAtJY9lfaOoK6A7r5Ia+U4BzT7yAM7kgChCr3Fwjim8e1jHZv BQHMPe3ABS0ChaLj2lOxp9vLJs1zPQw1VmZ1rzp85OIcqfjeO7ghNc4u7n4JP01vuPQv Cotnr87U0PehnCPbtLfHHJKKAAf2Eu6hdMknVstbdi+iGeIDQM1hehiPTBXgkRGjVBWc gcgA== X-Gm-Message-State: AOAM533Cg0tD478ZKognUw3fwlzko2LASXeOt7QTxbJhmCkKNADgmMnW fVzrsxcNOPnMv4Mgymg4fZGuDI/agQ178Q== X-Google-Smtp-Source: ABdhPJzzh9k6xAJe0kHS5jLYW5HOgPwS13jscIcBNDvW4BTwO0tXUvGZAsz2yD7LhxecDb09JmTY8w== X-Received: by 2002:a17:90a:a781:: with SMTP id f1mr22446791pjq.50.1606073485678; Sun, 22 Nov 2020 11:31:25 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id u20sm8748869pgo.22.2020.11.22.11.31.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Nov 2020 11:31:25 -0800 (PST) To: dmarc@ietf.org References: <2d4e1d382d8c4f669a15267d8877d65d@com> From: Michael Thomas Message-ID: Date: Sun, 22 Nov 2020 11:31:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <2d4e1d382d8c4f669a15267d8877d65d@com> Content-Type: multipart/alternative; boundary="------------9A46B1CCAF42C34F96044102" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:31:28 -0000 This is a multi-part message in MIME format. --------------9A46B1CCAF42C34F96044102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 11/22/20 11:18 AM, Douglas E. Foster wrote: > ARC has a very limited set of items included in the signature. Body > hash is purposefully excluded. So it is the same signature algorithm > but with different parameters and a different purpose. Therefore it > has a different header label . Now wait, Kurt just said that the body hash is included. Somebody has to be wrong here. Mike > > > Sent from my Verizon, Samsung Galaxy smartphone > > > > -------- Original message -------- > From: John R Levine > Date: 11/22/20 2:14 PM (GMT-05:00) > To: Michael Thomas , "Kurt Andersen (b)" > > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] ARC questions > > > Is there a reason that there is a separate ARC-signature rather than > just > > using the DKIM signature that is normally created for the new > message? Since > > ARC is new, you'd not want the intermediary to stop DKIM signing the > message > > so you end up with essentially two signatures doing essentially the > same > > thing? > > The ARC signature has a sequence number so you can track the chain of > custody. You are right that it is similar to the DKIM signature but the > extra ovehead doesn't seem excessive. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------9A46B1CCAF42C34F96044102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit


On 11/22/20 11:18 AM, Douglas E. Foster wrote:
ARC has a very limited set of items included in the signature. Body hash is purposefully excluded. So it is the same signature algorithm but with different parameters and a different purpose. Therefore it has a different header label .


Now wait, Kurt just said that the body hash is included. Somebody has to be wrong here.

Mike




Sent from my Verizon, Samsung Galaxy smartphone



-------- Original message --------
From: John R Levine <johnl@taugh.com>
Date: 11/22/20 2:14 PM (GMT-05:00)
To: Michael Thomas <mike@mtcc.com>, "Kurt Andersen (b)" <kboth@drkurt.com>
Subject: Re: [dmarc-ietf] ARC questions

> Is there a reason that there is a separate ARC-signature rather than just
> using the DKIM signature that is normally created for the new message? Since
> ARC is new, you'd not want the intermediary to stop DKIM signing the message
> so you end up with essentially two signatures doing essentially the same
> thing?

The ARC signature has a sequence number so you can track the chain of
custody. You are right that it is similar to the DKIM signature but the
extra ovehead doesn't seem excessive.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--------------9A46B1CCAF42C34F96044102-- From nobody Sun Nov 22 11:56:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A433A0BD7 for ; Sun, 22 Nov 2020 11:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=WNM7/Cac; dkim=pass (2048-bit key) header.d=taugh.com header.b=N/gVwD7W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rf-Sbax5pUT for ; Sun, 22 Nov 2020 11:56:25 -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 27DC83A0BC6 for ; Sun, 22 Nov 2020 11:56:24 -0800 (PST) Received: (qmail 23883 invoked from network); 22 Nov 2020 19:56:23 -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; s=5d48.5fbac267.k2011; i=johnl-iecc.com@submit.iecc.com; bh=hlDf6Du7ZB20XIkm+OpC3DQ5Lv/A+/lBVMXPU+EUKmM=; b=WNM7/CaczGoYr7tmb2I54PBLuG2WZ4ADt94u7FxLcREUjar+i8gvKrUn0iMdqP9D7fNFMFBiF72RA2bQuSe4HrBh8DzJc1UBirOKGAKnQrOJn4Q2eiASUp1lYDkzmwqIgy4/oXgrTNBwN3zQa0K2UI2aSdCbra/HJekXSuXzN6WmJUGtJ/gDwqRRHKFsYdLK2her4r87YuMW3PwYysIFAWR9Opk5ETR5SY8qULPDYkf8+HaOsywFyqjY1S0pu8V+y9qxIRds5ycb+svDqXOm7NuTF4OwA/YuetvIboAbyNc/wwfPDUfDNZr4oXri5vX/co3TlP45UDp+mprT4M8C8g== 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; s=5d48.5fbac267.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=hlDf6Du7ZB20XIkm+OpC3DQ5Lv/A+/lBVMXPU+EUKmM=; b=N/gVwD7WjdO5no7UbhRQIPTKcjEztxxTHz2SIdFHZqYw8JDZPlBKO9kwRdmnKPB6BtYzgpeap8NV62Y1JDkLuC10sT4HHCUbpOEmdflA2wdh+k53+SjzzdLAtvMrWofbVQUK21+Dw8SpTz4UTeS5gmI4Texcsu2l/ycLGOoTPb9eE2jlSUbLtqgnHTYH73q3zjZdAPlR30/5O+eUmZSr+PFNgKcMpHlp0U20rHXl953WJSGzH+1OVHfbP+8ptOyaYfcnIdVhFvV7r+/llZhcE4XL6tw9JKtBqoCLRJmA+nnHWmZJ5aVM1iwcMm8irhaBG8P7vvgsJ0QwahwQQs+dnw== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 22 Nov 2020 19:56:23 -0000 Date: 22 Nov 2020 14:56:23 -0500 Message-ID: <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> From: "John R Levine" To: "Michael Thomas" Cc: "dmarc@ietf.org" In-Reply-To: <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1126026243-1606074983=:15720" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 19:56:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1126026243-1606074983=:15720 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 22 Nov 2020, Michael Thomas wrote: >> The ARC signature has a sequence number so you can track the chain of >> custody.  You are right that it is similar to the DKIM signature but the >> extra ovehead doesn't seem excessive. >> > Did the wg consider just grafting that onto the DKIM signature itself instead > of having essentially a duplicate signature? Receivers are already supposed > to ignore any tags they don't understand so it shouldn't hurt backward > compatibility. ARC is an experiment that came from the people who designed DMARC. It's not a WG product. Having adapted the perl DKIM module to handle ARC signing and verification, I can say that the extra signature is not a big deal. If you look at mail coming from large mail systems, they're full of other junk headers and the extra overhead of AMS along with DKIM is not important. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1126026243-1606074983=:15720-- From nobody Sun Nov 22 12:01:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5C93A0BEF for ; Sun, 22 Nov 2020 12:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=CN6Ib+ne; dkim=pass (2048-bit key) header.d=taugh.com header.b=c5lH3PeI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQPqILKvulrV for ; Sun, 22 Nov 2020 12:01:21 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C554A3A0BEE for ; Sun, 22 Nov 2020 12:01:20 -0800 (PST) Received: (qmail 25039 invoked from network); 22 Nov 2020 20:01:19 -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:cleverness; s=61cd.5fbac38f.k2011; bh=d0qGUJckjv9uauW9cT/I9D6D9Q+5Yz3ApJSInNtv6L4=; b=CN6Ib+neNrGpGXTp9BJXb2N+Hov4Cl7/a6TMj3VmFg25Pvv+8EC8ihjojckn1o7qqKKPaEW7ajUsC03hj3U6ieae32is80UhxS2i4lDMrRpy1RKMXWqc7u8DqzBb/ms6Im2eUVw/f2BKCQHSLUe9AgLv6PL9WchkNrgHrIrQsO8Q9nWlSn6p+muAA3yeiMbMVjWrqqvN8BJXKJuFdDfxDsZeYHs5AsGf7rlFPUBgdgFwgcm9gf2QjOawkyATislarvCMZoF3+hv4+tmY/Y0BOco5LR4gSzgzlBkTxHRo2IdARgq/3JrXmXiONuEWRvv15J1vHmaaXPPtmu3Ob3JsLA== 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:cleverness; s=61cd.5fbac38f.k2011; bh=d0qGUJckjv9uauW9cT/I9D6D9Q+5Yz3ApJSInNtv6L4=; b=c5lH3PeI0PLHws4g/pwxU2D75SUNsnm8XmaHVAunA5A7DA4ec5vLvCILGrja6JEDouVih55aUrjjMtV/lm0Dp5nt0siCRX+sVbDUGRe2+MSrjG7PlLXC8lK82gF83YuileWesxNubeX1k9EZjEHQNfBtfHXbrjrcbgjuttHPI3SdvsczqtTxS6yPJENdtQXz9h161p5pyHNoliceRa9Ywix3lVp9dRIhZGU/sLoaBMN9NV8rIU0dMEIDvdxBfNjkFLP2YN6nohDgvnzJXk9fWfSImCsjR+J66zryBxDxPmUIHXOkUDuU96snKCT8G8RWPaeJCnEwlFVocpLDu8QkoA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 22 Nov 2020 20:01:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 1D77527BB031; Sun, 22 Nov 2020 15:01:18 -0500 (EST) Date: 22 Nov 2020 15:01:18 -0500 Message-Id: <20201122200119.1D77527BB031@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 20:01:22 -0000 In article you write: >-=-=-=-=-=- > > >On 11/22/20 11:18 AM, Douglas E. Foster wrote: >> ARC has a very limited set of items included in the signature.� �Body >> hash is purposefully excluded.� So it is the same signature algorithm >> but with different parameters and a different purpose.� Therefore it >> has a different header label . > >Now wait, Kurt just said that the body hash is included. Somebody has to >be wrong here. Doug is mistaken. The ARC-Message-Signature (AMS) header has the same body hash as a DKIM signature. From nobody Sun Nov 22 12:35:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197AB3A0CE7 for ; Sun, 22 Nov 2020 12:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5R6naGuwSZ7 for ; Sun, 22 Nov 2020 12:35:02 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C433A0CE4 for ; Sun, 22 Nov 2020 12:35:02 -0800 (PST) X-ASG-Debug-ID: 1606077298-11fa313c012c240001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id qTkN8VLz2EXSxxHN (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Sun, 22 Nov 2020 15:34:58 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=H91CJzHpJhbhZzl41gAzYahqWpv0+VLl6Ko21TU/+Fs=; b=GpO4Ez/PF43q1rs54hRH4I+a7ZbCMR44LND1Jdk/WvUIdvqoKCPTKYtYq/UiHMmIa AyED0sJlCEMZ3GK0w+81XoT30bquu+e5dwGuZFit+mNsGgFDVfTKXUdHswf5zfR+8 sU86qiFoPOmcKtHRip5OCL4Mw3kuN3Br+TbDUHwfk= From: "Douglas E. Foster" To: Date: Sun, 22 Nov 2020 15:34:49 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] ARC questions Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=2d0007a3f68b4a9192a6628af8f6929a In-Reply-To: <20201122200119.1D77527BB031@ary.qy> References: <20201122200119.1D77527BB031@ary.qy> X-Exim-Id: d64e6e7bf2b44936a4129492c934bb33 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606077298 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5443 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86053 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M Custom Rule 7568M Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2020 20:35:04 -0000 This is a multipart message in MIME format. --2d0007a3f68b4a9192a6628af8f6929a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies. Either I read an obsolete version of the document, an unrelat= ed document, or have a hallucinating memory. Hoping it is not my mind goi= ng south... Doug ---------------------------------------- From: "John Levine" Sent: 11/22/20 3:01 PM To: dmarc@ietf.org Cc: mike@mtcc.com Subject: Re: [dmarc-ietf] ARC questions In article you write: >-=3D-=3D-=3D-=3D-=3D- > > >On 11/22/20 11:18 AM, Douglas E. Foster wrote: >> ARC has a very limited set of items included in the signature.=3F =3FBod= y >> hash is purposefully excluded.=3F So it is the same signature algorithm >> but with different parameters and a different purpose.=3F Therefore it >> has a different header label . > >Now wait, Kurt just said that the body hash is included. Somebody has to >be wrong here. Doug is mistaken. The ARC-Message-Signature (AMS) header has the same body hash as a DKIM signature. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --2d0007a3f68b4a9192a6628af8f6929a Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Apologies.    Either I re= ad an obsolete version of the document, an unrelated document, or have a ha= llucinating memory.   Hoping it is not my mind going south...

Doug


From: "John L= evine" <johnl@taugh.com>
Sent: 11/22/20 3:01 PM
To: dmarc@ietf.or= g
Cc: mike@mtcc.com
Subject: Re: [dmarc-ietf] ARC questions

In article <bb13f0db-362b-78dd= -c005-279ac1776672@mtcc.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>
>On 11/22/20 11:18 AM, Do= uglas E. Foster wrote:
>> ARC has a very limited set of items included in the= signature.=3F =3FBody
>> hash is purposefully excluded.=3F So it is the same= signature algorithm
>> but with different parameters and a different purpose= .=3F Therefore it
>> has a different header label .
>
>Now wait, Kurt just said that t= he body hash is included. Somebody has to
>be wrong here.

Doug is mistaken. The ARC-Message-Signature (AMS) h= eader has the same
body hash as a DKIM signature.

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
d= marc mailing list
dmarc@ietf.org
--2d0007a3f68b4a9192a6628af8f6929a-- From nobody Mon Nov 23 01:14:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684A33A17A2 for ; Mon, 23 Nov 2020 01:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.379 X-Spam-Level: X-Spam-Status: No, score=0.379 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1, URI_NOVOWEL=0.5] 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 vzN58QGGPWpR for ; Mon, 23 Nov 2020 01:14:17 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21403A17A9 for ; Mon, 23 Nov 2020 01:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606122850; bh=ZeetAZn5Cb2CSTqHWGGH/5dY9MK/nzXQCldQP2zNwPI=; l=2629; h=To:References:From:Date:In-Reply-To; b=A+AVXRynAzoE55Dyv92+GQs++in90ZTfSuZlILopiMw/fKfODaBW0yNj+AwWhXwV3 V34q92VoOfsNjQhRN/+9q+rh0K8roRB3QuNA37IHmpSnFwY8aGr6tTdPhZV5cUE0LF R3S7NWBQTfxuQD5LtALnAUPpOUZUqTVpgjmzHorGBb9+nG8MNT3qbH/EsZhyX Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C3.000000005FBB7D62.0000701E; Mon, 23 Nov 2020 10:14:10 +0100 To: dmarc@ietf.org References: <20201122110057.23150.qmail@submit.iecc.com> From: Alessandro Vesely Message-ID: <4071b99a-04b4-b2ea-c71b-3db5879a8523@tana.it> Date: Mon, 23 Nov 2020 10:14:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201122110057.23150.qmail@submit.iecc.com> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 22 06:02:35 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 09:14:28 -0000 I just checked one message for each author, from my folder. Some domains alternately pass and fail. With a few tweaks, all author signatures on this list would reliably pass. Best Ale On 22/11/2020 12:00, John Levine wrote: > Count | Bytes | Who > ------------+----------------+------- > 13 (21.3%) | 122003 (18.5%) | Murray S. Kucherawy dkim=pass reason="transformed" (whitelisted) header.d=gmail.com; > 10 (16.4%) | 208118 (31.5%) | Doug Foster dkim=neutral (test key, signature verification failed) header.d=bayviewphysicians.com; > 8 (13.1%) | 39471 ( 6.0%) | John Levine dkim=fail (signature verification failed) header.d=taugh.com; > 6 ( 9.8%) | 105091 (15.9%) | Todd Herr dkim=pass reason="Original-From: transformed" (whitelisted) header.d=valimail.com; > 4 ( 6.6%) | 13999 ( 2.1%) | Dave Crocker -- > 3 ( 4.9%) | 22124 ( 3.4%) | Kurt Andersen (b) dkim=pass reason="transformed" (whitelisted) header.d=drkurt.com; > 3 ( 4.9%) | 20923 ( 3.2%) | Chudow, Eric B CIV NSA DSAW (USA) dkim=fail (signature verification failed) header.d=mail.mil; > 3 ( 4.9%) | 18496 ( 2.8%) | Alessandro Vesely dkim=pass (whitelisted) header.d=tana.it; > 2 ( 3.3%) | 39866 ( 6.0%) | Tim Wicinski dkim=pass reason="transformed" (whitelisted) header.d=gmail.com; > 2 ( 3.3%) | 14037 ( 2.1%) | Jim Fenton dkim=fail (signature verification failed) header.d=bluepopcorn.net; > 1 ( 1.6%) | 16436 ( 2.5%) | Craig Schwartz dkim=pass reason="Original-From: transformed" header.d=ftld.com; > 1 ( 1.6%) | 7830 ( 1.2%) | Dotzero dkim=fail (signature verification failed) header.d=gmail.com; > 1 ( 1.6%) | 7693 ( 1.2%) | Dale R. Worley dkim=fail (signature verification failed) header.d=comcastmailservice.net > 1 ( 1.6%) | 6556 ( 1.0%) | Gene Hightower dkim=pass reason="transformed" header.d=digilicious.com; > 1 ( 1.6%) | 6531 ( 1.0%) | Michael Thomas dkim=fail (signature verification failed) header.d=mtcc-com.20150623.gappssmtp.com > 1 ( 1.6%) | 6485 ( 1.0%) | Alwin de Bruin dkim=pass reason="transformed" (whitelisted) header.d=gmail.com; > 1 ( 1.6%) | 4404 ( 0.7%) | Gren Elliot dkim=fail (signature verification failed) header.d=mimecast.com; From nobody Mon Nov 23 05:19:11 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BE73A0ABA for ; Mon, 23 Nov 2020 05:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAiu7Fabg0N5 for ; Mon, 23 Nov 2020 05:19:08 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id A844B3A0ABC for ; Mon, 23 Nov 2020 05:19:08 -0800 (PST) Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 271729F149; Mon, 23 Nov 2020 05:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1606137547; bh=AcffYtH836mumbKWjlxPjfwnREcD+EeESJe+KHLNF58=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=cl0YkvH+XNFRaPuV40XAhQnq4nCclj+aBxolVtp2o8hzXP+bjHQeS3u5l8FiBVQzS /HosyURaakPJNKJ9s3yycH0lF9ISQs3oy1q2eppyCutuSq67qlhYXou7pD6cwYacMl RqmiGn/CNOJ56JPVKVMcsuAn9nipKp8L2mvDw1gE= From: Laura Atkins Message-Id: <9B843155-8A96-4F0B-8DF3-8F5C580AA023@wordtothewise.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C518B58D-4A2D-477B-BE3E-30EE8818A856" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 23 Nov 2020 13:19:05 +0000 In-Reply-To: Cc: IETF DMARC WG To: "Murray S. Kucherawy" References: <20201122022346.C039627B3EF9@ary.qy> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 13:19:10 -0000 --Apple-Mail=_C518B58D-4A2D-477B-BE3E-30EE8818A856 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Nov 2020, at 06:06, Murray S. Kucherawy = wrote: >=20 > On Sat, Nov 21, 2020 at 6:23 PM John Levine > wrote: > It is my impression that most real From: domains are pretty short. I > don't think I've ever seen one more than four labels long that wasn't > deliberately contrived. Anyone got data on that? >=20 > I'd bet there are some in .gov or .mil, especially the latter, but = otherwise I think the longest one I've seen is five, and that was not a = host that receives mail. >=20 > I'm sure we can all scrape our own mail logs for evidence either way. This might be a place where one (or more) of the big ESPs can help. = They=E2=80=99re going to have billions of email addresses and know which = ones have MXs. I=E2=80=99m happy to ask for that data if it would be of = use.=20 laura=20 --=20 Having an Email Crisis? We can help! 800 823-9674=20 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 =09 Email Delivery Blog: https://wordtothewise.com/blog=09 --Apple-Mail=_C518B58D-4A2D-477B-BE3E-30EE8818A856 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 22 Nov 2020, at 06:06, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Sat, Nov 21, 2020 = at 6:23 PM John Levine <johnl@taugh.com> wrote:
It is my impression that most real = From: domains are pretty short. I
don't think I've ever seen one more than four labels long that wasn't
deliberately contrived. Anyone got data on that?

I'd bet there are some in .gov or .mil, especially the = latter, but otherwise I think the longest one I've seen is five, and = that was not a host that receives mail.

I'm sure we can all scrape our own mail = logs for evidence either way.

This might be a place where one (or more) of the = big ESPs can help. They=E2=80=99re going to have billions of email = addresses and know which ones have MXs. I=E2=80=99m happy to ask for = that data if it would be of use. 

laura 

-- 
Having an Email Crisis? =  We can help! 800 823-9674 

Laura Atkins
Word = to the Wise
laura@wordtothewise.com
(650) = 437-0741 =

Email Delivery Blog: https://wordtothewise.com/blog =







= --Apple-Mail=_C518B58D-4A2D-477B-BE3E-30EE8818A856-- From nobody Mon Nov 23 06:25:11 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150053A0C90 for ; Mon, 23 Nov 2020 06:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0tIb2SRIy4O for ; Mon, 23 Nov 2020 06:25:08 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394693A0C94 for ; Mon, 23 Nov 2020 06:25:08 -0800 (PST) X-ASG-Debug-ID: 1606141505-11fa313c0131c40001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id oQJIYPpAnJeXl8rF (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Mon, 23 Nov 2020 09:25:06 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:reply-to:subject:to:from; bh=SJK8Bxyo1tly8Cf7jaBB3gXB1dlRlIzeSfEHYnyuJV8=; b=lBaQ70XEnxF1txZh+tQIhMg0ZdQzlmboYjnAsR6S65MVGknHQzGTdKoE8YA3JoWRb kAlRW3JMksw2kfMsanqePNJabsSzrn2Cwo8hmih8oDCx/eEWDST5HA0mCL4zOMvPV pYhosUUfSDPEeTLdeB7HtqDTyVvjl+N8CtV8Vq2tI= From: "Douglas E. Foster" To: "dmarc@ietf.org" Date: Mon, 23 Nov 2020 09:24:58 -0500 X-ASG-Orig-Subj: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd Reply-To: fosterd@bayviewphysicians.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=b2d8afe180604e19ab24a881d95f858a In-Reply-To: <9B843155-8A96-4F0B-8DF3-8F5C580AA023@wordtothewise.com> References: <20201122022346.C039627B3EF9@ary.qy> <9B843155-8A96-4F0B-8DF3-8F5C580AA023@wordtothewise.com> X-Exim-Id: c6254522cc6644528c35fe9168edfb01 X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606141506 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 21920 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86070 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 14:25:10 -0000 This is a multipart message in MIME format. --b2d8afe180604e19ab24a881d95f858a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My longest addresses are from SalesForce.com, with 6 segments. Relatively small dataset. ---------------------------------------- From: Laura Atkins Sent: 11/23/20 8:19 AM To: "Murray S. Kucherawy" Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-= ietf-dmarc-psd On 22 Nov 2020, at 06:06, Murray S. Kucherawy wrote: On Sat, Nov 21, 2020 at 6:23 PM John Levine wrote: It is my impression that most real From: domains are pretty short. I don't think I've ever seen one more than four labels long that wasn't deliberately contrived. Anyone got data on that=3F I'd bet there are some in .gov or .mil, especially the latter, but otherwis= e I think the longest one I've seen is five, and that was not a host that r= eceives mail. I'm sure we can all scrape our own mail logs for evidence either way. This might be a place where one (or more) of the big ESPs can help. They're= going to have billions of email addresses and know which ones have MXs. I'= m happy to ask for that data if it would be of use. laura -- Having an Email Crisis=3F We can help! 800 823-9674 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog --b2d8afe180604e19ab24a881d95f858a Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My longest addresses are from SalesForce.com, with= 6 segments.
Relatively small dataset.

From: Laura Atkins <laur= a@wordtothewise.com>
Sent: 11/23/20 8:19 AM
To: "Murray S. Kucherawy= " <superuser@gmail.com>
Cc: IETF DMARC WG <dmarc@ietf.org>Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-= ietf-dmarc-psd

=


On 22 Nov 2020, a= t 06:06, Murray S. Kucherawy <superuser@gmail.com= > wrote:

On Sat, Nov 21, 2020 at 6:23 PM Joh= n Levine <johnl@taugh.com> wrote:
It is my impression that= most real From: domains are pretty short. I
don't think I've ever seen one more than four= labels long that wasn't
deliberately contrived. Anyone got data on that=3F

I'd bet there are some in .gov or .= mil, especially the latter, but otherwise I think the longest one I've seen= is five, and that was not a host that receives mail.

I'm sure we can all scrape our own mail logs for e= vidence either way.

This might be a place where one (or more= ) of the big ESPs can help. They're going to have billions of email address= es and know which ones have MXs. I'm happy to ask for that data if it would= be of use. 

laura =

<= span fr-original-class=3D"Apple-style-span" fr-original-style=3D"border-col= lapse: separate; border-spacing: 0px; color: rgb(0, 0, 0); font-family: Hel= vetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal= ; font-variant-position: normal; font-variant-caps: normal; font-variant-nu= meric: normal; font-variant-alternates: normal; font-variant-east-asian: no= rmal; font-weight: normal; letter-spacing: normal; line-height: normal; tex= t-indent: 0px; text-transform: none; orphans: 2; white-space: normal; widow= s: 2; word-spacing: 0px;" style=3D"border-collapse: separate; border-spacin= g: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-= style: normal; font-variant: normal; font-weight: normal; letter-spacing: n= ormal; line-height: normal; text-indent: 0px; text-transform: none; orphans= : 2; white-space: normal; widows: 2; word-spacing: 0px; box-sizing: border-= box;">
-- =
Having = an Email Crisis=3F  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
(650) 437-0741

Email Delivery Blog: https://wordtothewise.com/blog







--b2d8afe180604e19ab24a881d95f858a-- From nobody Mon Nov 23 06:29:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3BF3A0C9A for ; Mon, 23 Nov 2020 06:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail.mil Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91jafKDPNSwB for ; Mon, 23 Nov 2020 06:29:19 -0800 (PST) Received: from UCOL19PA37.eemsg.mail.mil (UCOL19PA37.eemsg.mail.mil [214.24.24.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918193A0C9C for ; Mon, 23 Nov 2020 06:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail.mil; i=@mail.mil; q=dns/txt; s=EEMSG2018v1a; t=1606141759; x=1637677759; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y0lJ8euuyYE35xTSNl2lFsA7O+irpTYMX5hMEMPI9Ko=; b=poN3N2SipL8sD0gXqluyWKDZ8rJvTs8sn9k2CgWbc61KC+HqEfG16Zzu IVbQ4BI1RY+2g+gNG/1kpwbzP0GhT3BLiYO8YOPcgqWcF6TF+OERWPScQ Ox3H7SxphWOdObvoUgfSytjdJDtli2vTFsbvuqo5GJes4lk1FbVADwz2p m1jcOgcdjfCDXLem+FPrIFIMPFg6EcGK8UvNOqMFbia5l/6qLAOS4k18t KSmykhoBE+3gjWlnKlJCbCWNUqZpVnkVRHDBg4n/RruyVRs4LtJOqk8GQ T7fhah2gxlJc7y/G/fdKe11NOSZE+Lt4xBT6hzKvWqBX7yJCMLJLPJdjS A==; X-EEMSG-check-017: 180259945|UCOL19PA37_ESA_OUT04.csd.disa.mil X-IronPort-AV: E=Sophos;i="5.78,363,1599523200"; d="scan'208,217";a="180259945" Received: from edge-mech02.mail.mil ([214.21.130.231]) by UCOL19PA37.eemsg.mail.mil with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Nov 2020 14:29:16 +0000 Received: from UMECHPAOR.easf.csd.disa.mil (214.21.130.161) by edge-mech02.mail.mil (214.21.130.231) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 23 Nov 2020 14:28:23 +0000 Received: from UMECHPA7D.easf.csd.disa.mil ([169.254.6.235]) by umechpaor.easf.csd.disa.mil ([214.21.130.161]) with mapi id 14.03.0487.000; Mon, 23 Nov 2020 14:28:23 +0000 From: "Chudow, Eric B CIV NSA DSAW (USA)" To: Laura Atkins , "Murray S. Kucherawy" CC: IETF DMARC WG Thread-Topic: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd Thread-Index: AQHWwZtiqQAQOpNRTkOng1A17Bshh6nVxPAngAABpOs= Date: Mon, 23 Nov 2020 14:28:22 +0000 Message-ID: <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> References: <20201122022346.C039627B3EF9@ary.qy> , <9B843155-8A96-4F0B-8DF3-8F5C580AA023@wordtothewise.com> In-Reply-To: <9B843155-8A96-4F0B-8DF3-8F5C580AA023@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.97.88] Content-Type: multipart/alternative; boundary="_000_553D43C8D961C14BB27C614AC48FC0312811FC37UMECHPA7Deasfcs_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 14:29:20 -0000 --_000_553D43C8D961C14BB27C614AC48FC0312811FC37UMECHPA7Deasfcs_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Even for .mil, the vast majority of email domains are fairly short with fou= r or fewer labels. Most of the other ones tend to be individual servers tha= t send automatic performance emails, and I think should be considered more = of an edge case and less of our concern. Thanks, Eric Chudow DoD Cybersecurity Mitigations ________________________________ From: Laura Atkins [laura@wordtothewise.com] Sent: Monday, November 23, 2020 8:19 AM To: Murray S. Kucherawy Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-= ietf-dmarc-psd On 22 Nov 2020, at 06:06, Murray S. Kucherawy > wrote: On Sat, Nov 21, 2020 at 6:23 PM John Levine > wrote: It is my impression that most real From: domains are pretty short. I don't think I've ever seen one more than four labels long that wasn't deliberately contrived. Anyone got data on that? I'd bet there are some in .gov or .mil, especially the latter, but otherwis= e I think the longest one I've seen is five, and that was not a host that r= eceives mail. I'm sure we can all scrape our own mail logs for evidence either way. This might be a place where one (or more) of the big ESPs can help. They=92= re going to have billions of email addresses and know which ones have MXs. = I=92m happy to ask for that data if it would be of use. laura -- Having an Email Crisis? We can help! 800 823-9674 Laura Atkins Word to the Wise laura@wordtothewise.com (650) 437-0741 Email Delivery Blog: https://wordtothewise.com/blog --_000_553D43C8D961C14BB27C614AC48FC0312811FC37UMECHPA7Deasfcs_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B84FE3B17E371428504B26A13F07302@easf.csd.disa.mil> Content-Transfer-Encoding: quoted-printable

Even for .mil, the vast majority of email domains are fairly short = with four or fewer labels. Most of the other ones tend to be individua= l servers that send automatic performance emails, and I think should b= e considered more of an edge case and less of our concern. 

 

Thanks,

 

Eric Chudow

DoD Cybersecurity Mitigations

 

From: Laura Atkins [laura@wordtothewise.c= om]
Sent: Monday, November 23, 2020 8:19 AM
To: Murray S. Kucherawy
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for= draft-ietf-dmarc-psd



On 22 Nov 2020, at 06:06, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Sat, Nov 21, 2020 at 6:23 PM John Levine <johnl@taugh.com> wrote:
It is my impression that most real From: domains are pretty short. I
don't think I've ever seen one more than four labels long that wasn't
deliberately contrived. Anyone got data on that?

I'd bet there are some in .gov or .mil, especially the latter, but oth= erwise I think the longest one I've seen is five, and that was not a host t= hat receives mail.

I'm sure we can all scrape our own mail logs for evidence either way.<= /div>

This might be a place where one (or more) of the big ESPs can help. Th= ey=92re going to have billions of email addresses and know which ones have = MXs. I=92m happy to ask for that data if it would be of use. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
(650) 437-0741

Email Delivery Blog: https://wordtothewise.com/blog







--_000_553D43C8D961C14BB27C614AC48FC0312811FC37UMECHPA7Deasfcs_-- From nobody Mon Nov 23 06:50:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE343A0DC6 for ; Mon, 23 Nov 2020 06:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.492 X-Spam-Level: X-Spam-Status: No, score=0.492 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=0.7, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VauObqy6pfT for ; Mon, 23 Nov 2020 06:50:17 -0800 (PST) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 6DE3B3A0DC4 for ; Mon, 23 Nov 2020 06:50:17 -0800 (PST) Received: from pps.filterd (m0167075.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ANEfaHv011232 for ; Mon, 23 Nov 2020 09:50:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : content-type; s=pps01; bh=TKIuO/5TleC8trb6XW7szzRj/5RIi6Okx68HTozrETQ=; b=rXQj7qLNu4HFGu5e2NhYuVRsRRmBrSHjwmr7OzvIK3y09i0/4a9hID5r8kaIlslgs4ZI opXbm0Fu8fsk84OMeqPq3IY19LENbBqWozqfagE5Rtnfe450Gr9D1pGAJnzX4Ek8k70k IvRRlHaGeWA/XqvrHeUSrzZT2oPv8OjwS5HKgUMm60Q2Vn9EWnPy11jFpdUD26fNl/IW wN3ZtHGxNZL6aIcQEmpoQGDN2/dJhoPNIph3W9XumWSWLwDqAETEXhLPPe4cvArPfFjX 5YLm7EqwgT9QIT89s7E13oiVbmcHfnPPIS4Nlp3a4x0f5gsg3BXP7a4Kfru0OF7uk7S0 uw== Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0b-00364e01.pphosted.com with ESMTP id 34xyrtswys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 23 Nov 2020 09:50:16 -0500 Received: from mail-io1-f72.google.com (mail-io1-f72.google.com [209.85.166.72]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0ANEoF8p041630 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 23 Nov 2020 09:50:15 -0500 Received: by mail-io1-f72.google.com with SMTP id v15so12993745ioq.16 for ; Mon, 23 Nov 2020 06:50:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TKIuO/5TleC8trb6XW7szzRj/5RIi6Okx68HTozrETQ=; b=pWvEpC7ryMIgBMt/AbHAsUtSIcSZ5nP1ecVCApvHJwSNOAo5xMYcSb1Bx8hioSMMwc Eb9JqwCXOm7bXyEYWbnY3eK9HEMgdgQ+FjlfrKyIrXHZ0GYVf0cHDt8eWuKE0GH6aFNI +AlZNVZDhuk6pISHNposTfq4XUk9rleQyxLWLru4NZmXkMC6zgwT7Wx7m4D5igxafvrL cZUO4Isu2nAH9QekEoGer+bfxUI90UJkB29xdEeup7gD3h80ixOfJzjAc1flw9dvG42i cFCVf5QAj85Ds/maAdJtPuXnNPaTDh/fJWZPrxXyiLAvPWBqhTrDMQv84ajmbUMUT04c Jjrw== X-Gm-Message-State: AOAM532P4RvzRJ2gP7gGhC/dQqIaMC0O3guQAMBKLWE1P8jTScdSTHeG CF06nHduUHLaAdN+uZKYTJVnMJZV0WcjuIcY7foSRsIl/kq7WichSLE/UQi8S+ECFerIo4LWLLj vlRZ9hnzMuwEA/nn9DjtVSqKMKr0iJw== X-Received: by 2002:a05:6602:1853:: with SMTP id d19mr90320ioi.46.1606143014704; Mon, 23 Nov 2020 06:50:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJxPVbwwh1/+e7V82bZAJI3tEGQ3JYm68K246vqcegkG74LwfZ+hEZuK5Xpx7XUCkl4OB625xA27RcS4Adq7ZzE= X-Received: by 2002:a05:6602:1853:: with SMTP id d19mr90298ioi.46.1606143014362; Mon, 23 Nov 2020 06:50:14 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> In-Reply-To: From: Joseph Brennan Date: Mon, 23 Nov 2020 09:50:03 -0500 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d4719105b4c74fef" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-23_11:2020-11-23, 2020-11-23 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 malwarescore=0 clxscore=1015 suspectscore=2 spamscore=0 impostorscore=10 mlxscore=0 mlxlogscore=711 adultscore=0 priorityscore=1501 lowpriorityscore=10 phishscore=0 bulkscore=10 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011230101 Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 14:50:19 -0000 --000000000000d4719105b4c74fef Content-Type: text/plain; charset="UTF-8" > > > > > On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > >> >> > This also means that ARC isn't useful if you don't have a reputation >> system to tell you where the lists and other forwarders that might add >> legit ARC signatures are. >> > > And if you know which hosts are legit mailing lists or forwarders, you already know what ARC would tell you. -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --000000000000d4719105b4c74fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Sat, Nov 21, 2020 at 7:14 PM John Levine <johnl@taugh.com> wrote:

=C2=A0
This also means that ARC isn't useful if you don't have a reputatio= n
system to tell you where the lists and other forwarders that might add
legit ARC signatures are.=C2=A0

=

And if you know which hosts are legit mail= ing lists or forwarders, you already know what ARC would tell you.


=C2=A0
--
Joseph Brennan
Lead, Email and Sys= tems Applications
Columbia University Information Technology
<= br>

--000000000000d4719105b4c74fef-- From nobody Mon Nov 23 07:39:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFA53A07A0 for ; Mon, 23 Nov 2020 07:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igY8iuXtNRjv for ; Mon, 23 Nov 2020 07:39:05 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 9DE233A0779 for ; Mon, 23 Nov 2020 07:39:05 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id ec16so9003135qvb.0 for ; Mon, 23 Nov 2020 07:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dxyl3bEq3wDGRejOn2DrhVkxE6WfWGAaLflq1KjBEMc=; b=CQVIKZH/fVtH/dSDgCm9hxpjGFmuFLCVEyPAJPDRrimHMfGDNG1SSIwEdVuq0EMQkx 9cbWQmmix8tq1/WKydt0HK7+vDXPUVGY8V0wtXrJn5DaHNo91+AI8UzjDoT+FNGVMckb 18NCMhou1dYSKvPvMiR5hNBTuH/7kmdnMD7t4m9WKmN7iKO8+GgAH9ajAosrXyzAOniZ nJ/MmERPPreMnUxo1txkDCJH+cPI5tXXpiNFJ77vF3K+/XpinVdVcRjHFu11tORa4KNQ bN3Wig2UTvBya6TrziM/dm93ZCpgNcLFtHh/QF+Q2+qnyeN6Vy+hovCWtmOkOdv6z9dp 1nXg== 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=Dxyl3bEq3wDGRejOn2DrhVkxE6WfWGAaLflq1KjBEMc=; b=TsHYGLdm0v7YhugiZBWpOBWab31A18gcXHD1hh5UZR/inarpXEJ9/Y3iJU+YD2PZTd BgZRsqZ8Rjvn7WBCWqi2/wyZWczBZ2vMf9PoH+Gr3boy7MUQECBFd102awXgmpxKOOAs LCfbPDYpGmXUDHMNlAjHi0oQf9JpFYPX9fVeK2EUE+DCJ/H4AiCITA1d5xznvjMZBajn NhTfCRkg0J2Cx8nqzky68NowPlDDJm+peoDgi8nMEnE2U8fUiu+1ahGQC4YYUzJkbE1T sOWJ9VhTl6rSyHJ4iFpZwf2Zo5FxdJrxigRJxg/NikKU+a7ioHx+c7wmYryB28VXDN72 DK3w== X-Gm-Message-State: AOAM531FDUDBzWmG8iphV6N0e4JrkRFEnDD9AICBaoHmjk+t+tHtDiDW 0Vfkf0d85Y/F1YPWum5eJ4c1QSaNWjPmbE9TBaWVWA== X-Google-Smtp-Source: ABdhPJyT4PFv5ipgRxAWQgrMQrvxY7zPH1/SwSeOJFuPR8g37IIMlQqRJGu76QXvKhj63/e00bC4ZI0iCNfG/9TAOW4= X-Received: by 2002:a0c:db11:: with SMTP id d17mr29880471qvk.39.1606145944575; Mon, 23 Nov 2020 07:39:04 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> In-Reply-To: From: Todd Herr Date: Mon, 23 Nov 2020 10:38:48 -0500 Message-ID: To: Joseph Brennan Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007bf99505b4c7fecd" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 15:39:08 -0000 --0000000000007bf99505b4c7fecd Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan wrote: > >> On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: >> >>> >>> > >> This also means that ARC isn't useful if you don't have a reputation >>> system to tell you where the lists and other forwarders that might add >>> legit ARC signatures are. >>> >> >> > And if you know which hosts are legit mailing lists or forwarders, you > already know what ARC would tell you. > > I believe, though, that the intent of ARC is that it be scalable in ways that manual enumeration of known legit mailing lists and forwarders is not. Standard authentication protocols (SPF, DKIM, DMARC) are fine for direct mail flow. When the message arrives at its destination, the receiver can check authentication protocols and apply handling rules for a message based on its past history with the authenticated identities associated with that message. For indirect mail flows, messages might not pass such checks at their final destination, but it's possible that they did pass those checks on an intermediate hop. As Michael said in his original post, ARC 'allows intermediaries to say "this is what it looked like to me at this point [and before i messed it]".' The question with ARC then becomes, does the final destination trust the results reported in the ARC header set(s), and it's kind of a complicated question. If I as the final destination trust the ARC header set(s), I'm saying that I believe the reported results with no real way to independently verify the results, meaning that I can't do direct DKIM validation or SPF checking using standard tools; if I could, there'd be no need for ARC. I suppose that an approach to building up an ARC reputation might be one where over time a receiving site can compare indirect mail flow that is purported to have X as an authenticated identifier with mail that comes direct to the receiving site with X as an authenticated identifier. That is, if direct mail with X as an authenticated identifier generally hits Y on my internal reputation scale, does indirect mail that is ARC-signed by Z to have X as an authenticated identifier also generally hit Y on my internal reputation scale? If so, great; I can trust Z as an ARC signer. The devil is in the details, though. If mail through Z doesn't generally hit Y, then what explains the variance? If it's for most or all values of X, then it's probably because Z is a bad actor. If it's hitting Y for most values of X but not for all, is it because those particular mail streams are ones that are still legitimate from an authentication perspective, but aren't of the same quality due to reasons, or is Z engaging in some elaborate scheme using valid mail as legit shields to get its nasty payload through in the noise? If variances can be dealt with in a way that doesn't require too much manual intervention, then perhaps there's hope here. Even at that, such a system would need to be bootstrapped with some list of manually enumerated known good intermediaries, but over time it could theoretically grow organically based on data collected. I don't believe the above challenges are insurmountable (says the guy who hasn't had operational responsibility for a mail system in over a decade) but I'm not in a position to assign the necessary resources to solve this problem at each site that has an interest in doing so. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000007bf99505b4c7fecd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 23, 2020 at 9:50 AM Joseph Br= ennan <brennan@columbia.edu&= gt; wrote:

On Sat, Nov 21, 2020 at= 7:14 PM John Levine <johnl@taugh.com> wrote:

=C2=A0
This also means that ARC isn't useful if you don't have a reputatio= n
system to tell you where the lists and other forwarders that might add
legit ARC signatures are.=C2=A0

=

And if you know which hosts are legit mail= ing lists or forwarders, you already know what ARC would tell you.


I believe, though,= that the intent of ARC is that it be scalable in ways that manual enumerat= ion of known legit mailing lists and forwarders is not.=C2=A0
Standard=C2=A0authentication protocols (SPF, DKIM, DMARC) are f= ine for direct mail flow. When the message arrives at its destination, the = receiver can check authentication protocols and apply handling rules for a = message based on its past history with the authenticated identities associa= ted with that message.

For indirect mail flows, me= ssages might not pass such checks at their final destination, but it's = possible that they did pass those checks on an intermediate hop. As Michael= said in his original post,=C2=A0 ARC 'allows intermediaries to say &qu= ot;this is
what it looked like to me at this point [and before i messe= d it]".'

The question with ARC then becomes, does the final destination = trust the results reported in the ARC header set(s), and it's kind of a= complicated question. If I as the final destination trust the ARC header s= et(s), I'm saying that I believe the reported results with no real way = to independently verify the results, meaning that I can't do direct DKI= M validation or SPF checking using standard tools; if I could, there'd = be no need for ARC.

I suppose that an approach to building up an ARC reputation m= ight be one where over time a receiving site can compare indirect mail flow= that is purported to have X as an authenticated identifier with mail that = comes direct to the receiving site with X as an authenticated identifier. T= hat is, if direct mail with X as an authenticated identifier generally hits= Y on my internal reputation scale, does indirect mail that is ARC-signed b= y Z to have X as an authenticated identifier also generally hit Y on my int= ernal reputation scale? If so, great; I can trust Z as an ARC signer.
=

The devil i= s in the details, though. If mail through Z doesn't generally hit Y, th= en what explains the variance? If it's for most or all values of X, the= n it's probably because Z is a bad actor. If it's hitting Y for mos= t values of X but not for all, is it because those particular mail streams = are ones that are still legitimate from an authentication perspective, but = aren't of the same quality due to reasons,=C2=A0or is Z engaging in som= e elaborate=C2=A0scheme using valid mail as legit shields to get its nasty = payload through in the noise? If variances can be dealt with in a way that = doesn't require too much manual intervention, then perhaps there's = hope here. Even at that, such a system would need to be bootstrapped with s= ome list of manually enumerated known good intermediaries, but over time it= could theoretically grow organically based on data collected.
I don't believe the above challenges are insurmountable (s= ays the guy who hasn't had operational responsibility for a mail system= in over a decade) but I'm not in a position to assign the necessary re= sources to solve this problem at each site that has an interest in doing so= .

--

Todd Herr= | Sr. Technical Program Manager
p: 703.220.4= 153


This email and all data transmitted with it c= ontains confidential and/or proprietary information intended solely for the= use of individual(s) authorized to receive it. If you are not an intended = and authorized recipient you are hereby notified of any use, disclosure, co= pying or distribution of the information included in this transmission is p= rohibited and may be unlawful. Please immediately notify the sender by repl= ying to this email and then delete it from your system.

--0000000000007bf99505b4c7fecd-- From nobody Mon Nov 23 09:02:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C801F3A0B04 for ; Mon, 23 Nov 2020 09:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG8619EZNXby for ; Mon, 23 Nov 2020 09:02:31 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 8E6D23A0B05 for ; Mon, 23 Nov 2020 09:02:31 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id l17so4359481pgk.1 for ; Mon, 23 Nov 2020 09:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=hX5aF7AQcBlj+NxFG1IGxAX/9ifiBkGCW7eygn8hQ4k=; b=ourCJb6Jfzam1rEIy1FR1pyLE2l8j7sJnkgBEnFqc9GSY72Icijdcoo0ACi3fOdwhn 7aGTngZ23ejrBtSreSCWI7kI9J8ZDIcsSX4o21vG7EanOqpfZaYpLUxPkfD1N8sGlZxO rYhBvmrPh4X3IW5rNMY1GciUutqcMzHZxa4fOoCrFlJ3man5/rToytki0Jb0Es+bqGjq EVkgQ/PjJLk6JlfLpYQr9QNYFmIPJL/33M4xUbmd3zFwjL94euwHruycjrGfQODRM9ge OZdGmEA6meK/X9Yy9g7++mTR+2KDBD8MvXdw7Z/fEgDIpVKKh0krsQ+Vc9WdNWujAM+c GXxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hX5aF7AQcBlj+NxFG1IGxAX/9ifiBkGCW7eygn8hQ4k=; b=IKn51AT25AWWURoXJdbtCve7hhwQ0ju/7xcJjRMrYvby8mqBUxoSJ+PLC/jmpVmilM EW3cj12ebFMflokxydDg7gneyI36DkCzfevWZ8N1Siy1Zcm7GmKNqycSigqXEDvLf6gE ZAt725JPefhY8+Voe80aJs2csQmzrZVHTLCMOwbT1kt/YQSeNB4/Y+ql+jwB12Wn6WYn j3XxuYO7/e+F7iRUAE9HnC4HHcpE3tJH56ZWnqIxBwB1RZU6LGttgfv1ZQBYD9nyFB9X OEVsbhDvpJn4CveQ46VpHdmH5EX+/2xtAGORlcOSiB88jMw+nDf98IC4rV+8lY98/P+L hZVw== X-Gm-Message-State: AOAM531OkgsRqMOHPr0VhgeSi1QET5F0ud/4hlAzEwpt4mlubV0RADaH bjavBW0eIq0e7UhPX/4aSGh+jYhCzXA= X-Google-Smtp-Source: ABdhPJw6v0iSUJfZ0T26B0XWrlY7JOZKtSzQyAMAPUjb9vQd858U02KdY20VKizaZrd6FPCTuTHN4A== X-Received: by 2002:a17:90a:5901:: with SMTP id k1mr710808pji.7.1606150950802; Mon, 23 Nov 2020 09:02:30 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id k8sm12495353pfh.6.2020.11.23.09.02.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 09:02:30 -0800 (PST) To: Todd Herr , Joseph Brennan Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> From: Dave Crocker Message-ID: Date: Mon, 23 Nov 2020 09:02:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0DD3EABB8DF139F7347965F6" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 17:02:33 -0000 This is a multi-part message in MIME format. --------------0DD3EABB8DF139F7347965F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/2020 7:38 AM, Todd Herr wrote: > On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan > wrote: > On Sat, Nov 21, 2020 at 7:14 PM John Levine > wrote: > > This also means that ARC isn't useful if you don't have a > reputation > system to tell you where the lists and other forwarders > that might add > legit ARC signatures are. > > > And if you know which hosts are legit mailing lists or forwarders, > you already know what ARC would tell you. > > > I believe, though, that the intent of ARC is that it be scalable in > ways that manual enumeration of known legit mailing lists and > forwarders is not. "if you know which hosts are legit" buries an assumption that is problematic, namely that you know who handled the message.  The fack that a message purports to be handled by a mailing list you trust does not mean it actually was. That's the issue that ARC resolves. ARC (and DKIM) produce noise-free uses of identifiers.  If the authentication validates, the receiver knows is really was handled by who is saying it was handled by.  Without these, you don't. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------0DD3EABB8DF139F7347965F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/23/2020 7:38 AM, Todd Herr wrote:
On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan <brennan@columbia.edu> wrote:
On Sat, Nov 21, 2020 at 7:14 PM John Levine <johnl@taugh.com> wrote:
 
This also means that ARC isn't useful if you don't have a reputation
system to tell you where the lists and other forwarders that might add
legit ARC signatures are.

And if you know which hosts are legit mailing lists or forwarders, you already know what ARC would tell you.

I believe, though, that the intent of ARC is that it be scalable in ways that manual enumeration of known legit mailing lists and forwarders is not. 


"if you know which hosts are legit" buries an assumption that is problematic, namely that you know who handled the message.  The fack that a message purports to be handled by a mailing list you trust does not mean it actually was.

That's the issue that ARC resolves.

ARC (and DKIM) produce noise-free uses of identifiers.  If the authentication validates, the receiver knows is really was handled by who is saying it was handled by.  Without these, you don't.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------0DD3EABB8DF139F7347965F6-- From nobody Mon Nov 23 09:15:44 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF163A0B89 for ; Mon, 23 Nov 2020 09:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIGE-bXVpUcq for ; Mon, 23 Nov 2020 09:15:40 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004923A0B80 for ; Mon, 23 Nov 2020 09:15:38 -0800 (PST) X-ASG-Debug-ID: 1606151736-11fa313c0137730001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id FjgolAaFDV4D1Uba (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 23 Nov 2020 12:15:37 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=q7bdxE1MJsYk6jGqEvIubie5fEUXXujcsClJJBjCvKo=; b=dT/xxmCnNCD/23yTJ5Qizlx2musgcpbrfYB9WwQSq5UROLGRfrc/8M4t6WPgl4N2a YLbKVZ2+MqrBOfKK/aETSaEVkuPs7wHZly37coL/qf6o3kUTsjTsv+fS5YCF1R/zc 8UkkUZLFVi6iptmS+jw1EgkZmAUETF5E6OzaF7/ds= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 23 Nov 2020 12:15:27 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'Dave Crocker'" , "'Todd Herr'" , "'Joseph Brennan'" Cc: References: <20201122021417.B5E6E27B3E59@ary.qy> In-Reply-To: Date: Mon, 23 Nov 2020 12:15:26 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] ARC questions Message-ID: <004b01d6c1bc$3d9a1990$b8ce4cb0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01D6C192.54C4FBF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXz+0WkBofX62NH9iXrOEFk3P74QI1TqT8AiMfSDYA2L0BEAHq4xAZAmU2bUGqB806cA== Content-Language: en-us X-Exim-Id: 004b01d6c1bc$3d9a1990$b8ce4cb0$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606151737 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 8349 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86073 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 17:15:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01D6C192.54C4FBF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My wishlist for ARC: =20 ARC tells me that somebody changed some data, but it does not tell me = which MTA performed the forwarding operation, added content, or = performed address rewriting. If we could get HELO names into the ARC = data, then those names could be correlated with the Received header = chain to make better filtering decisions. =20 DF =20 =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Monday, November 23, 2020 12:02 PM To: Todd Herr; Joseph Brennan Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ARC questions =20 On 11/23/2020 7:38 AM, Todd Herr wrote: On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan = wrote: On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: =20 This also means that ARC isn't useful if you don't have a reputation system to tell you where the lists and other forwarders that might add legit ARC signatures are.=20 =20 And if you know which hosts are legit mailing lists or forwarders, you = already know what ARC would tell you. =20 I believe, though, that the intent of ARC is that it be scalable in ways = that manual enumeration of known legit mailing lists and forwarders is = not.=20 =20 "if you know which hosts are legit" buries an assumption that is = problematic, namely that you know who handled the message. The fack = that a message purports to be handled by a mailing list you trust does = not mean it actually was. That's the issue that ARC resolves. ARC (and DKIM) produce noise-free uses of identifiers. If the = authentication validates, the receiver knows is really was handled by = who is saying it was handled by. Without these, you don't. d/ --=20 Dave Crocker dcrocker@gmail.com 408.329.0791 =20 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org ------=_NextPart_000_004C_01D6C192.54C4FBF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

My wishlist for ARC:

 

ARC tells me that somebody changed some data, but it does not tell me = which MTA performed the forwarding operation, added content, or = performed address rewriting.=C2=A0 If we could get HELO names into the = ARC data, then those names could be correlated with the Received header = chain to make better filtering decisions.

 

DF =C2=A0=C2=A0

 

From:= = dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave = Crocker
Sent: Monday, November 23, 2020 12:02 PM
To: = Todd Herr; Joseph Brennan
Cc: = dmarc@ietf.org
Subject: Re: [dmarc-ietf] ARC = questions

 

On = 11/23/2020 7:38 AM, Todd Herr wrote:

On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan <brennan@columbia.edu> = wrote:

On Sat, Nov 21, 2020 = at 7:14 PM John Levine <johnl@taugh.com> = wrote:

 

This also = means that ARC isn't useful if you don't have a reputation
system to = tell you where the lists and other forwarders that might add
legit = ARC signatures are. =

 

And if you know which hosts are legit mailing lists or = forwarders, you already know what ARC would tell = you.

 

I = believe, though, that the intent of ARC is that it be scalable in ways = that manual enumeration of known legit mailing lists and forwarders is = not. 

 

"if you know which hosts are legit" buries an assumption = that is problematic, namely that you know who handled the message.  = The fack that a message purports to be handled by a mailing list you = trust does not mean it actually was.

That's the issue = that ARC resolves.

ARC (and DKIM) produce noise-free = uses of identifiers.  If the authentication validates, the receiver = knows is really was handled by who is saying it was handled by.  = Without these, you don't.

d/

-- 

Dave =
Crocker
dcrocker@gmail.com
408.329.0791
 
Volun=
teer, Silicon Valley Chapter
American Red =
Cross
dave.crocker2@redcross.org=
------=_NextPart_000_004C_01D6C192.54C4FBF0-- From nobody Mon Nov 23 09:23:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8C93A09E1 for ; Mon, 23 Nov 2020 09:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p_ch6_nMxBv for ; Mon, 23 Nov 2020 09:23:51 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 E61153A0A42 for ; Mon, 23 Nov 2020 09:23:42 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id t37so14777628pga.7 for ; Mon, 23 Nov 2020 09:23: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; bh=Ax+6SUXz3jXB4EUOpAX2/7nO05NycLXO5lEjaej7Z3o=; b=H9F6ep9upNdRRHA0uiYv4ff0nSoQLnuiwQUYRZt4o65oZf70aclSWx76v1Pd6vt0IC nfvkvtjiET7kVvJpPaRHVUOsBt7L2IDSvR4KF3qzOXR+3Ea0s8MCiJ39bjt07Zq/cyY8 yH0G5725Mc7EBD5fwI4ZXQx8TGWiSOGPdftpfqWkjWuXCSmlPQlOkO6+fuTk8owi9uCF 09g4/XhgMgb0G2Vqy9kfuE7IWlOf+T8WNyRpJJBFhZgJ8roLwE4Judm0ppkfFluuTrEZ rVVHp5oHBxdJ79I5vfaeb9JzcMDcOrTskOTs0cCQtvVopr8r4JGc7eNz8YXM7PqASHD6 /sSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Ax+6SUXz3jXB4EUOpAX2/7nO05NycLXO5lEjaej7Z3o=; b=AMDNiZv90Ju3KQRj3YT/ZYAAKWWt5/3a92VA+t0H3DfKSdR2NjAjo46O4UeoCnS7Fp zr2TBedXcdFyvhG1KVWQG2GITbGJwaVFRopXLmuFmWxWC1FpMFpHb3bfXQoeAA325NWW akdAU2ojdWr6QZjDUDPOtbM2FntxZULl0n9J4/dyzJi1FDcsxcnUaoJqL6kQyQFHoWJU HhW7DPPA6JJRkhCAd9GVjUbM1o/ci5RYZQBeW0wNwhSyTFvNOMetVeXRl5ktJqqIgoMv vT0jojOZN8Er0f08gXHvTq3AGf3lVPydHQtI63EKRabS2Hgz15HhxPOdNEOkyoxhG3Kj b33g== X-Gm-Message-State: AOAM531zD7B3pSK0fBkRpusKnb2+nCdipuFlvBOPdjxaRjeyMg+xm3H+ A0V+a8Blp0hl+cJmNIryul0Ujy/vzFU= X-Google-Smtp-Source: ABdhPJykx8cCom2Uq8wqq7M3SgtDqrxllj+5sa3vb0yP+Tudos7YGMKg1kAw0Z/m40lyb7mtCOJrTA== X-Received: by 2002:a62:256:0:b029:18c:6905:d18d with SMTP id 83-20020a6202560000b029018c6905d18dmr335870pfc.67.1606152222239; Mon, 23 Nov 2020 09:23:42 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id l17sm14158213pjy.29.2020.11.23.09.23.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 09:23:41 -0800 (PST) To: Doug Foster Cc: dmarc@ietf.org References: <20201122021417.B5E6E27B3E59@ary.qy> <004b01d6c1bc$3d9a1990$b8ce4cb0$@bayviewphysicians.com> From: Dave Crocker Message-ID: <8786c65e-432e-6c25-e6ae-df7e6cb5f6bc@gmail.com> Date: Mon, 23 Nov 2020 09:23:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <004b01d6c1bc$3d9a1990$b8ce4cb0$@bayviewphysicians.com> Content-Type: multipart/alternative; boundary="------------A381B73C1252FD48C9DC9C36" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 17:23:57 -0000 This is a multi-part message in MIME format. --------------A381B73C1252FD48C9DC9C36 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/2020 9:15 AM, Doug Foster wrote: > ARC tells me that somebody changed some data, but it does not tell me > which MTA performed the forwarding operation, added content, or > performed address rewriting.  If we could get HELO names into the ARC > data, then those names could be correlated with the Received header > chain to make better filtering decisions. That's not ARC.  Feel free to recruit others to support a new initiative, for a different protocol. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------A381B73C1252FD48C9DC9C36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/23/2020 9:15 AM, Doug Foster wrote:
ARC tells me that somebody changed some data, but it does not tell me which MTA performed the forwarding operation, added content, or performed address rewriting.  If we could get HELO names into the ARC data, then those names could be correlated with the Received header chain to make better filtering decisions.


That's not ARC.  Feel free to recruit others to support a new initiative, for a different protocol.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------A381B73C1252FD48C9DC9C36-- From nobody Mon Nov 23 09:41:31 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95A93A0AAD for ; Mon, 23 Nov 2020 09:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucEdHKCjWrje for ; Mon, 23 Nov 2020 09:41:27 -0800 (PST) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 D380E3A0AA3 for ; Mon, 23 Nov 2020 09:41:26 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2107.outbound.protection.outlook.com [104.47.55.107]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QK901UJZFS4QE70@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 23 Nov 2020 11:40:53 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.23.173317, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.19.5790001, SenderIP=[104.47.55.107] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F1fD05v95Y78PF0wCSm55tmksnlgVXRsInurX0slDkLew11e7lCBaoKG+M4V/aCEEpB0/wCZeVy4C1gs+ErZm9Usu3aoRdwlkoaWYhuSNZLD6GhG5gBvyp610RthCjPNRDuu2dMEdQag05Q+J+Z7G7D2dZFL0302U/ZBwu8TcBO9CX/FdeeLW4GpaZEDJ31z9XAKzrUrAyZiygwnn8R+/NpKs2G2gUc5UJABFl+t0rcQgt3o/hGw8ZxOrA5+/I3JLpJzRy7V1VMI7+2NfPG4DQhPM9mZ9ioFPccYC9Fs7SQp6aUSIp7jvxke0n0Di7+JiAjtSwCpbiinwxR3hCATew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GTdaSLMalYQimCYqfv9dPSLMOR5vNt9fyvcbj3j9n2Q=; b=M2YxSgR6mOEQ5IkavciYA8oyTBqX4W7ViGKXIeQlvnpnrWfcxzltPW6UuZF2wqrNtyzZ6jczphHsKV/8p3c8m9M9g1Wqz3/mvgVGMCqyhie3y9M729/mcFC+r/lpEQ7oCIf1hZkwwtwfL1vsPKzKijBTYhDMf9SiW07NTWdBwqVsRqhsKjraQEjjEFDUjWOTK277HvLoBS8GliVtGge82frZuk5vKWAausc2u1LkidDZdcqJvBJiegIE5rNrFcUKIXQNiTxnBiOuxH3ElltA3cu71Ruvlf38WRYOlhQdLbKpcu/2DdG4Q4ZPo7X7dirTS3ZCZQus0+KM35vupldqXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GTdaSLMalYQimCYqfv9dPSLMOR5vNt9fyvcbj3j9n2Q=; b=irNsZoNyMPIEwXo3aigGWCEUlj+xlr8Fp1YTNITOCLjT/BGO8ZxN8gVMYQQbQp0BrafGwxlomlfJ16kDXzscSMsVPQY27mbrSpgGgFzU6AJ12Sa8o7ORlGLrAllE1JTeZCb0OtnH2ebUoTxp9GhkAd9yJYLCdlaxyx33Yw1d7hU= Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by CO6PR06MB7105.namprd06.prod.outlook.com (2603:10b6:5:34d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Mon, 23 Nov 2020 17:40:51 +0000 Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5%7]) with mapi id 15.20.3589.022; Mon, 23 Nov 2020 17:40:51 +0000 To: dmarc@ietf.org References: <20201122022346.C039627B3EF9@ary.qy> <9B843155-8A96-4F0B-8DF3-8F5C580AA023@wordtothewise.com> <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> From: Jesse Thompson Message-id: <023d37eb-e8ef-275f-21a4-5d0d76974a53@wisc.edu> Date: Mon, 23 Nov 2020 11:40:48 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-reply-to: <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> Content-type: text/plain; charset=windows-1252 Content-language: en-US Content-transfer-encoding: base64 X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH2PR10CA0012.namprd10.prod.outlook.com (2603:10b6:610:4c::22) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR10CA0012.namprd10.prod.outlook.com (2603:10b6:610:4c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Mon, 23 Nov 2020 17:40:51 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6281de0b-27aa-44a6-c085-08d88fd6ebe2 X-MS-TrafficTypeDiagnostic: CO6PR06MB7105: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2ecTdn0BhCSLJ+vhaBw8h6Bf1Mz6+z2bIOmXxeRrieg4oI8q6M7HmQeqi8CEI8dTgvT3hLWlzCqHn4IqkoTr5PkD4uWePbDT3Nu2R+MOEjNIcwGTWX8kRCTZpugF4r0IQK6aDoUvp5nLqH2I5b3+llFDR+1v8+flrrJ8iAYbHspGI0TyL5cmTJBoVySnMDywTuZ5tbS7de99KG18PSQilDuuWINs4Mb4fG+GjHucWrRbB7p+Lnewy/VFYEw3ZuEbmEtcE4L3JLLJaXXALu4wB+Lo1qpHRe6xdXMQ3GeBRf/mR1bBcl19wLN3S6MYtOY5lox/R2ls6KIxZGucYB3r5RUhtBjBuoPQb1emUYiBcxSFcj2WxYRX9lnWT1CAdlkmjs8O2NeyfeLyrU5abYrCo+pVomEhsjhP2KupU4NMh2O0IHiJPPBms9VOCthrqCOQ6iy0Dd40h8OmJrgxOjEjXYyqL8Ru3AVBtAoP9eYeNU4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(39860400002)(366004)(346002)(396003)(186003)(16526019)(36756003)(316002)(16576012)(2906002)(6916009)(6706004)(786003)(6666004)(83380400001)(66556008)(66476007)(66946007)(478600001)(75432002)(31696002)(2616005)(44832011)(956004)(966005)(5660300002)(31686004)(26005)(8936002)(6486002)(8676002)(53546011)(86362001)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?Windows-1252?Q?an0pFz3Vwt0bAlvwS2ZzDqsh7uRDrL8Q2JYlUK2aYqBivUW7wyfClF2/?= =?Windows-1252?Q?QqWDVNMHnyUlrgz0d3gWKThgwF8cpjvt5q67Fo0rWwWw0BZOSyVerb0I?= =?Windows-1252?Q?BbS31YMv8nST7+ZnTfR39BhuclB71q1hKATdB8C1A1eukfoocqx8jNeO?= =?Windows-1252?Q?DjiAM9i0UlKoClrdo87CBy7n2ZMCg+Sg/3xK+hZLKSpMCHidEuOs2V81?= =?Windows-1252?Q?i0YIqfIJNjLIOpIIxDXPitCdIlwgdXeffNfyYar4FT7U0R/uvEcs2q4O?= =?Windows-1252?Q?sU6lLHxhcGUMBtLvGmlgO3ruJ7S0vxGwBbZGQzO+XkFc2mU8Do7mY34B?= =?Windows-1252?Q?rbN3ZCl2K43ivbA5ZnRW1BCmZZoFOLNmf6JPaa/nh2HIkUjIOaEovRhH?= =?Windows-1252?Q?js2ohQPdFEsGbbPgD+PrtiFQWcfWq53cwNLk9JlquW31HOE9urqHNuKK?= =?Windows-1252?Q?aUedFO3+8ivWRCuJyw8MvymKcqM/tT+Jg2EO4vbo8cu7DC4rH347HNUS?= =?Windows-1252?Q?67wmSouBWOWOUGzgAeg5iPb9g9+zujBt/dcc/xCQHS3lQeXAK5976W1T?= =?Windows-1252?Q?Ipo1QOSSdTZabD0mNJ3xyORYojER0V/0B0m5DXx8q5EIM4pgkQHHCata?= =?Windows-1252?Q?MU/0umL1I9sD4LqL+FXYu19oOSDNjx8/CaPD0hXMf7lSFtCkkBPh8yP/?= =?Windows-1252?Q?OUkCU1FtU2PvoFwIGCUyZH9fgxX8/XKb1YlP4vx3GM3rwqMCZ0bacWqg?= =?Windows-1252?Q?qmrLTylWHt+73/j7VsptLHXj3n99CjScCDj0OvKMyU8tj9vHxXIkejvl?= =?Windows-1252?Q?TtkLUttLvhZ2+Rhmb2dULL1963tDoan6OV6ftLOZkSk9bi2Hm00DoXpf?= =?Windows-1252?Q?bO8VQtMP21j3sp93OzqqtU2t2pY7IxpTAT1MghS3XNkRp++2VEBZ3ImA?= =?Windows-1252?Q?tehXIfFmPA9ECws5LTot4vfPpHWuvVio0lxXgzGTdcxTAMjYUI7TJRq6?= =?Windows-1252?Q?riQ7E739SW8aZkq+5QClqzf9M6nhFp6weDOLawlWaOUZwWE2o51MGrAn?= =?Windows-1252?Q?Y09EfNO3rwGJepGz?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 6281de0b-27aa-44a6-c085-08d88fd6ebe2 X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2020 17:40:51.8385 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5rsHTbGaCu6FnSOK7N+hvYz8nMc5VaZGsrNl7SWT0t0o1T2JLW25mUF8cHKL2BN5PzaNs0Rb8+vllCs3zr+iSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR06MB7105 Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 17:41:29 -0000 T24gMTEvMjMvMjAgODoyOCBBTSwgZXJpYy5iLmNodWRvdy5jaXY9NDBtYWlsLm1pbEBkbWFyYy5p ZXRmLm9yZyB3cm90ZToNCj4gRXZlbiBmb3IgLm1pbCwgdGhlIHZhc3QgbWFqb3JpdHkgb2YgZW1h aWwgZG9tYWluc6BhcmUgZmFpcmx5IHNob3J0IHdpdGggZm91ciBvciBmZXdlciBsYWJlbHMuoE1v c3Qgb2YgdGhlIG90aGVyIG9uZXMgdGVuZCB0byBiZSBpbmRpdmlkdWFsIHNlcnZlcnMgdGhhdCBz ZW5kIGF1dG9tYXRpY6BwZXJmb3JtYW5jZSBlbWFpbHMsIGFuZCBJIHRoaW5rIHNob3VsZCBiZSBj b25zaWRlcmVkIG1vcmUgb2YgYW4gZWRnZSBjYXNlIGFuZKBsZXNzIG9mIG91ciBjb25jZXJuLqAN Cg0KVGhpcyBpcyB0aGUgY2FzZSBmb3IgdXMgYXMgd2VsbCAoZS5nLiBvdXIgY29tcCBzY2kgaGln aCB0aHJvdWdocHV0IGNvbXB1dGUgY2x1c3RlciBzZXJ2ZXJzIHNlbmQgYXV0b21hdGljIGVtYWls cyB0byBib3RoIGludGVybmFsIGFuZCBleHRlcm5hbCByZXNlYXJjaCBjb2xsYWJvcmF0b3JzKS4g IEkgc3VwcG9zZSB1bml2ZXJzaXRpZXMgYXJlIGRpZmZlcmVudCB0aGFuIHRoZSBtaWxpdGFyeSBz aW5jZSB0aGUgbWlsaXRhcnkgcHJvYmFibHkgZG9lc24ndCB3YW50IHRoZWlyIHNlcnZlcnMgdG8g YmUgc2VuZGluZyBlbWFpbCBleHRlcm5hbGx5LCB3aGVyZWJ5IHdpdGggYSByZXNlYXJjaCB1bml2 ZXJzaXR5IGNyb3NzLWluc3RpdHV0aW9uYWwgY29sbGFib3JhdGlvbiBpcyBpbmhlcmVudC4NCg0K SSBzdXBwb3NlIEkgY29uc2lkZXIgaXQgYW4gZWRnZSBjYXNlIHRvbyAoYSBsYXJnZSBlZGdlIGNh c2UgLSBJIHNlZSBvdmVyIDIwMCBvZiB0aGVzZSA0dGggbGV2ZWwgZG9tYWlucyBpbiBvciBETUFS QyBhZ2dyZWdhdGUgcmVwb3J0cyBmb3IgdGhlIGV4YW1wbGUgY2x1c3RlciBJIGNpdGUpLCBidXQg dGhlIGxvbmcgdGFpbCBvZiBzZXJ2ZXJzIGFsc28gYXJlbid0IGxpa2VseSB0byBjaGFuZ2UgdGhl IHdheSB0aGV5IGFyZSBzZW5kaW5nIGVtYWlsIG5vciB3aWxsIHN5c2FkbWlucyBpbXBsZW1lbnQg U1BGL0RLSU0gZm9yIGV2ZXJ5IHNlcnZlciBob3N0bmFtZSwgZXRjLCBzbyB0aGVzZSBzdWJkb21h aW5zIGFyZSBhIGJsb2NrZXIgZm9yIHB1Ymxpc2hpbmcgc3A9cmVqZWN0IGF0IHRoZSBvcmcgZG9t YWluIChoZW5jZSBhIGNvbmNlcm4gd2l0aGluIHRoZSBjb250ZXh0IG9mIHRyZWUgd2Fsa2luZyku DQoNCldoaWxlIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBpbXBsZW1lbnRhdGlvbiBjaGFs bGVuZ2VzIHRoYXQgbWF5IG1ha2UgdGhpcyBpbmZlYXNpYmxlLCB3aGF0IEkgd291bGQgKmxpa2Uq IHRvIGRvIGlzIGFzayBlYWNoIG9mIHRoZXNlIGRlcGFydG1lbnRzL3Jlc2VhcmNoIHRlYW1zIHRv IHB1Ymxpc2ggc3A9bm9uZSBhdCB0aGVpciAzcmQgbGV2ZWwgZG9tYWlucyAoYW5kIHRha2Ugb3Zl ciBETUFSQyByZXNwb25zaWJpbGl0aWVzIGZvciB0aGVpciBwYXJ0cyBvZiB0aGUgdHJlZSkgc28g dGhhdCB3ZSBjYW4gcHVibGlzaCBzcD1yZWplY3QgYXQgdGhlIG9yZyBkb21haW4gdG8gcHJvdGVj dC9tYW5hZ2UgdGhlIHJlc3Qgb2YgdGhlIHVuaXZlcnNpdHkuDQoNCkplc3NlDQoNClAuUy4gSGVy ZSBhcmUgc29tZSBzdGF0cy4gIFVuaXF1ZSBkb21haW5zIHVzZWQgaW4gdGhlIFJGQzUzMjIuRnJv bSByZXN1bHRpbmcgZnJvbSBtYWlsIHNlbnQgZXh0ZXJuYWxseSB0byBETUFSQyByZXBvcnRpbmcg b3JnYW5pemF0aW9ucyBpbiB0aGUgcGFzdCAyIHdlZWtzOg0KMjMgMm5kIGxldmVsIChvcmcgZG9t YWlucykNCjQ2NCAzcmQgbGV2ZWwgKDM1OSBhcmUgc3ViZG9tYWlucyBvZiB3aXNjLmVkdSkNCjUy MiA0dGggbGV2ZWwgKGFsbCBhcmUgc3ViZG9tYWlucyBvZiB3aXNjLmVkdSkNCjEzIDV0aCBsZXZl bA0KMiA2dGggbGV2ZWwNCg0KPiANCj4goA0KPiANCj4gVGhhbmtzLA0KPiANCj4goA0KPiANCj4g RXJpYyBDaHVkb3cNCj4gDQo+IERvRKBDeWJlcnNlY3VyaXR5IE1pdGlnYXRpb25zDQo+IA0KPiCg DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gKkZyb206KiBMYXVyYSBBdGtpbnMgW2xh dXJhQHdvcmR0b3RoZXdpc2UuY29tXQ0KPiAqU2VudDoqIE1vbmRheSwgTm92ZW1iZXIgMjMsIDIw MjAgODoxOSBBTQ0KPiAqVG86KiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+ICpDYzoqIElFVEYgRE1B UkMgV0cNCj4gKlN1YmplY3Q6KiBSZTogW2RtYXJjLWlldGZdIHRyZWUgd2FsayBhbmQgT3JnIGFu ZCBQU0QsIFNlY29uZCBXR0xDIGZvciBkcmFmdC1pZXRmLWRtYXJjLXBzZA0KPiANCj4gDQo+IA0K Pj4gT24gMjIgTm92IDIwMjAsIGF0IDA2OjA2LCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVz ZXJAZ21haWwuY29tIDxtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbT4+IHdyb3RlOg0KPj4NCj4+ IE9uIFNhdCwgTm92IDIxLCAyMDIwIGF0IDY6MjMgUE0gSm9obiBMZXZpbmUgPGpvaG5sQHRhdWdo LmNvbSA8bWFpbHRvOmpvaG5sQHRhdWdoLmNvbT4+IHdyb3RlOg0KPj4NCj4+ICAgICBJdCBpcyBt eSBpbXByZXNzaW9uIHRoYXQgbW9zdCByZWFsIEZyb206IGRvbWFpbnMgYXJlIHByZXR0eSBzaG9y dC4gSQ0KPj4gICAgIGRvbid0IHRoaW5rIEkndmUgZXZlciBzZWVuIG9uZSBtb3JlIHRoYW4gZm91 ciBsYWJlbHMgbG9uZyB0aGF0IHdhc24ndA0KPj4gICAgIGRlbGliZXJhdGVseSBjb250cml2ZWQu IEFueW9uZSBnb3QgZGF0YSBvbiB0aGF0Pw0KPj4NCj4+DQo+PiBJJ2QgYmV0IHRoZXJlIGFyZSBz b21lIGluIC5nb3Ygb3IgLm1pbCwgZXNwZWNpYWxseSB0aGUgbGF0dGVyLCBidXQgb3RoZXJ3aXNl IEkgdGhpbmsgdGhlIGxvbmdlc3Qgb25lIEkndmUgc2VlbiBpcyBmaXZlLCBhbmQgdGhhdCB3YXMg bm90IGEgaG9zdCB0aGF0IHJlY2VpdmVzIG1haWwuDQo+Pg0KPj4gSSdtIHN1cmUgd2UgY2FuIGFs bCBzY3JhcGUgb3VyIG93biBtYWlsIGxvZ3MgZm9yIGV2aWRlbmNlIGVpdGhlciB3YXkuDQo+IA0K PiBUaGlzIG1pZ2h0IGJlIGEgcGxhY2Ugd2hlcmUgb25lIChvciBtb3JlKSBvZiB0aGUgYmlnIEVT UHMgY2FuIGhlbHAuIFRoZXmScmUgZ29pbmcgdG8gaGF2ZSBiaWxsaW9ucyBvZiBlbWFpbCBhZGRy ZXNzZXMgYW5kIGtub3cgd2hpY2ggb25lcyBoYXZlIE1Ycy4gSZJtIGhhcHB5IHRvIGFzayBmb3Ig dGhhdCBkYXRhIGlmIGl0IHdvdWxkIGJlIG9mIHVzZS6gDQo+IA0KPiBsYXVyYaANCj4gDQo+IC0t oA0KPiBIYXZpbmcgYW4gRW1haWwgQ3Jpc2lzPyCgV2UgY2FuIGhlbHAhIDgwMCA4MjMtOTY3NKAN Cj4gDQo+IExhdXJhIEF0a2lucw0KPiBXb3JkIHRvIHRoZSBXaXNlDQo+IGxhdXJhQHdvcmR0b3Ro ZXdpc2UuY29tIDxtYWlsdG86bGF1cmFAd29yZHRvdGhld2lzZS5jb20+DQo+ICg2NTApIDQzNy0w NzQxDQo+IA0KPiBFbWFpbCBEZWxpdmVyeSBCbG9nOiBodHRwczovL3dvcmR0b3RoZXdpc2UuY29t L2Jsb2cgPGh0dHBzOi8vd29yZHRvdGhld2lzZS5jb20vYmxvZz4NCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBkbWFyYyBtYWlsaW5nIGxpc3QNCj4gZG1hcmNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYw0KPiANCg== From nobody Mon Nov 23 10:34:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428143A0C25 for ; Mon, 23 Nov 2020 10:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1DwjBaO9D-3 for ; Mon, 23 Nov 2020 10:34:46 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C053A0C23 for ; Mon, 23 Nov 2020 10:34:46 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id e10so6635258qte.4 for ; Mon, 23 Nov 2020 10:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OHwNXCn4335iUdg7IIse9LBp3Y+nFAMnhqEsdYhrA5I=; b=VUYLfk/dlrDGOa2stMpYDbQqECfl8KSqZle4iwRvmrnBIE4Wl9cAipwsVIhIQNYxIw 5EqkUFaLD2WLBSu6d4MybiLAVEqgwiUhoiTj3AVbUZdOKw1Ud/NaRaU3nG1V982/kgkM yQsRTQq+OIg1h/K3g1hfJwMsTRCe1YycJKjeQWlQnFA6f5sgpjieE3xCyNtIadrIouLY qNMnaZL0QcJ/kPSY3NjYf/TLfkKkuNgADWCESNYwKyocounzvjrJVPPRDlowgMyZnERo mz/I2EC6lMhSDRJ3lsZSfQ99ZrMt+1CQouwQ81+Yg6MHvK6vTjRu2c8rvv55HK2wFkw9 UKHA== 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=OHwNXCn4335iUdg7IIse9LBp3Y+nFAMnhqEsdYhrA5I=; b=OV/gSWAwuHoTSw058dpxxuy4x3+Uzjem4YwCBuuvGaXlezC+PMp6JxRSKpnZCdAxXq j6bf5GhUQ3R8Y4I2V/a1JmKLD+ewIW7ob5sOVQIumErGB5QaoWaWHKMB28O8UGz4TU+y Xxl5MLY3fX3gVVb240wJdr+sHGynW7SubQdpHHOQ12xfh7X7fHwqkYk0G7lmBln6JGRB D1pX6FftRC/H7S6b1LBQwhPbDDIwYTUKoijMyi6pEuVRuXV7Nu6k9gbuKHr2XWfG8YVJ 3+rhyghOpPl5wyDctw5vbRSmjyz9e4oeXirV8zYeh2Z0ouWA7nRVlZZ8SAhwuE/b2u4+ fY+A== X-Gm-Message-State: AOAM530VbzDoQ7dOOkOCvXajz0FxEJzpSz4j0QRTrF/tCt49cst8mkne wXx3zPnO8fDx8+u8j9QSx310C1nuOtpohu1vndBp+Bc7ym9GqQ== X-Google-Smtp-Source: ABdhPJxutpRPKa11zu9c+W9E5DpXqL82IQiqMl1uAnoxs5PpmuJ4axAElOx+ewd2a9dmr4TNGMsNXZTgDVedDvHwV+Y= X-Received: by 2002:aed:3ff1:: with SMTP id w46mr435258qth.83.1606156484891; Mon, 23 Nov 2020 10:34:44 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> In-Reply-To: From: Todd Herr Date: Mon, 23 Nov 2020 13:34:28 -0500 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bc6fee05b4ca72fe" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 18:34:48 -0000 --000000000000bc6fee05b4ca72fe Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 12:02 PM Dave Crocker wrote: > On 11/23/2020 7:38 AM, Todd Herr wrote: > > On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan > wrote: > On Sat, Nov 21, 2020 at 7:14 PM John Levine wrote: > >> >> >>> This also means that ARC isn't useful if you don't have a reputation >>>> system to tell you where the lists and other forwarders that might add >>>> legit ARC signatures are. >>>> >>> >> And if you know which hosts are legit mailing lists or forwarders, you >> already know what ARC would tell you. >> > > I believe, though, that the intent of ARC is that it be scalable in ways > that manual enumeration of known legit mailing lists and forwarders is not. > > > "if you know which hosts are legit" buries an assumption that is > problematic, namely that you know who handled the message. The fack that a > message purports to be handled by a mailing list you trust does not mean it > actually was. > > That's the issue that ARC resolves. > > ARC (and DKIM) produce noise-free uses of identifiers. If the > authentication validates, the receiver knows is really was handled by who > is saying it was handled by. Without these, you don't. > > > Yes, but knowing it really was handled by who is saying it was handled by isn't the entirety of the problem. I can know from ARC headers that X handled the message and what email authentication checks X purports to have done when handling the message and what results X claims to have obtained. What I have to decide in that case is "do I trust X to record correct and valid results?" because the answer to that question will impact my disposition of the message when it reaches me. It's obviously not the place of the ARC protocol spec to proscribe how trust in ARC results can be determined, but without some system in place for assigning trust levels to ARC Sealers, ARC has limited utility for sites that serve as the terminal destination for a message. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --000000000000bc6fee05b4ca72fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 23, 2020 at 12:02 PM Dave Cro= cker <dcrocker@gmail.com> w= rote:
=20 =20 =20
On 11/23/2020 7:38 AM, Todd Herr wrote:
On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan <<= a href=3D"mailto:brennan@columbia.edu" target=3D"_blank">brennan@columbia.e= du> wrote:
On Sat, Nov 21, 2020 at 7:1= 4 PM John Levine <johnl@taugh.com> wrote:
=C2=A0
This also means that ARC isn't useful if you don&= #39;t have a reputation
system to tell you where the lists and other forwarders that might add
legit ARC signatures are.

And if you know which hosts are legit mailing lists or forwarders, you already know what ARC would tell you.

I believe, though, that the intent of ARC is that it be scalable in ways that manual enumeration of known legit mailing lists and forwarders is not.=C2=A0


"if you know which hosts are legit" buries an assumption = that is problematic, namely that you know who handled the message.=C2=A0 The fack that a message purports to be handled by a mailing list you trust does not mean it actually was.

That's the issue that ARC resolves.

ARC (and DKIM) produce noise-free uses of identifiers.=C2=A0 If the authentication validates, the receiver knows is really was handled by who is saying it was handled by.=C2=A0 Without these, you don'= t.


Yes, but knowing it really was handl= ed by who is saying it was handled by isn't the entirety of the prob= lem.=C2=A0

I can know from ARC headers that X hand= led the message and what email authentication checks X purports to have don= e when handling the message and what results X claims to have obtained. Wha= t I have to decide in that case is "do I trust X to record correct and= valid results?" because the answer to that question will impact my di= sposition of the message when it reaches me.

It= 9;s obviously not the place of the ARC protocol spec to proscribe how trust= in ARC results can be determined, but without some system in place for ass= igning trust levels to ARC Sealers, ARC has limited utility for sites that = serve as the terminal destination for a message.

= --

Todd Herr | Sr. Technical Program Manager
p: 703.220.4153


This email and all data transmitted with it contains confidential= and/or proprietary information intended solely for the use of individual(s= ) authorized to receive it. If you are not an intended and authorized recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--000000000000bc6fee05b4ca72fe-- From nobody Mon Nov 23 10:40:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6604C3A0C31 for ; Mon, 23 Nov 2020 10:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt_7zz_y1vCG for ; Mon, 23 Nov 2020 10:40:26 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 C02863A0C25 for ; Mon, 23 Nov 2020 10:40:26 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id u2so9266605pls.10 for ; Mon, 23 Nov 2020 10:40:26 -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-transfer-encoding:content-language; bh=sCmSTDZ8ijvitXgxTfXWkDQa83W9Koc8gEwGJ/vx8GA=; b=jpgBcLzcd57bAUCxsdrxfR/uxLAM9QZGgSPRt3XyC2Gqwre6FXECdPvN7hLiJvtXTu hNcaTA6MQYLau1lkk06JITqjiDlW1AV7Dkz8S/FgGUEaFwCUc2V6+EIRhlxxdiw1jdUq 4abQjhVAd44m/C8mVDNg1a6afb5hFLG14a9RrOarFzR6UWu1GPOkCLtwf+E0W6nQPljR DF0NEeijbjxQnLbhtC5rlUtP0Xjy/2t8ATGlX/PqyzBTmq+LaKziH8aarYnQQrbJXqf4 vaL6/vQSgN3wdEJv6lcSu0Y4mwlZ37bShmq/o18uUorn89/k/tRhekcTyZJn78Zh5lZX O8VQ== 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-transfer-encoding :content-language; bh=sCmSTDZ8ijvitXgxTfXWkDQa83W9Koc8gEwGJ/vx8GA=; b=Rk8ZD3cOEMtRPPlj/da3NSmfQ8aad2ungrphVu3s2V3gNp4NrevbKKkhqdqj41/Ptv 0i+L6ZqsbLLe/clvDIoJqYyqoXgrc0fZT9s5uVZzMR8UNTnLP59uxHA3BtE6gRbFUOas Y+X55/IjxadjNAKlx3TpNujraVVwel0piFhBoAxRyQA9YCyG2cN0RLD3dc0IJOQEAo1V 5mrQrIDp/q9fwWUyQakfCg7dY3SZIYi2W5WoBAZ5gmE66TsvMbC2USFZK0bSEweJoucN mQ1hFx3cuh5i/LqjNV3uf5C2xBDROFeQx9gOP+ch9X8U1/BdkbEmHG+KG3Th3J9oeHY1 h+6w== X-Gm-Message-State: AOAM530PxdvvdjrSFSwLX+wYrLqeoaPT9e1VUPt1K0YUhVZIgoLuLhgP QzYHgKWTq7SjuLUAQdB6jrEjEATsxkQ= X-Google-Smtp-Source: ABdhPJwptszt5+9WxrMVJRopc1w7xJIbVoBorFpKAX4IooTXuD9iJyK57exXgU4iB7adSnFfYw39Ng== X-Received: by 2002:a17:902:8506:b029:d9:6dd:45ea with SMTP id bj6-20020a1709028506b02900d906dd45eamr666726plb.72.1606156825938; Mon, 23 Nov 2020 10:40:25 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id r3sm102157pjl.23.2020.11.23.10.40.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 10:40:25 -0800 (PST) To: Todd Herr , "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> From: Dave Crocker Message-ID: <5715fc56-02bf-c6f0-0e0a-a2c7d0a96277@gmail.com> Date: Mon, 23 Nov 2020 10:40:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 18:40:28 -0000 On 11/23/2020 10:34 AM, Todd Herr wrote: > Yes, but knowing it really was handled by who is saying it was handled > by isn't the entirety of the problem. Of course.  But it helps (quite a lot) to be clear about what this specific mechanism does do. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Mon Nov 23 10:43:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA423A0C25 for ; Mon, 23 Nov 2020 10:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1v3JNo10YPp for ; Mon, 23 Nov 2020 10:43:11 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596043A0C23 for ; Mon, 23 Nov 2020 10:43:11 -0800 (PST) X-ASG-Debug-ID: 1606156988-11fa313c0139ca0001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id s7WqzHf21dLH7TB4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 23 Nov 2020 13:43:09 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=jHSmwuCXZnzSS2Zau+tlCdth9XOH5feflRbhyqn+s0g=; b=hDKPGh1cPW1OXIrjpNoTetW1jorr2zFvpFkbv0PsoTYYUUCA+GGSKHzLVx51gMwxz Rjp4wmP6tzi0NG3e2WhZKGopkStjFXMi6CI7JqVhiU2uLVQ1ycQRqxLfJoGYcXkiJ eKHvris1oSfAVJcsS+TJy0hojssSlayO76LE1u7LI= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Mon, 23 Nov 2020 13:43:01 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'Tim Wicinski'" Cc: "'IETF DMARC WG'" References: <003f01d6bcf0$69055b60$3b101220$@bayviewphysicians.com> <553D43C8D961C14BB27C614AC48FC03128116494@UMECHPA7D.easf.csd.disa.mil> <90433555c5d34c2a98744c408e617f06@bayviewphysicians.com> In-Reply-To: Date: Mon, 23 Nov 2020 13:43:02 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP Message-ID: <00d001d6c1c8$79804e00$6c80ea00$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D6C19E.90AD2C30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJImLb1cmUMRltHAmghMYnlRx5C7gMRkJ65AaptzrECDxExzgEDiy0OqLPmFyA= Content-Language: en-us X-Exim-Id: 00d001d6c1c8$79804e00$6c80ea00$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606156988 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 41924 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86074 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 18:43:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D1_01D6C19E.90AD2C30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I was misinterpretation the language to require detection whether any = host existed in the zone, rather than checking whether there is a host = name which matches the domain name. Thank you to Murray for = straightening me out. =20 That aside, we still have a problem. The specification is applying = SPF-type logic to an address that has no necessary connection to SPF. = A typical advertising message, sent be a third party, will pass SPF = using the third-party sender=E2=80=99s domain. The message From = address becomes a label to identify the client organization in some = manner, and possibly to identify the identity of the marketing campaign. = The domain name used for that purpose may not exist anywhere else, = often does not accept replies, and may not exist as a mail server domain = anywhere. Consequently, these may very well be unregistered domains, = but it may be reasonable to insist that domain owners get them = registered to avoid false positives from the test. The least = disruptive test will be for NS. Anything stricter will produce false = positives. =20 The logic that seems to work is: - Check SPF and DKIM for domain alignment. If the DMARC = criteria are satisfied by either method, the message domain does not = need to exist, because it has been validated. - If the message does not pass DMARC alignment, then we need to = look for a DMARC policy to see if P/SP/NP applies. If NP applies, and = NS does not exist, the NP policy is applied. =20 Using the example domain from the document, I am assuming that we are = trying to block all three of these non-existent domains: - T4x.gov.example - Spammer.t4x.gov.example - Spammer.tax.gov.example If the goal is only to block t4x.gov.example, then the current NP = algorithm is slightly less problematic. =20 Doug Foster =20 =20 From: Tim Wicinski [mailto:tjw.ietf@gmail.com]=20 Sent: Thursday, November 19, 2020 11:04 PM To: fosterd@bayviewphysicians.com Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: = Definition of NP =20 Doug =20 In looking for domain presence most folks will look at the domain = itself. There are a few web tools to enumerate such as https://dnschecker.org/=20 =20 Some examples https://dnschecker.org/#MX/dmarc.org https://dnschecker.org/#TXT/dmarc.org https://dnschecker.org/#TXT/_dmarc.dmarc.org =20 There are unix tools - such as 'dig' - which are also quite useful. =20 hope this helps tim =20 =20 On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster = wrote: Time to show my ignorance again. =20 How do I check a domain for presence or absence of A, AAAA, or MX = records? I thought most domains were protected from enumeration, so one had to = know a name to find out if it is defined =20 DF =20 =20 _____ =20 From: "Douglas E. Foster" Sent: 11/19/20 9:27 PM To: "IETF DMARC WG" Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: = Definition of NP =20 Thank you for the pointer Eric. =20 Can someone explain why the chosen algorithm, which requires testing = multiple conditions, is preferable to a single query for a name server = record? Minimizing DNS traffic has been part of our recent discussion, = and minimizing software complexity is always a good thing. =20 Can someone also explain why the DMARC appendix takes such a strong = stance against all queries for non-existent domains, regardless of = technique? It seems like the philosophical incompatibilities need to be = addressed before both documents advance. =20 DMARC is specified only as a test for the RFC5322.From domain. = RFC5321.MailFrom domains may also be non-existent. They will return SPF = NONE, but that is an ambiguous result, and SPF has no organization = default mechanism. =20 * Is there data to indicate whether evaluators have found that checking = the RFC5321.MailFrom for non-existence is useful? =20 * Suppose that the NP policy becomes generalized, and a domain has = asserted a "must-exist" DMARC policy. Should a non-existent subdomain = used in the RFC5321.MailFrom address be treated skeptically? I can imagine a scenario where a spammer uses a bogus subdomain of a = legitimate organization, in an attempt to get whitelisted by spam = filters which primarily evaluate the RFC5321.MailFrom address. This = attack could be paired with an unrelated and non-DMARC RFC5322.From = address which is newly minted or otherwise not generally known to be = suspicious, So my instinct is that some extension of DMARC to the SMTP = address will be beneficial. =20 Doug Foster =20 =20 =20 =20 _____ =20 From: "Chudow, Eric B CIV NSA DSAW (USA)" Sent: 11/19/20 5:31 PM To: 'Doug Foster' , 'IETF DMARC WG' = Cc: "'dmarc-chairs@ietf.org'" Subject: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: = Definition of NP =20 Section 2.7. defines a non-existent domain as "a domain for which there = is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a = broader definition than that in NXDOMAIN [RFC8020]." This should be = sufficient for determining that the domain is not intended to be used = and therefore could have a more stringent policy applied. =20 The idea of looking for a "mail-enabled domain" based on if an "MX = record exists or SPF policy exists" is interesting. Although there may = be domains that send email but not receive email and so may not have an = MX record. Also, even if there is no SPF record, the domain may still = send email, but then it might be held to a more stringent DMARC policy = that would further penalize it for not having an SPF record. =20 Also, for the revision of the document I like the way that the three = parts of the experiment are now laid out more clearly. My only comment = is that the title of Appendix A is overly specific to just one of the = experiments and so should be broader. =20 Thanks, =20 Eric Chudow DoD Cybersecurity Mitigations =20 From: Doug Foster Sent: Tuesday, November 17, 2020 9:46 AM To: 'IETF DMARC WG' Cc: dmarc-chairs@ietf.org Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: = Definition of NP =20 I did not see a definition of a "non-existent domain" (the np policy). = A definition is needed. =20 To my thinking, the obvious rule should be to query for a NS record for = the domain. If the record exists, then the domain owner could create a = DMARC record for that domain, or could create a default entry for the = domain at the organizational level. If no record exists, it is because = the domain owner chose to not create one. =20 However, the DMARC Bis document conflicts strongly with this. In = section A.4, it suggest several ways to do a test of this type, then = repudiates all of them. NS lookup is not one of the mentioned options. =20 There is a possible second-level policy test for a "mail-enabled = domain". I would define that test as "MX record exists or SPF policy = exists". That could be an additional option to NP, but should not be = a replacement for it. =20 PSD for DMARC clearly intends for the NP policy to be a general solution = to a general problem. If there are still objections to it becoming a = general solution, this should be addressed soon. =20 Doug Foster =20 =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski Sent: Friday, November 13, 2020 1:42 PM To: IETF DMARC WG Cc: dmarc-chairs@ietf.org Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd =20 =20 All =20 During the IESG reviews of draft-ietf-dmarc-psd, there were several = issues raised with some of the document. Most of them are editorial = but the one big item was the description of the Experiment. The chairs = sat down and broke out the experiment section into three separate = experiments, and included language on how to capture the data to confirm = how the experiment worked.=20 =20 It's enough of a change that we wanted to do a second working group last = call to make sure the working group agrees with our changes. The diff of = the current version with the previous version is here:=20 =20 = = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-dmarc-psd-08&url2=3Ddraft-= ietf-dmarc-psd-09 =20 This starts a *one* week second working group last call for = draft-ietf-dmarc-psd Please review the changes and offer up comments to the working group. =20 This working group last call 20 November 2020 =20 Thanks, =20 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ------=_NextPart_000_00D1_01D6C19E.90AD2C30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I was misinterpretation the language to require detection whether any = host existed in the zone, rather than checking whether there is a host = name which matches the domain name.=C2=A0 Thank you to Murray for = straightening me out.

 

That aside, we still have a problem.=C2=A0=C2=A0 The specification is = applying SPF-type logic to an address that has no necessary connection = to SPF.=C2=A0=C2=A0 A typical advertising message, sent be a third = party, will pass SPF using the third-party sender=E2=80=99s = domain.=C2=A0=C2=A0=C2=A0 The message From address becomes a label to = identify the client organization in some manner, and possibly to = identify the identity of the marketing campaign.=C2=A0 The domain name = used for that purpose may not exist anywhere else, often does not accept = replies, and may not exist as a mail server domain = anywhere.=C2=A0=C2=A0=C2=A0 Consequently, these may very well be = unregistered domains, but it may be reasonable to insist that domain = owners get them registered to avoid false positives from the = test.=C2=A0=C2=A0 The least disruptive test will be for NS.=C2=A0=C2=A0 = Anything stricter will produce false positives.

 

The logic that seems to work is:

-          = Check SPF and DKIM for domain alignment.=C2=A0=C2=A0 If the DMARC = criteria are satisfied by either method, the message domain does not = need to exist, because it has been validated.

-          = If the message does not pass DMARC alignment, then we need to look = for a DMARC policy to see if P/SP/NP applies.=C2=A0 If NP applies, and = NS does not exist, the NP policy is applied.

 

Using the example domain from the document, I am assuming that we are = trying to block all three of these non-existent = domains:

-          = T4x.gov.example

-          = Spammer.t4x.gov.example

-          = Spammer.tax.gov.example

If the goal is only to block t4x.gov.example, then the current NP = algorithm is slightly less problematic.

 

Doug Foster

 

 

From:= = Tim Wicinski [mailto:tjw.ietf@gmail.com]
Sent: Thursday, = November 19, 2020 11:04 PM
To: = fosterd@bayviewphysicians.com
Cc: IETF DMARC = WG
Subject: Re: [dmarc-ietf] Second WGLC for = draft-ietf-dmarc-psd: Definition of NP

 

Doug

 

In looking for domain presence most = folks will look at the domain itself.  There are a few web tools to = enumerate

 

Some = examples

 

There are unix tools - such as 'dig' = - which are also quite useful.

 

hope this = helps

tim

 

 

On = Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster <fosterd=3D40bayviewphysician= s.com@dmarc.ietf.org> wrote:

Time to show = my ignorance again.

 

How do I = check a domain for presence or absence of A, AAAA, or MX = records?

I thought = most domains were protected from enumeration, so one had to know a name = to find out if it is defined

 

DF=

 

 

From: = "Douglas E. Foster" <fosterd@bayviewphysicians.com>
Sent: = 11/19/20 9:27 PM
To: = "IETF DMARC WG" <dmarc@ietf.org>
Subject: RE: = [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of = NP

 

Thank you = for the pointer Eric.

 

Can someone = explain why the chosen algorithm, which requires testing multiple = conditions, is preferable to a single query for a name server record? =   Minimizing DNS traffic has been part of our recent discussion, = and minimizing software complexity is always a good = thing.

 

Can someone = also explain why the DMARC appendix takes such a strong stance against = all queries for non-existent domains, regardless of technique?  It = seems like the philosophical incompatibilities need to be addressed = before both documents advance.

 

DMARC is = specified only as a test for the RFC5322.From domain.   = RFC5321.MailFrom domains may also be non-existent.  They will = return SPF NONE, but that is an ambiguous result, and SPF has no = organization default mechanism. =   

  • Is there = data to indicate whether evaluators have found that checking the = RFC5321.MailFrom for non-existence is useful? =   
  • Suppose that = the NP policy becomes generalized, and a domain has asserted a = "must-exist" DMARC policy.   Should a non-existent = subdomain used in the RFC5321.MailFrom address be treated = skeptically?

I can = imagine a scenario where a spammer uses a bogus subdomain of a = legitimate organization, in an attempt to get whitelisted by spam = filters which primarily evaluate the RFC5321.MailFrom address.   = This attack could be paired with an unrelated and non-DMARC RFC5322.From = address which is newly minted or otherwise not generally known to be = suspicious,   So my instinct is that some extension of DMARC to the = SMTP address will be beneficial.

 

Doug = Foster

 

 

 

 

From: = "Chudow, Eric B CIV NSA DSAW (USA)" <eric.b.chudow.civ@mail.mil>
Sent: = 11/19/20 5:31 PM
To: 'Doug = Foster' <fosterd@bayviewphysicians.com>, 'IETF DMARC WG' = <dmarc@ietf.org>
Cc: "'dmarc-chairs@ietf.org'" <dmarc-chairs@ietf.org>
Subject: RE: = [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of = NP

 

Section 2.7. = defines a non-existent domain as "a domain for which there is an = NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a = broader definition than that in NXDOMAIN [RFC8020]." This should be = sufficient for determining that the domain is not intended to be used = and therefore could have a more stringent policy = applied.

 

The idea of = looking for a "mail-enabled domain" based on if an "MX = record exists or SPF policy exists" is interesting. Although there = may be domains that send email but not receive email and so may not have = an MX record. Also, even if there is no SPF record, the domain may still = send email, but then it might be held to a more stringent DMARC policy = that would further penalize it for not having an SPF = record.

 

Also, for = the revision of the document I like the way that the three parts of the = experiment are now laid out more clearly. My only comment is that the = title of Appendix A is overly specific to just one of the experiments = and so should be broader.

 

Thanks,<= /o:p>

 

Eric = Chudow

DoD = Cybersecurity Mitigations

 

From: Doug = Foster <fosterd@bayviewphysicians.com>=

Sent: = Tuesday, November 17, 2020 9:46 AM

To: 'IETF = DMARC WG' <dmarc@ietf.org>

Subject: Re: = [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of = NP

 

I did not = see a definition of a "non-existent domain" (the np policy). =   A definition is needed.

 

To my = thinking, the obvious rule should be to query for a NS record for the = domain.  If the record exists, then the domain owner could create a = DMARC record for that domain, or could create a default entry for the = domain at the organizational level.  If no record exists, it is = because the domain owner chose to not create = one.

 

However, the = DMARC Bis document conflicts strongly with this.  In section A.4, = it suggest several ways to do a test of this type, then repudiates all = of them.  NS lookup is not one of the mentioned = options.

 

There is a = possible second-level policy test for a "mail-enabled = domain".  I would define that test as "MX record exists = or SPF policy exists".    That could be an additional = option to NP, but should not be a replacement for = it.

 

PSD for = DMARC clearly intends for the NP policy to be a general solution to a = general problem.    If there are still objections to it = becoming a general solution, this should be addressed = soon.

 

Doug = Foster

 

 

From: dmarc = [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim = Wicinski

Sent: = Friday, November 13, 2020 1:42 PM

To: IETF = DMARC WG

Subject: = [dmarc-ietf] Second WGLC for = draft-ietf-dmarc-psd

 

 

All

 

During the = IESG reviews of draft-ietf-dmarc-psd, there were several issues raised = with some of the document.   Most of them are editorial but the one = big item was the description of the Experiment.   The chairs sat = down and broke out the experiment section into three separate = experiments, and included language on how to capture the data to confirm = how the experiment worked. 

 

It's enough = of a change that we wanted to do a second working group last call to = make sure the working group agrees with our changes. The diff of the = current version with the previous version is = here: 

 

 

This starts = a *one* week second working group last call for =  draft-ietf-dmarc-psd

Please = review the changes and offer up comments to the working = group.

 

This working = group last call 20 November 2020

 

Thanks,<= /o:p>

 

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

------=_NextPart_000_00D1_01D6C19E.90AD2C30-- From nobody Mon Nov 23 10:49:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219D93A0C02 for ; Mon, 23 Nov 2020 10:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 aPSD4TJDxxx4 for ; Mon, 23 Nov 2020 10:49:35 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 E00E83A04BC for ; Mon, 23 Nov 2020 10:49:34 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id s63so5211570pgc.8 for ; Mon, 23 Nov 2020 10:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QFmxF3jqGKvLZ3lbRmFOg7dXkYek2g3zJvlWzBg8Dcs=; b=TQZWVN4tA8IPT5F0uO26BIBGT/TOSrbUaR+NX48teN4zKXlgT+eb/GV3z0yz0Vz6mM 5U9onnqLyd92NAL6st6RiRw0CgznSVAcVI/ObIR4b2/yvf1eGwcc4mRjMhp9ITajqSKP eXvU33fJUBGJ1/7UNVJMc3jC8FZPIdGkpB9wImOJ/FxkbvNUy066Giiw9sSImwG3yXME z5BCgERvrkFPIf8hLg+TEwYhOIzFk2KHw2K54etRnc4pzUz/uKwBi57zHhTxKC9w+zeM DbWry6qZDpg3JCyRUpCnnwJsQvoREk6w4Gz0LsuR+u8JcrnYsXMd/RvW/cFBlkHpTwvY WBvw== 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-transfer-encoding :content-language; bh=QFmxF3jqGKvLZ3lbRmFOg7dXkYek2g3zJvlWzBg8Dcs=; b=S4i72e+FuCns/L6SVTi9BUMM6XyIhRrfENlVhGDBDbXNNv8fS62CG9sVDHFg9TNpYD 6k/VjMIwLT5lvN+/gVWCJOUxqH7IOWadwIRuXjgRM4jooLOhDBW7lC3OvpLRuDkpm6Ke m6A1UQEVToQLLa56NWVxXEW1DFO4FaJnHTZvvnZhIgU2MLoNTaMoeVwG1t3XjhYp5Wem kyY64CPpLmaFpjQ6Va7M+Hibhzn2oxVBg+ZdVpsnzFwKiviojLSnijuCRSHBJUvlwh/L PM1LuTHednz4cuJyJcQTLCAoE3zjRzkwluWIiy/Wy3EzOYh/Rn5whRJwXdffNAIpv3vU 6pXA== X-Gm-Message-State: AOAM5330r0wFfXju/Yv+0rAKaWDVZsr+bBhj2Sy5fg0MdgM/usABZXYY PVTqAFcPH95NO7268kYR7jvZTcXEb7OmiQ== X-Google-Smtp-Source: ABdhPJzedOcE4+kBdVImVuOTfqi850qbpr48NITFkCVy3UBnyLbrXBTMBJqkB+mKligV+apGOyPSBw== X-Received: by 2002:a17:90a:4482:: with SMTP id t2mr336413pjg.44.1606157373761; Mon, 23 Nov 2020 10:49:33 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id v7sm12269989pfu.39.2020.11.23.10.49.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 10:49:32 -0800 (PST) To: John R Levine Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> From: Michael Thomas Message-ID: <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> Date: Mon, 23 Nov 2020 10:49:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 18:49:36 -0000 On 11/22/20 11:56 AM, John R Levine wrote: > On Sun, 22 Nov 2020, Michael Thomas wrote: >>> The ARC signature has a sequence number so you can track the chain >>> of custody.  You are right that it is similar to the DKIM signature >>> but the extra ovehead doesn't seem excessive. >>> >> Did the wg consider just grafting that onto the DKIM signature itself >> instead of having essentially a duplicate signature? Receivers are >> already supposed to ignore any tags they don't understand so it >> shouldn't hurt backward compatibility. > > ARC is an experiment that came from the people who designed DMARC.  > It's not a WG product. > > Having adapted the perl DKIM module to handle ARC signing and > verification, I can say that the extra signature is not a big deal.  > If you look at mail coming from large mail systems, they're full of > other junk headers and the extra overhead of AMS along with DKIM is > not important. > From what I can tell, the main thing that ARC is doing is binding an auth-res to a dkim signature-like thing. But as I recall -- it's been a long time -- there were ordering requirements ala received headers for where new dkim-signatures and auth-res go in the header. Assuming my memory is correct, that means you can reconstruct "what this looked like before i messed with it" already by signing the incoming auth-res as part of the new DKIM signature. Is there something more going on here? Mike From nobody Mon Nov 23 10:53:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AD23A0C46 for ; Mon, 23 Nov 2020 10:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2WW_r17GSPB for ; Mon, 23 Nov 2020 10:53:31 -0800 (PST) Received: from wmauth3.doit.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (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 A65C03A0C3F for ; Mon, 23 Nov 2020 10:53:31 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QK900NSKJ03G3L0@smtpauth3.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 23 Nov 2020 12:50:28 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-3, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.23.184217, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.19.5790001, SenderIP=[104.47.56.174] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JCRaL0jvJ5L0H46GUfvg7w3dx3cBBFSPov4mWlxsy3TTLzWRZI1aV4BhEQ4TkZT/sstyI/qgqK6aU/oIRmlXohMLp3oTHxXAgaEBmcrWMWK2+5w4f5XZ/y4ztqPo5Qn6DBRtHy+9K9SjxeNaC6dx6T1urJYElbKyfISFZTdSlg9gXvAKi6LupBsiGvRqzACdtNWXsBcnHiDVVYtugGhEDtclbGMSYoG+r2Szniji989f6nlK18JKaolnZfwrVScLvgmo6XRqA1GYyzaRczN/jXyJWgoTlVmTUHXCUICAsYr67ZLoK4d1oHG695AmfGgNa/n6K2ntXpw4Hg3UWKeMBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cLzioF8Nteo1KPeNQ02CYVw6DAbGn2f0IB951B4Uwxo=; b=hD0ScLAWYjdFHsYoEtUH9VKFP0GPsaBNj7urgCmYyPKrE2QC27dCO2BWdbluI+Mn0Rn7/Bsxw9lUW7LmCZw5MRBAQMeSrTQtt4bPCfQSTT1OxjbxerF08rujgNpjwMNdIvH2+FwjbzqVrV3BzIlvq1lIsvbDwRF+FOweXGfD41eZEnRFWDuibBtgo9QIwf1YtwX8aLF/hupiSrMj7Mi6VrGSyRA7h3hnskgqvOTRBK986iySKHYsU7zpLglnrmQx2qIxxHJedtgzpCgo/1oegR1BZFi32vkXB/v1iu8p2zuQO0ZNHQioVuY+CHUDrY496U+8dtgaL3m8KSbIAxIBRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cLzioF8Nteo1KPeNQ02CYVw6DAbGn2f0IB951B4Uwxo=; b=CUZm5qOthYK0hrLCKVToU9JWg5iUlbzAFn0H649BH6xFRX7MbPh+onB3JCfISvrk2PVvvA0FXopyiV78vYzFR4eEqN1IVkH4jV0pD1/sbBlVuJHoFAYwMz6V/UDgFSOVawZOJ1Wq82Jw+QSBQ4AXIL+QukFF7XiebS5CYrh7C/o= Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by MWHPR0601MB3595.namprd06.prod.outlook.com (2603:10b6:301:7b::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.30; Mon, 23 Nov 2020 18:50:26 +0000 Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5%7]) with mapi id 15.20.3589.022; Mon, 23 Nov 2020 18:50:26 +0000 To: dmarc@ietf.org References: From: Jesse Thompson Message-id: <9e6bac98-47fa-92e3-8552-7f4839d37e60@wisc.edu> Date: Mon, 23 Nov 2020 12:50:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7bit X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH2PR20CA0022.namprd20.prod.outlook.com (2603:10b6:610:58::32) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR20CA0022.namprd20.prod.outlook.com (2603:10b6:610:58::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20 via Frontend Transport; Mon, 23 Nov 2020 18:50:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 3a660b18-a4c4-435e-4221-08d88fe0a42e X-MS-TrafficTypeDiagnostic: MWHPR0601MB3595: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /hQk3aom8MeM4Z209Grl/W7iSAD+op/ZZi3y4zufVuGV/llkWqj4JmXF1eXwkFgLTj5Lr+38vIUkEPJjAED9V11Df9iGdHp3KHJXT++A4EgzjSv697gWZYBnotsrpEXM0AkMX50/R2Iqkr1Ahn0X9RkZl5rEVmq8b27ezCoes6ZcshP/VM97NvuLYKQqB76u5t3EAUk9xZD3dA61IA9rRz67dB8lWoFtXTZRiKncbJfXs1Yd46VgrLE6NRNc2jaF3kmyZ8eMLdBoXZvbnrGr6ZKnqyq5TdOjVsfpCBNYC5N+9ID2m5k2Gemymi0a9RR48GQ5A7rVUs9L7aqBGnFkNs0C+6XfYlxluepXahGwpKIlrZUxEk2sjkdZpCNiErsHC18n4J6CkOvgwtKfP4H/QenUq62grye7rO9uNLx8b6x2YdUUULI9uK2sTUGjNp5yL5CYFzhNH2uUpUiGrSsCdo9hHgNx0dot17MEiNXUBio= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(396003)(376002)(346002)(86362001)(36756003)(44832011)(786003)(316002)(966005)(8936002)(66946007)(66476007)(26005)(6916009)(16576012)(478600001)(66556008)(8676002)(956004)(53546011)(6706004)(6486002)(75432002)(31696002)(2616005)(2906002)(83380400001)(31686004)(186003)(16526019)(5660300002)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?b2JoTmtERGpWMXhjWkM1Q29obkdjc0RMQ1ZKVm5XVkFNNk1ubXRuS3dYTExC?= =?utf-8?B?WEE2bm5pRVdFbGVITVgrOW9KeWVxQ0tLM2lWL3NLUUcyRGNoUDhpU3lyekQw?= =?utf-8?B?R2h0c1g2cXBTelBIZnpjU1lyaVZiVks1N3VaTmh0WWRCdnM5UUxWK0ZQL21S?= =?utf-8?B?ZjIwcmlRZ2RLRVd3ZHNVcXZob0xEVk9kOENKZzhqSmF4S2k3WnBSN09ESmEw?= =?utf-8?B?TmpYM1I5enVPa2ZZK1B1c0lKSFdqT2Y5T0kybXdBd0xSTTIvQ1c1SGdGVVZt?= =?utf-8?B?VGFhSnRrbk1HWFFVa3pxa3dUM3ViZmQ4N0lWWFM2cmNnVmJtUSs4VzJVcGZL?= =?utf-8?B?WURCM1I3RUFzQ1hURW1kZ1VMSWczRWt2SDVHckQrdFhFQ1gvQ0Nqa1FVS0Jh?= =?utf-8?B?aVRDd0twenBjVlpadWNpd0FxOWdKMVpVdGVvc2Fud2cveUVTT0IxcExwOEcz?= =?utf-8?B?Mkl3d1ZnZUZnTmNxNjNWNy9BYXgwU0loSHhpaFRGOEZmbnNTbjhxbTNQMmlp?= =?utf-8?B?YUQzS0tWTDAraTZXS09HUlRmWC9OaVRtQ0wzd3E2Ni9CeUdiNGdHZlNFaHJh?= =?utf-8?B?SUorRjBWbkJiWDhGdlJFNS9WSCtrNks3OVVYSlczTlVzcE91TGpWV2J6L2h6?= =?utf-8?B?REhoT05MbENQSXZhN0tETTIwSGk0OU1hTGFyR2dCMlcyUGtxS0o1SDVhWFhW?= =?utf-8?B?aVpOeEhRZ3Q2aXVBMlhoaFNlUTFCRUxtL0xnWklaRG84NEZQYmF1TWU5SUNx?= =?utf-8?B?YlUxd2NCVXhTRWJKWUUwaVkwUlpoVjJaZW5hNTFMTVcvU0lxZzQwSGNtWUh4?= =?utf-8?B?cGlFQXQyK0hKcWRxRFNHa3dmL0xxQjZ4Z3haNUQwTVZaRkJvUzBGVjBJSDJt?= =?utf-8?B?eEFmWDhIQlZuWVdsUk1HeWVIZUtCTmRmQnFEenBVRnlzN0NsQ3M2L3VmMlNV?= =?utf-8?B?RXU1OHNlc0JkNEtzbHZYbUJEQkVHN0xHVktHZlJiVlhXUWNBQ2ZuUmQxYTV1?= =?utf-8?B?L3ZsZnkzNnRDT3BtalVhdDFBc1ptRXA4R2lGMHBzSC9vTklvN0pGcDJxYWMx?= =?utf-8?B?QytQNzd2NkxmMm1BUnhLYnYxSHhyQ3FtQ0x1Z2paNG9kUnd2VDYvcS9iSGNC?= =?utf-8?B?NEJWR0lRVk0xYWcySEE3YXJLc3JCbEZ2Z1R3S3FoWlFmWDJocG0xNW8xYkUy?= =?utf-8?B?cmhOTXV0WStxZ0h2ai92WE5IMzFYQ0dvOTNpNDFTMHVWTWszTit6eXIwNkUw?= =?utf-8?B?cVlRR0E1Z0dIUkJhdGc5TGJqdnpUck5OelQ5cHpRL2pNaXIra0kwanNzSTZ0?= =?utf-8?Q?Gfp1C3a6Du6co/TM18HTWwD/BSOq6+VWp3?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 3a660b18-a4c4-435e-4221-08d88fe0a42e X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2020 18:50:26.4529 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: rLMchHvFOSbd88JJn9rt+73TYAim5NzFNsTwNiP07QsLlVmYIyMLUEV/DUbS+IDl5Fcfp1nFTsoSDegody1QyA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0601MB3595 Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 18:53:33 -0000 On 11/20/20 6:02 PM, John R Levine wrote: > Here's a draft about how DMARC might do a tree walk rather than look up an organizational domain in the PSL. > > https://datatracker.ietf.org/doc/draft-levine-dmarcwalk/ Would it help if there was a new DMARC policy tag to trigger the tree walk? It's still the same number of DNS lookups, but changes the order and doesn't happen unless the organization wants it, so (aside from potential abuse) it should minimize the overall DNS lookup overhead. Look up _dmarc.sales.east.widgets.bigcorp.com - find no policy Look up _dmarc.bigcorp.com - finds a policy with a tw=1 tag Look up _dmarc.east.widgets.bigcorp.com - find no policy Look up _dmarc.widgets.bigcorp.com - finds a valid sp tag Is it also worth considering changing the direction of the lookups under the assumption that the consistency of/control over the sub-organization's sending practices increases with each branch? This would potentially reduce the number of DNS lookups. Look up _dmarc.sales.east.widgets.bigcorp.com - find no policy Look up _dmarc.bigcorp.com - finds a policy with a valid tw=true tag Look up _dmarc.widgets.bigcorp.com - finds a valid sp tag and no additional tw=1 tag Jesse From nobody Mon Nov 23 11:01:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D943A0C4D; Mon, 23 Nov 2020 11:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnGBIUqQcURp; Mon, 23 Nov 2020 11:00:58 -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 D71D33A0C31; Mon, 23 Nov 2020 11:00:53 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ANJ4Qkm022110 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 23 Nov 2020 11:04:26 -0800 Reply-To: dcrocker@bbiw.net To: Jesse Thompson , dmarc@ietf.org References: <9e6bac98-47fa-92e3-8552-7f4839d37e60@wisc.edu> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <77bbde18-5720-63ca-53b0-6b41f2ea60ed@dcrocker.net> Date: Mon, 23 Nov 2020 11:00:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <9e6bac98-47fa-92e3-8552-7f4839d37e60@wisc.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:00:59 -0000 On 11/23/2020 10:50 AM, Jesse Thompson wrote: > Would it help if there was a new DMARC policy tag to trigger the tree walk? policy tags are useful when one has a dmarc record that might contain it. the challenge here is to find that record. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 23 11:28:24 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E103A0CD6 for ; Mon, 23 Nov 2020 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=cRkZewNQ; dkim=pass (2048-bit key) header.d=taugh.com header.b=aL+dlJtM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqv2DC0RKGPB for ; Mon, 23 Nov 2020 11:28:20 -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 22A923A0ABD for ; Mon, 23 Nov 2020 11:28:19 -0800 (PST) Received: (qmail 50675 invoked from network); 23 Nov 2020 19:28:19 -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; s=c5f1.5fbc0d53.k2011; i=johnl-iecc.com@submit.iecc.com; bh=mG906e9dGSaEuddHYfmS8Y/G9z7x/FHU0MSsZC3aXpc=; b=cRkZewNQdFoMyunxTILlcG9ryih7UKKcgs4RjerA29StWI/Jt8BM9RVHfQDdAgLYf9dhK3s3rcXxf7Gfz/BdeAeFh/3spLZzjPMm9WogeoIie8kZ0AMxlV4PHCrtAuu/REY0m/JBhioF4Bi/1aMFgXVzgvN3AnnVxrt5A/WWT8rYQY6GCSS/zZeWPsoqe+KT3NJU++NhiAlqy1rL8T2dsWSEt4CzV6uaiEp9bpFxnFdlMd/lJr3azzQdeSEnabsKVY0NvZcLQxLJ7ei8sFJ/CXkfaFKgs1RdrQd1mcd4oG0jD3T4wNQaxzFIRR/jrcgb4UH1U0wkX0hKbeQcD3kfMw== 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; s=c5f1.5fbc0d53.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=mG906e9dGSaEuddHYfmS8Y/G9z7x/FHU0MSsZC3aXpc=; b=aL+dlJtMxG+GAo9XHEVlTpjpQfgYh+uno2vzC/sqm7At5x9nUiPUFOs7MIuA4H4zjoN5X3J8Yx7DuAT2LrBtb2Wc6vpIM1+5s/yuwxRI15FMFdJ7eLEDfKKIzs0zRsPnvh0qrFzxwtnr8pzRMUZdpLzA8gX6GsAcG+lYNqmp3VuUmyiaPO5Tsq8x+MNHvyZzovWmI91BtLNR+2HVoFUeEgf4NSQi5YNCUKdG06FP10E7bK9gQmaoTK225QqyR8pKrLUJ8B3iKvGXpjG24DgVMcqRAs8okJgIRbKGbac60jcEEu4AuSCt3W+vzkHYiABozHMb5ZnV/OksQH5PL521mg== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 23 Nov 2020 19:28:18 -0000 Date: 23 Nov 2020 14:28:18 -0500 Message-ID: From: "John R Levine" To: "Michael Thomas" Cc: "dmarc@ietf.org" In-Reply-To: <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:28:22 -0000 > From what I can tell, the main thing that ARC is doing is binding an auth-res > to a dkim signature-like thing. But as I recall -- it's been a long time -- > there were ordering requirements ala received headers for where new > dkim-signatures and auth-res go in the header. Assuming my memory is correct, > that means you can reconstruct "what this looked like before i messed with > it" already by signing the incoming auth-res as part of the new DKIM > signature. > > Is there something more going on here? Not really. There are ordering rules but mail systems do not follow them reliably, DKIM signatures in practice are not ordered. Also, A-R can be deleted in some situations, so ARC makes copies of them to be more robust in transit. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 23 11:29:48 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA33A0CD7 for ; Mon, 23 Nov 2020 11:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXsa4p_-6IGn for ; Mon, 23 Nov 2020 11:29:46 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 EF3AB3A0CD6 for ; Mon, 23 Nov 2020 11:29:45 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id x13so6027313uar.4 for ; Mon, 23 Nov 2020 11:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NQUP8T3wYCbRG8/H5QbHIh+LvLyic2kIrtswjuxMteo=; b=PVB0xho2E43IIP9d5lU7Jh2vrUav9sxoAojQwWyVgNvYAsK8X1A8iAhXdru+kabKUZ FPPkT3oSRK79X94KH/+ddPKqQHiVh/2N3ezP83wr8SKujQc881cRosIO8JJ14CChd5SZ MrAFJKC4vkMWH6tizKMYMl+NRqv8tAlljZeFenwwN2ergp1qCgaEJF1XMprTDGhGnRTe rtSJQddaM0tFaBBRt/iK+hBrjxymqoKfoWuQV+jadCKuHhjiEnPoEEeQZ6xWVCK5pgYf UcQNyVTG8zmcp+sJMobHrFtlp+KO0VufsgEiQXKEeQqLHhuopmE4+NgV2LlLERhGkGNA YBCQ== 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=NQUP8T3wYCbRG8/H5QbHIh+LvLyic2kIrtswjuxMteo=; b=mWjWu/u1cedg3281tTDAysFpS7XPdcGc3gPlHXactWEhe8wfb2Ieuj8qNfbRNMM7v6 ZwQqBRo2XJKJhjJDGf6YQ20ckv9DersipiE1vJZXHq5t2XLuLnE01sDqegVS1Fy9ClL5 U/BkkKr/wsxxc4q0dVfBBASeXxesbpzG9s15dW/MKeAndiZy+Nc/F+TT1poubcwwPzFk RWa9zLAbNmV/Uc9t9EV93U/abssFckphbhwNh6ZbZiMrZdZh/+tGe/NHQs0B9QPRgfxe k8MDOeNyrYuSLWV6/eyTgIcNZ5ZIaz6b3YcnNc/5F8Qw0y8QvoPn9Cc4rrXd93ITHXgY FmyA== X-Gm-Message-State: AOAM531XsijosO+syqqBRWOrPViPFxucdvhpCX7H+MYxxtmX/02ZYwgw scHsJKM9r4vfZhGDDPbA0SmDmF33l1r6tbuibNHhvWd7UQ== X-Google-Smtp-Source: ABdhPJwki/mWnDJXv4aGLR0Vddn8HOi4vE2GFkf3cU76fwYg6RPOdMBRwKr2aGKtit57uMuQoNokQNwNAn7pklCttms= X-Received: by 2002:ab0:13f1:: with SMTP id n46mr1106295uae.10.1606159784692; Mon, 23 Nov 2020 11:29:44 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> In-Reply-To: <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> From: Brandon Long Date: Mon, 23 Nov 2020 11:29:32 -0800 Message-ID: To: Michael Thomas Cc: John R Levine , "Kurt Andersen (b)" , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006bdd9805b4cb37d2" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:29:47 -0000 --0000000000006bdd9805b4cb37d2 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 22, 2020 at 11:29 AM Michael Thomas wrote: > > On 11/22/20 11:14 AM, John R Levine wrote: > >> Is there a reason that there is a separate ARC-signature rather than > >> just using the DKIM signature that is normally created for the new > >> message? Since ARC is new, you'd not want the intermediary to stop > >> DKIM signing the message so you end up with essentially two > >> signatures doing essentially the same thing? > > > > The ARC signature has a sequence number so you can track the chain of > > custody. You are right that it is similar to the DKIM signature but > > the extra ovehead doesn't seem excessive. > > > Did the wg consider just grafting that onto the DKIM signature itself > instead of having essentially a duplicate signature? Receivers are > already supposed to ignore any tags they don't understand so it > shouldn't hurt backward compatibility. > The DKIM-Signature is an "ownership" thing, it's a message originator that is saying "associate this message to me". Intermediaries don't want to take ownership of the message in that sense, though there are some mailing lists that do. So, if Google added a DKIM signature as google.com to all of the messages going through it, that would not be good. Even if the new tag indicated "I don't own this", it doesn't change the existing receivers who haven't been updated. Brandon --0000000000006bdd9805b4cb37d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 22, 2020 at 11:29 AM Mich= ael Thomas <mike@mtcc.com> wrote= :

On 11/22/20 11:14 AM, John R Levine wrote:
>> Is there a reason that there is a separate ARC-signature rather th= an
>> just using the DKIM signature that is normally created for the new=
>> message? Since ARC is new, you'd not want the intermediary to = stop
>> DKIM signing the message so you end up with essentially two
>> signatures doing essentially the same thing?
>
> The ARC signature has a sequence number so you can track the chain of =
> custody.=C2=A0 You are right that it is similar to the DKIM signature = but
> the extra ovehead doesn't seem excessive.
>
Did the wg consider just grafting that onto the DKIM signature itself
instead of having essentially a duplicate signature? Receivers are
already supposed to ignore any tags they don't understand so it
shouldn't hurt backward compatibility.

<= div>The DKIM-Signature is an "ownership" thing, it's a messag= e originator that is saying
"associate this message to me&qu= ot;.

Intermediaries don't want to take ownersh= ip of the message in that sense, though there
are some mailing li= sts that do.

So, if Google added a DKIM signature = as google.com to all of the messages goin= g through
it, that would not be good.=C2=A0 Even if the new tag i= ndicated "I don't own this", it doesn't change
= the existing receivers who haven't been updated.

Brandon
--0000000000006bdd9805b4cb37d2-- From nobody Mon Nov 23 11:34:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6BE3A0CF8 for ; Mon, 23 Nov 2020 11:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 kzk59fh8jXmn for ; Mon, 23 Nov 2020 11:34:05 -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 2988F3A0CFA for ; Mon, 23 Nov 2020 11:34:05 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ANJbZ72026825 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 23 Nov 2020 11:37:35 -0800 Reply-To: dcrocker@bbiw.net To: Brandon Long , Michael Thomas Cc: "dmarc@ietf.org" , "Kurt Andersen (b)" , John R Levine References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 23 Nov 2020 11:33:53 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:34:09 -0000 On 11/23/2020 11:29 AM, Brandon Long wrote: > The DKIM-Signature is an "ownership" thing, it's a message originator > that is saying > "associate this message to me". That is not DKIM's semantics: "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name" This says nothing about whether the organization has anything to do with origination. There is nothing to prohibit or preclude handling agents other than the originator from signing. > > Intermediaries don't want to take ownership of the message in that > sense, though there > are some mailing lists that do. Signing with DKIM does not take 'ownership'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 23 11:34:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F4A3A0CF4 for ; Mon, 23 Nov 2020 11:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdzV8rp7WvQQ for ; Mon, 23 Nov 2020 11:34:39 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2D93A0CEF for ; Mon, 23 Nov 2020 11:34:38 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id r14so9747277vsa.13 for ; Mon, 23 Nov 2020 11:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wzmOB2/rWfizm4kICkSpiNRBYlDsv6FWNZGcWp9QPNg=; b=uIPsjubNmBRYVVQ59rzguoDWLpkJ1MYBOKjIe5m7U9f7nNtZiJe/NRPE/tjce205of iBxwDw1tAlAX2PA+z7PDxWzcHmrH7irYQH++sTHhnVOa63tisG7TTyGW3jvsW/n2uJN/ M4fMyWO7fRYrEzyrJhRbQXpUEjoT6ukPrFhjNFpBvFzJzBigpm5j2my0nnVQzubgksgO M0qH9DD9sM4/3kJ3z3Lazsyi5kwoZszrAHyVNQF1cOpJjRNqw55klvY5kq0W9f6vj9j5 Mik474pqtHj8SLzx2d6fZnZBNDUqmeyX8YqafngjvxHis8XdG0nbWn8x9hWkAycdV5Le blBA== 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=wzmOB2/rWfizm4kICkSpiNRBYlDsv6FWNZGcWp9QPNg=; b=YSD7+lA/n+FTiEfC3xJP/3RsRFM3B6Kiy5t/ftfmSHUCETJWhx7qsqJXwe/ikftd3a KbsIgjOhJQnlOzaQc+uv9A0JS6H1cYxeuAVpzetTu56rIsiHcrtraaszbwx3PU3UH8gH gO/4yF6VpVYCrfKdXuKGwao1c2KV2KnH16nwpHGA026oWCul1zUE5uba3K0ClWw0LjCO 7yorh05+838t4kUyODcSvfl2Am6YHWTgPAlNBRCQ6VJ8cnWsamFm6Y0GUYipOEZp9p/r v/gYRo3ljc9L6mDXPHgHPdSo2CUp32TPjK6RrJyxGaYjdEzz0fmPY/82dWtchEC/HxTn pTwA== X-Gm-Message-State: AOAM533WZ2wOw+zrJITyK5FyCBUKpHdtMX09H5wz1Tmn1s/yLMcIJ/Q9 zRDsmr/08Bit+yrmURIjdCjaSpQxsGhkp+5QLA05Q/ZBsg== X-Google-Smtp-Source: ABdhPJzPs9Rnv/D8iLaFYnuAh+cCy1q1YhXeBcL6H61Sq6TYgifh7D6b3uwNsu1xFfGBaaR7WCQDH1aj6vdxWWZXnqQ= X-Received: by 2002:a67:df8b:: with SMTP id x11mr1362973vsk.37.1606160077841; Mon, 23 Nov 2020 11:34:37 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> In-Reply-To: From: Brandon Long Date: Mon, 23 Nov 2020 11:34:25 -0800 Message-ID: To: John R Levine Cc: Michael Thomas , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e4cce405b4cb488b" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:34:40 -0000 --000000000000e4cce405b4cb488b Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 11:28 AM John R Levine wrote: > > From what I can tell, the main thing that ARC is doing is binding an > auth-res > > to a dkim signature-like thing. But as I recall -- it's been a long time > -- > > there were ordering requirements ala received headers for where new > > dkim-signatures and auth-res go in the header. Assuming my memory is > correct, > > that means you can reconstruct "what this looked like before i messed > with > > it" already by signing the incoming auth-res as part of the new DKIM > > signature. > > > > Is there something more going on here? > > Not really. There are ordering rules but mail systems do not follow them > reliably, DKIM signatures in practice are not ordered. Also, A-R can be > deleted in some situations, so ARC makes copies of them to be more robust > in transit. > Right, A-R is explicitly called out to be deleted in the RFC on inbound if the admd matches (so someone can't fake an A-R to you). Even if it's not fake, a message can go through multiple hops through the same admd and each hop have a different A-R result, but there is no mechanism for multiple A-Rs for the same admd having any ordering or such. >From the other direction, one could say that ARC is a superset of A-R and DKIM with different purpose, and you might be able to subsume them into ARC, but you couldn't build ARC out of the originals. Brandon --000000000000e4cce405b4cb488b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 11:28 AM John= R Levine <johnl@taugh.com> wr= ote:
> From w= hat I can tell, the main thing that ARC is doing is binding an auth-res > to a dkim signature-like thing. But as I recall -- it's been a lon= g time --
> there were ordering requirements ala received headers for where new > dkim-signatures and auth-res go in the header. Assuming my memory is c= orrect,
> that means you can reconstruct "what this looked like before i me= ssed with
> it" already by signing the incoming auth-res as part of the new D= KIM
> signature.
>
> Is there something more going on here?

Not really.=C2=A0 There are ordering rules but mail systems do not follow t= hem
reliably, DKIM signatures in practice are not ordered.=C2=A0 Also, A-R can = be
deleted in some situations, so ARC makes copies of them to be more robust <= br> in transit.

Right, A-R is explicitly ca= lled out to be deleted in the RFC on inbound if the admd
matches = (so someone can't fake an A-R to you).=C2=A0 Even if it's not fake,= a message
can go through multiple hops through the same admd and= each hop have a different
A-R result, but there is no mechanism = for multiple A-Rs for the same admd having
any ordering or such.<= /div>

From the other direction, one could say that ARC is a superse= t of A-R and DKIM with
different purpose, and you might be able t= o subsume them into ARC, but you couldn't
build ARC out of th= e originals.

Brandon=C2=A0
--000000000000e4cce405b4cb488b-- From nobody Mon Nov 23 11:42:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962893A0DB5 for ; Mon, 23 Nov 2020 11:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kutVn1CGnHUB for ; Mon, 23 Nov 2020 11:42:36 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 0ABF03A0DF6 for ; Mon, 23 Nov 2020 11:42:33 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id x11so9775565vsx.12 for ; Mon, 23 Nov 2020 11:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VwHpGvjBQxbjAc1v3bFlzo3iHu2j8G9m2zJvJKCpc7c=; b=daJBsQxbPEEtQ8g8Sx8zGYtm/jJ2CZDiqQFPn+8aKLGTcEyNNgw5nAZ1w6ZF4IR3Fu M5eZtO8UiXTEFoLXlfBw9b5/NYEneuGPtFXQUvNvCpyR6Teeyx9qB9Oq6mFBIWNDl8ab v6JQGkZM07DiCBQFyKmTH/hVcukkECAqy1sT5XkVeX3iSUJnemJNMaFoL+u4JC/be66A 8h+KmpUWazFZhe9NP01jhmIK0/z8o/K6mKPD8ZvBKON+UBgLjFx2Y2klvI/6YXnbVm3X zXYGmHfSU1VPBoztsV8ulsmopfrWjMqQL8hDQPAu5Qd28mTA4svoPY1J1dg5TpGF9wo/ IqJQ== 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=VwHpGvjBQxbjAc1v3bFlzo3iHu2j8G9m2zJvJKCpc7c=; b=V7lf4b+IR5tuETOAeq0LuFVxH9CP7EW/2bgkxokj8KIS83ccHBeYocSytytsaKEfDg PMRWa1dkYpoEuB5c73eucU5zldzPUtvHVoNconZyGojY2B/KQiD2qFyOZyL0PcYbG5es kvASg1tJWeMug/6boC15m3+RvhuQy3A5t6M2Ryu/RuUjWT1B0FcX5yllkdvvnUmAy9uX QLum6Ac+UYBD/YSx7geU4r7GntHaE0PtrTGYV9Zot3/C75i44SRGaIuhJ9poAcQb9PfJ 5jB0ThxQAPZOMJ9ESf+8NtY6O3kYztBf4vI+YXxG7O+nBnTuGZMA7UN1ElsOl7OIj37m lKYQ== X-Gm-Message-State: AOAM5302FxKYmSo/kbl2ec9fbwkjYsYlRb2zZwerc8DZSaMubBTSZ7GN A9NyGsZGAWomo4YFxDnrEy3O+7hB/TBX1/1WapUMgDNkww== X-Google-Smtp-Source: ABdhPJzGDyv9BCmK96EAXaJ7y5ac5gDa+SG1rOCDWmHC/K+5KJAzmiD3P3L8rIMwJUqRu5HedLn6X7L7R2K5cdvcFjk= X-Received: by 2002:a67:df8b:: with SMTP id x11mr1389895vsk.37.1606160551872; Mon, 23 Nov 2020 11:42:31 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> In-Reply-To: From: Brandon Long Date: Mon, 23 Nov 2020 11:42:19 -0800 Message-ID: To: Dave Crocker Cc: Michael Thomas , "dmarc@ietf.org" , "Kurt Andersen (b)" , John R Levine Content-Type: multipart/alternative; boundary="0000000000002601f605b4cb6560" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:42:45 -0000 --0000000000002601f605b4cb6560 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker wrote: > On 11/23/2020 11:29 AM, Brandon Long wrote: > > The DKIM-Signature is an "ownership" thing, it's a message originator > > that is saying > > "associate this message to me". > > That is not DKIM's semantics: > > "DomainKeys Identified Mail (DKIM) permits a person, role, or > organization to claim some responsibility for a message by > associating a domain name" > > This says nothing about whether the organization has anything to do with > origination. > > There is nothing to prohibit or preclude handling agents other than the > originator from signing. > Yes, of course, a handling agent can do it, but there are plenty of reasons why they shouldn't. > > Intermediaries don't want to take ownership of the message in that > > sense, though there > > are some mailing lists that do. > > Signing with DKIM does not take 'ownership'. > Yes, responsibility is the proper word. My point survives the word change. DKIM says the domain takes responsibility for the message, while ARC says the domain takes responsibility for evaluating the status of the message when they received and forwarded it. Brandon --0000000000002601f605b4cb6560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 11:34 AM Dave= Crocker <dhc@dcrocker.net> w= rote:
On 11/23/2= 020 11:29 AM, Brandon Long wrote:
> The DKIM-Signature is an "ownership" thing, it's a messa= ge originator
> that is saying
> "associate this message to me".

That is not DKIM's semantics:

=C2=A0 =C2=A0 "DomainKeys Identified Mail (DKIM) permits a person, rol= e, or
=C2=A0 =C2=A0 organization to claim some responsibility for a message by =C2=A0 =C2=A0 associating a domain name"

This says nothing about whether the organization has anything to do with origination.

There is nothing to prohibit or preclude handling agents other than the originator from signing.

Yes, of course= , a handling agent can do it, but there are plenty of reasons
why= they shouldn't.
=C2=A0
> Intermediaries don't want to take ownership of the message in that=
> sense, though there
> are some mailing lists that do.

Signing with DKIM does not take 'ownership'.
<= br>
Yes, responsibility is the proper word.=C2=A0 My point surviv= es the word change.

DKIM says the domain takes res= ponsibility for the message, while ARC says
the domain takes resp= onsibility for evaluating the status of the message when
they rec= eived and forwarded it.

Brandon=C2=A0
<= /div> --0000000000002601f605b4cb6560-- From nobody Mon Nov 23 11:46:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE953A0D47 for ; Mon, 23 Nov 2020 11:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 xhHr61zdxqRD for ; Mon, 23 Nov 2020 11:45:59 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 DE3BE3A0D44 for ; Mon, 23 Nov 2020 11:45:59 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id 18so9355052pli.13 for ; Mon, 23 Nov 2020 11:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/3r8PY7qQXrpEItm3TDgiO5QrNVuXF9infgfidIrMuY=; b=tA27iROcnwTJELH7lYlKRTM3FsiF7xASQ+tM4+i0WE9HSGBQFq2vmYoGA5S+7vhz4U 1L7CBkmYWXLkaiOpyfp2rIeZ5uyVRqQv8xGvmm5WgT0BftJbhBIb2qr7/ex8D48Sv47h EcJ78iSkgltc+hBn4XCEU9PMtfhII6DQso6WsOSMb+XQladAUjo6G8MMgYKJrnweghA1 kUflKAyDZCFljhsX+puXPZJ1ABhB9CBrT41zdkIQfvJy72rV/l831yoJppWoXTFqnUFs vJr8G5i76kZZHFXhLIa+kWaYBD5VdJecfInrLhXHQ4IoaDWuk+S0Fe7GsI5+tNclQVND FLcw== 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-transfer-encoding :content-language; bh=/3r8PY7qQXrpEItm3TDgiO5QrNVuXF9infgfidIrMuY=; b=UeS+McPGBv/BbXHNyrGO7toem/f8EHvHav2AAslov6eLhRi94No4L+H6muS489IOc+ VQip2oBDYmEnW32f60Y35RdAl0aZDk/PjrCTdG2FPywrXYR/O0tT3yj4S/BFazDOL9zH FZZXw6wLwFzwaIWkzGSLkVv37UjykxX6G5O6ffb1y/nJ+GYF8VbZqLO77MrjmO6ss4Wt 8IoxDuLmeRsL49XAGDFPnP5c5cRDx2oDLHUw8W4vwq/VA+CYKR5LQy0YdpqLerfh5ut2 SaNM8i6L5Y81CL9ly+63Q0DLakGJ+bdrPhtDdssxP/+zumdyC4s/mw1rSkSUzk9bFDIl z1jQ== X-Gm-Message-State: AOAM533+zwX5DEkVwHyh6cNVXkfsv3+DIjGA2mdSFMNcNVRurqMeTBtb c2B9MixBaFsLrKNirZxWGJnldE+ugIo+KA== X-Google-Smtp-Source: ABdhPJyTg1zpHwBeSa2KUZVJV3MrXw9nh/JbF+ho5Tx9W9dKQuTSfKceq5CHNo8JSZ2qxdkIKhYCDQ== X-Received: by 2002:a17:902:b689:b029:d8:f07f:7336 with SMTP id c9-20020a170902b689b02900d8f07f7336mr882219pls.53.1606160758864; Mon, 23 Nov 2020 11:45:58 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id q5sm10791219pff.36.2020.11.23.11.45.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 11:45:58 -0800 (PST) To: John R Levine Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> From: Michael Thomas Message-ID: <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> Date: Mon, 23 Nov 2020 11:45:56 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:46:01 -0000 On 11/23/20 11:28 AM, John R Levine wrote: >> From what I can tell, the main thing that ARC is doing is binding an >> auth-res to a dkim signature-like thing. But as I recall -- it's been >> a long time -- there were ordering requirements ala received headers >> for where new dkim-signatures and auth-res go in the header. Assuming >> my memory is correct, that means you can reconstruct "what this >> looked like before i messed with it" already by signing the incoming >> auth-res as part of the new DKIM signature. >> >> Is there something more going on here? > > Not really.  There are ordering rules but mail systems do not follow > them reliably, DKIM signatures in practice are not ordered.  Also, A-R > can be deleted in some situations, so ARC makes copies of them to be > more robust in transit. > If auth-res is sometimes deleted, why wouldn't we expect the arc auth-res to not be deleted too? I imagine that the vast majority of intermediaries that break signatures number exactly one extra domain, so it's not very hard to reconstruct the chain of custody from origin to destination. Assuming the intermediary resigns with the incoming auth-res, the destination can choose to believe that auth-res or not, right? Since this is an experiment, do we have an idea of what the rest of the problem is after the typical mailing list-like signature breakers are excluded? Mike From nobody Mon Nov 23 11:48:17 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25323A0D74 for ; Mon, 23 Nov 2020 11:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 r745t_oVVuA3 for ; Mon, 23 Nov 2020 11:48:14 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 CEED33A0D73 for ; Mon, 23 Nov 2020 11:48:14 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id s2so9365728plr.9 for ; Mon, 23 Nov 2020 11:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=2zYiKXIUR/LTPXWLwTkirYFGfp8XZvkF2iGkYXRTQsw=; b=HFDR1FHvdd0e3HDEq53ggu75vwLFkIYHwqiX9euQ6yBGRmLLDT28KwF5H5hBUZp3gJ xhqt+Pjnvz2ltEG0hQLQY+rfsgTdgcH221SCDDuckDjzZiqa1UKP7zJJ4QhZthwUnpmv EtiaeCix78AvMmK0FBV5nK0zWNGbbTJHba2SJWY+s8/z6tAKsLWieilUFy9GFvWTrQCV FzCa8k4wMGzemFgSt6EClIsC8oUYj8djT88ifdrAHdDSQK9YgUphAjsJbC61GniMdoWj vQzpC0+BOjt1KTSmMjG4B6tw7nSN7dmDsexE0HNil84RWEkm7QDYjMFjecn3EuxNy/uo l+Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2zYiKXIUR/LTPXWLwTkirYFGfp8XZvkF2iGkYXRTQsw=; b=hP1gt2MYBIn3UHms1zUsKdrWJwajopQKLXqsjkRrpHHjyLx4c/Dv2UtLTa8ANFykAM Qlq0u+TzUrmdw7RHNpH4qN9H/u0NmuMQVO5BcqpYCFu33nbbp3DWCFiQj7Lnd+bMJyGo GbeNOfoRpCERzGeO7D8zWd0TFxMfCz0Ay4Nz7/gEn772o8Y7sVdJGn0lgs2030ZmdTAl DY+wyyOeOywv9ZLzqaGgx4az2jwVm5ni5q+6MfmSGksX1Vg3wqd8cRO6bU8rDOF5y64q oBjKGe7xbQWbvJSTEfJnRsjajQpd65wYMJ1Ez7iOVxOOYwl9qtgUxTJvBi1I5yenCs37 0GfA== X-Gm-Message-State: AOAM532AS3Uo8YqTYtNX85dA0zvYXf1nYAM14dwwp4JbiWbUeptMy83f ytRJWZ0dFRzxQYjD6PA7jglUDA== X-Google-Smtp-Source: ABdhPJwDySC2F4UgkJfbfmqO2xSuHXBk+4pEbC+RioMJF9LUTr5+Qfba7LN1I5yLfa+JRn4a65eGNA== X-Received: by 2002:a17:902:328:b029:d7:eba5:83ce with SMTP id 37-20020a1709020328b02900d7eba583cemr851055pld.57.1606160894207; Mon, 23 Nov 2020 11:48:14 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id u6sm175160pjn.56.2020.11.23.11.48.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 11:48:13 -0800 (PST) To: Brandon Long , Dave Crocker Cc: "dmarc@ietf.org" , "Kurt Andersen (b)" , John R Levine References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> From: Michael Thomas Message-ID: <29a7f273-c04d-54a6-576f-3ba121918df9@mtcc.com> Date: Mon, 23 Nov 2020 11:48:11 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------792AC3873EC0C7E9FEDFD92C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:48:16 -0000 This is a multi-part message in MIME format. --------------792AC3873EC0C7E9FEDFD92C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/20 11:42 AM, Brandon Long wrote: > > Yes, responsibility is the proper word.  My point survives the word > change. > > DKIM says the domain takes responsibility for the message, while ARC says > the domain takes responsibility for evaluating the status of the > message when > they received and forwarded it. > But it can already do that be re-signing its auth-res. Mike --------------792AC3873EC0C7E9FEDFD92C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/23/20 11:42 AM, Brandon Long wrote:

Yes, responsibility is the proper word.  My point survives the word change.

DKIM says the domain takes responsibility for the message, while ARC says
the domain takes responsibility for evaluating the status of the message when
they received and forwarded it.

But it can already do that be re-signing its auth-res.

Mike

--------------792AC3873EC0C7E9FEDFD92C-- From nobody Mon Nov 23 11:50:03 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0096F3A0DAC for ; Mon, 23 Nov 2020 11:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NkhBEBwpaZ4 for ; Mon, 23 Nov 2020 11:50:00 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 6901B3A0DAB for ; Mon, 23 Nov 2020 11:50:00 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id r23so6059123uak.0 for ; Mon, 23 Nov 2020 11:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VayGHdhMaNcxuLtKeWBv9pgQHX/0m0ophukUUKfgk2A=; b=A/AJOyKwScxB/UQNHZYqI0Vpm8hS8st5lTsT/1zDor8ZmQ9/OWHwEaSk/a0wptSXJL JJpyGkqpmwnYMkB73z4Yh2oPySD3LOMCkyGfBUZfTrEfSbidZmnofh8kButAkXpM/eb4 bpbnmrawEfL9PcuWAlykot41QJM+ylRjNmRzdSlDYGZysO4KgQDaaM6gFSgPf32XIeul nzOP+VZaXIfQdZL9lNHczvTZxdISL7bziqlx0wMY3milWcUoMYjmxgpHP5BDP6ruPtGA dwFc42QYN4uSig10Orfov6DPZfsuMKIz3l2voSVy5+C3R/vijfJ88a3y54wMPNaRwUUp 6NSQ== 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=VayGHdhMaNcxuLtKeWBv9pgQHX/0m0ophukUUKfgk2A=; b=PhxaP+IisNOgo646zI8EE56dVhzQi6E9a7PB70yUn7ffTxHBKVhF3yRVGb/rfpTjc3 CLRVj9qNavwnxa8H9UJtm+4DGUNSPl0Rn/YyBIUGhnvlpbQjHbfykg2H0I6AYAWb34Uq I2T9glDE9IQZZ6uilhtbjOivbz/fgB1tZq3RlIrd8Xk5cJpToh/v5XnwqpvbmRZEqcPD 92U3JuBx+YxRgNnx14UP3SPrVeIzU/MvPx/Xc6C6+88NRAgZKVVkC24o6NolVBxXp6dz bzM7l3t/FrZrcTuMS1idZpTv0uk36JQ+Oun0F+atHvcL6xNFoWZxogDP3YB0tFS6jVNB Cf4A== X-Gm-Message-State: AOAM532WLw9GHoBCaGBVCTaVnt+rEELkOS3XBjlDlsk3VubX3UG6zq8p Ii+xlYtb+WAiZ+LXlSVET0kpMBC96va5nmQ03Lt1 X-Google-Smtp-Source: ABdhPJxTy7h+u4sRyMPSO6mG3BBs1L+7fGQS7RBEAr64iKLUXEA9IMBO4vkSscHvdjyRgB2eoRXXIa/Xza64huZl+Xs= X-Received: by 2002:ab0:21da:: with SMTP id u26mr1167959uan.92.1606160999342; Mon, 23 Nov 2020 11:49:59 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> In-Reply-To: <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> From: Brandon Long Date: Mon, 23 Nov 2020 11:49:46 -0800 Message-ID: To: Michael Thomas Cc: John R Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d1e40405b4cb7f6c" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:50:02 -0000 --000000000000d1e40405b4cb7f6c Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 11:46 AM Michael Thomas wrote: > > On 11/23/20 11:28 AM, John R Levine wrote: > >> From what I can tell, the main thing that ARC is doing is binding an > >> auth-res to a dkim signature-like thing. But as I recall -- it's been > >> a long time -- there were ordering requirements ala received headers > >> for where new dkim-signatures and auth-res go in the header. Assuming > >> my memory is correct, that means you can reconstruct "what this > >> looked like before i messed with it" already by signing the incoming > >> auth-res as part of the new DKIM signature. > >> > >> Is there something more going on here? > > > > Not really. There are ordering rules but mail systems do not follow > > them reliably, DKIM signatures in practice are not ordered. Also, A-R > > can be deleted in some situations, so ARC makes copies of them to be > > more robust in transit. > > > If auth-res is sometimes deleted, why wouldn't we expect the arc > auth-res to not be deleted too? > > I imagine that the vast majority of intermediaries that break signatures > number exactly one extra domain, so it's not very hard to reconstruct > the chain of custody from origin to destination. Assuming the > intermediary resigns with the incoming auth-res, the destination can > choose to believe that auth-res or not, right? Since this is an > experiment, do we have an idea of what the rest of the problem is after > the typical mailing list-like signature breakers are excluded? > No, as in the RFC says to remove them, so it's a standard part of implementation. RFC 7601 4.1: > instances of the header field that appear to originate within the ADMD but are actually added by foreign MTAs will be removed before delivery. That's very different than "just maybe it might be removed" Brandon --000000000000d1e40405b4cb7f6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 11:46 AM Mich= ael Thomas <mike@mtcc.com> wrote= :

On 11/23/20 11:28 AM, John R Levine wrote:
>> From what I can tell, the main thing that ARC is doing is binding = an
>> auth-res to a dkim signature-like thing. But as I recall -- it'= ;s been
>> a long time -- there were ordering requirements ala received heade= rs
>> for where new dkim-signatures and auth-res go in the header. Assum= ing
>> my memory is correct, that means you can reconstruct "what th= is
>> looked like before i messed with it" already by signing the i= ncoming
>> auth-res as part of the new DKIM signature.
>>
>> Is there something more going on here?
>
> Not really.=C2=A0 There are ordering rules but mail systems do not fol= low
> them reliably, DKIM signatures in practice are not ordered.=C2=A0 Also= , A-R
> can be deleted in some situations, so ARC makes copies of them to be <= br> > more robust in transit.
>
If auth-res is sometimes deleted, why wouldn't we expect the arc
auth-res to not be deleted too?

I imagine that the vast majority of intermediaries that break signatures number exactly one extra domain, so it's not very hard to reconstruct <= br> the chain of custody from origin to destination. Assuming the
intermediary resigns with the incoming auth-res, the destination can
choose to believe that auth-res or not, right? Since this is an
experiment, do we have an idea of what the rest of the problem is after the typical mailing list-like signature breakers are excluded?

No, as in the RFC says to remove them, so it's = a standard part of implementation.

RFC 7601 4.1:
instances of the head= er field that appear to originate within the ADMD but
are actually added by foreign MTA= s will be removed before delivery.

That'= ;s very different than "just maybe it might be removed"

Brandon=C2=A0
--000000000000d1e40405b4cb7f6c-- From nobody Mon Nov 23 11:53:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36BC3A0E14 for ; Mon, 23 Nov 2020 11:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjeNPA3usvyt for ; Mon, 23 Nov 2020 11:53:15 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 9D0163A0E18 for ; Mon, 23 Nov 2020 11:53:15 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id q10so15943954pfn.0 for ; Mon, 23 Nov 2020 11:53:15 -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=Q34zU3suZ/TpWHBfD8NLiZ8nJT24i70LGDcYE95PyDI=; b=gF/2Utm0qMEz0zFwjhutrGCn6RM1ApCTY6See57Wr4GwnE4HkyKZfEeBXP+j0jBR5x qx8B6ayjZWMfA5wjo5VY8AC3Zzak1R4+XmBPQ5nFg/hwzlvalMCr+KkGiu5twngA6q7c TJaWlSsvl6K+fBL2PLCSxiFZLuEv9pS0eFgzlG2hz85Wvvl1zTu6wztXTjC8dyNDdKci 2Q25LooCn53B47jnDhQDp4GKLjJ7rSKklydor5n0OfI7IlyN3yB6UB6Y8DelETD0SG9N crIYhst5ruoOYdrPfNza724M1fjnPbbK2ubY87RipZSFU3SEYNJd2Ms7kbCm4tyxW/6z otAA== 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=Q34zU3suZ/TpWHBfD8NLiZ8nJT24i70LGDcYE95PyDI=; b=WnuY9I7THn1w0tODydR2Lr0URvclRBoewKyoGS2uljBDtW6ne0Umc7L2gptOVDQdR0 hghAitHPdjN4XoXcRaN1ogYG8T/msWBvviAuLAZG49vRv+A1sxXXcwKDpuLR28IKovBG tsC5YXYpaKeBwaS0qWUZj9xmOwLlusgdeZteXKw/qE9q0pRgxvcKwNxk8dBLLyPM7AUG gN/B+w9HKdlVg+knWoddcDmRL4Rh9qIMGNycxfGppSLwymy333atiCM4MzDL6+kyU617 v0k9Quyg7F0nUCZWdtCRLvwtjmdcHZwrxr3GJmpHaD9hCTX4v87KFYVSS81f5MFUYUwA Zs0w== X-Gm-Message-State: AOAM533yr5wQrWd+7UavplxWNF8lfyE8PHo5YX8AefqFAZwyf/tH9xig RtnNAqDibvDmLI5Zw/I/8aYOxImFdIs= X-Google-Smtp-Source: ABdhPJwoCRthvuwMRPTVylEk3/hZaP95rkNY34DHw8lr0lhbcu5PHINFqIOxDDNJbRIzBXIsM2Teuw== X-Received: by 2002:a65:5948:: with SMTP id g8mr871529pgu.51.1606161194890; Mon, 23 Nov 2020 11:53:14 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id h7sm5288031pgr.33.2020.11.23.11.53.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 11:53:14 -0800 (PST) To: Brandon Long Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> From: Dave Crocker Message-ID: <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> Date: Mon, 23 Nov 2020 11:53:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:53:17 -0000 On 11/23/2020 11:42 AM, Brandon Long wrote: > > > On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker > wrote: > > On 11/23/2020 11:29 AM, Brandon Long wrote: > > The DKIM-Signature is an "ownership" thing, it's a message > originator > > that is saying > > "associate this message to me". > > That is not DKIM's semantics: > >     "DomainKeys Identified Mail (DKIM) permits a person, role, or >     organization to claim some responsibility for a message by >     associating a domain name" > > This says nothing about whether the organization has anything to do > with > origination. > > There is nothing to prohibit or preclude handling agents other than the > originator from signing. > > > Yes, of course, a handling agent can do it, but there are plenty of reasons > why they shouldn't. Please enumerate and explain. If it's that dangerous, we should document it, especially I don't recall that constraint being in any of the design or standardization discussions. > > Intermediaries don't want to take ownership of the message in that > > sense, though there > > are some mailing lists that do. > > Signing with DKIM does not take 'ownership'. > > > Yes, responsibility is the proper word.  My point survives the word change. I disagree. > DKIM says the domain takes responsibility for the message, while ARC says > the domain takes responsibility for evaluating the status of the message > when > they received and forwarded it. This implies that the word 'some' is irrelevant. It isn't. And it was included intentionally. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Mon Nov 23 11:55:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496BC3A0E73 for ; Mon, 23 Nov 2020 11:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 cDmrVtQYyOFo for ; Mon, 23 Nov 2020 11:55:27 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 A49AB3A0E6E for ; Mon, 23 Nov 2020 11:55:27 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id f17so6712813pge.6 for ; Mon, 23 Nov 2020 11:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=vOpwCcgv9N5+yEeKKCcOo9vjj9DflDaH1qhLD7ep1Ao=; b=azhSBY0q3/eaPzEMmaIVYe5zcEU1n1N9GonbQRPczaJVuewGPTxji2XqDZsta9M6NW mhO+V1kgrKn2AHnYkZ+DpRw2n4ygI6wpaGoAfgJMBut/L1VJb+xMo180HZOrNr7OLhsz pyxO66jBvb7hf4YGS8saQZT9+q2l3hPbTpRFbfvj7yPWKLScgnVe2rEeuQimxKslEctF o8yS5eQFIrA2w2CEcO07oEQ6EV8Zz3/zozbRnoS5NDSBop/xHaogt6V16MStR/f89yJ8 CV2Lht+bkAdv43VECWGMJLAaXM0xtl8NWWARud1n6KW6IoMYZrF1F1yLJWpfJIEqOl3Q xdlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vOpwCcgv9N5+yEeKKCcOo9vjj9DflDaH1qhLD7ep1Ao=; b=bZ3tpfFM6QvUDN71Yu0RpIS/dD+yFu++mMA+O16MWLcqi3SCl78e7Z54yiNnNlQ+4u tVS+7Nhpgnl3BqAjBsLp0NtbFsMpLYfA9R4zqvw15sLZ8H2n3KI1paGKwvMrnxQYXMLz MlaeTmX5JVjSEYxOyncO9dz5noCKh3z0GLYpLn8SG39sZ/7/q2WpbjvrcvGBka3PFsZC rGLZjSZmQnqMsDZtoedS4lrVjrk47gIMnA3k5bP8fBuQSvmmcIhUuDxytHbzs5Ryr97e P2igW573LMdZXW+KQ/o2s/qXOWCkLJPutNlxGe3NliTYc9wZKZgVl6S2SLLfknMn9EPr SpfQ== X-Gm-Message-State: AOAM5316KXkVGdMaKVXNwJ6DYHggsL8B/m7HGfCryKuU8S6VQQHOmC0A I2Suz743bT09ODRso+1URUp1m4tRR4TSQA== X-Google-Smtp-Source: ABdhPJxc6IQ+VdHTUj8rvS2uXs9WvQED8zR3vM8ttih8T3NouF/8PH4/rGJWhSROtqhwUxjrURqDlA== X-Received: by 2002:a63:f54c:: with SMTP id e12mr844649pgk.415.1606161326831; Mon, 23 Nov 2020 11:55:26 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id s6sm13139023pfh.9.2020.11.23.11.55.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 11:55:26 -0800 (PST) To: Brandon Long Cc: John R Levine , "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> From: Michael Thomas Message-ID: Date: Mon, 23 Nov 2020 11:55:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A82A0CEDA2C0A281905BD1BB" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:55:29 -0000 This is a multi-part message in MIME format. --------------A82A0CEDA2C0A281905BD1BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/23/20 11:49 AM, Brandon Long wrote: > > I imagine that the vast majority of intermediaries that break > signatures > number exactly one extra domain, so it's not very hard to reconstruct > the chain of custody from origin to destination. Assuming the > intermediary resigns with the incoming auth-res, the destination can > choose to believe that auth-res or not, right? Since this is an > experiment, do we have an idea of what the rest of the problem is > after > the typical mailing list-like signature breakers are excluded? > > > No, as in the RFC says to remove them, so it's a standard part of > implementation. > > RFC 7601 4.1: > > instances of the header field that appear to originate within the > ADMD but > > are actually added by foreign MTAs will be removed before delivery. > > > That's very different than "just maybe it might be removed" > The receiving MTA in the next domain doesn't have to discard the information before removing it. The act of removing it is so there isn't confusion about the ultimate auth-res, especially with MUA's. The incoming MTA is free to consider the previous auth-res just like it's free to consider the previous arc auth-res. Mike --------------A82A0CEDA2C0A281905BD1BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 11/23/20 11:49 AM, Brandon Long wrote:

I imagine that the vast majority of intermediaries that break signatures
number exactly one extra domain, so it's not very hard to reconstruct
the chain of custody from origin to destination. Assuming the
intermediary resigns with the incoming auth-res, the destination can
choose to believe that auth-res or not, right? Since this is an
experiment, do we have an idea of what the rest of the problem is after
the typical mailing list-like signature breakers are excluded?

No, as in the RFC says to remove them, so it's a standard part of implementation.

RFC 7601 4.1:
instances of the header field that appear to originate within the ADMD but
are actually added by foreign MTAs will be removed before delivery.

That's very different than "just maybe it might be removed"

The receiving MTA in the next domain doesn't have to discard the information before removing it. The act of removing it is so there isn't confusion about the ultimate auth-res, especially with MUA's. The incoming MTA is free to consider the previous auth-res just like it's free to consider the previous arc auth-res.

Mike

--------------A82A0CEDA2C0A281905BD1BB-- From nobody Mon Nov 23 11:58:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B3F3A03FB for ; Mon, 23 Nov 2020 11:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.249 X-Spam-Level: X-Spam-Status: No, score=0.249 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 v5DsfaNIiAWN for ; Mon, 23 Nov 2020 11:58:16 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 0C0A53A03FA for ; Mon, 23 Nov 2020 11:58:15 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id t8so15934259pfg.8 for ; Mon, 23 Nov 2020 11:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=9VlKUWE7TsHMj/4ORmHMw16DZBstrvSvdsZ6dNh2OrM=; b=eqvb85YwqGYA0wCTKWhWZsairxro3FN1HxsrHivSbHaxSh4HJxX3XCcHmEYJilf0f0 Ee9gbQmwT0JGUUGsJ9CmzebBzynA91jU4q0hUttYrq3JojCc1C13wyDmFWU2uYFpWRUm 2tOrxRtHO0CRKlu7zNK7YB6m/r4HifZWMzLCWKQn8d+7M/R51CkUvMcI81E1vCXln85e dprYLYVrnLoB68DnE+8qOel8h7Qytnkoa6VDLie0S5St8zk27DDwvNMB7tNxt+mrw49c 13As9SsBcnPk0hPTJbXtYKvt/Cg7QXlbZgaeq4vuiD4rP0SK7H162c0adDlxCoaoeSSV VfHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=9VlKUWE7TsHMj/4ORmHMw16DZBstrvSvdsZ6dNh2OrM=; b=aNyR32AGMZy1exFytPbXcU6D0DoV26bBIinIvSYL6tam7kNq/GUnfCSAIds65x8whC 6asGtqDl92iYqiLou3hDEZInRMvcZyDGCwvb8T3OW6Seo23qHMd6lJ074rk38jhy7bfU f8DNeTseLZaU0WlkZAo8tOaqvjV7dEL94Wwin7x3I+PoEqDy9tjk+8U5UATn3zB12G7A bVjhd8WGvxbZTs72U6W39T7ZR+ZP0sz+rRUnFiHq2yS99RCxjJ7NntvK5IsFq3zM5R2f yMWfIEp10CKpSMZAnvjhzExvblouV+me/Uv9aIS+iVCHrncTjzX7Gd3ddbldbsEvosmn iY/g== X-Gm-Message-State: AOAM532M69TxVXjnBb7Q9wqrqGK2XWtH04PHdXSkQU9m0ouYcE/N7hXU PVNzcf9xX5cZV5ghxd6iwb9cIeeMP3UnOw== X-Google-Smtp-Source: ABdhPJxLx8LXr1mNL1wHLCFj8xNH3qYuSv5cHCkEX4Ek3R4Mly+aQDxWnCzlOp4gnT2SpbuHhocs5g== X-Received: by 2002:a62:1ec7:0:b029:197:e012:19b with SMTP id e190-20020a621ec70000b0290197e012019bmr879999pfe.77.1606161495070; Mon, 23 Nov 2020 11:58:15 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id d68sm12973350pfc.135.2020.11.23.11.58.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 11:58:14 -0800 (PST) To: Brandon Long , John R Levine Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> From: Michael Thomas Message-ID: <0102f3db-7bb8-9434-354d-460cf4cf4fc4@mtcc.com> Date: Mon, 23 Nov 2020 11:58:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4519A799D05378AC180B8FF5" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:58:17 -0000 This is a multi-part message in MIME format. --------------4519A799D05378AC180B8FF5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/23/20 11:34 AM, Brandon Long wrote: > > From the other direction, one could say that ARC is a superset of A-R > and DKIM with > different purpose, and you might be able to subsume them into ARC, but > you couldn't > build ARC out of the originals. > It's seems to me that the superset involves explicitly binding an auth-res to a dkim-like signature. Is there more beyond that? Mike --------------4519A799D05378AC180B8FF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 11/23/20 11:34 AM, Brandon Long wrote:

From the other direction, one could say that ARC is a superset of A-R and DKIM with
different purpose, and you might be able to subsume them into ARC, but you couldn't
build ARC out of the originals.


It's seems to me that the superset involves explicitly binding an auth-res to a dkim-like signature. Is there more beyond that?

Mike

--------------4519A799D05378AC180B8FF5-- From nobody Mon Nov 23 11:59:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493DC3A064E for ; Mon, 23 Nov 2020 11:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hwLdrxtb1Va for ; Mon, 23 Nov 2020 11:59:16 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 D60153A0644 for ; Mon, 23 Nov 2020 11:59:15 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id k12so6040551uae.13 for ; Mon, 23 Nov 2020 11:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YhMpfSgWiwz5YwCTs4Myu+wBOJNSIrw04yPdCwBNE50=; b=cMxKGOug1nCXJ3drGDqFYlnvMFUSpHGMHze/2w3737MELTYRWM7KezWUSs+Vq+vF1r +D7gk5bjJx07vdf3+TDYLugwKW1m3qIxsfRLnTh/SRt7kxBiF4VFpc1XetMyohDg8A+I AX9LsF508IXRZCAT68RgHpW4+oSXwv78CnHmfpE3/i25ahtPuv6gDZZUlqLnHk+v05Fw FacElxE5TQoxNABMlrF1szqbsioK9Y6z8VrLXYUzSuhiVp7f5kS3nzAWc/35qt4wMxoi O57thhnWKZR5heV2DM7iPkw7Jorw4fa0x6EdLZLz1h4vkuFv9lP334XHVNAuW6HUcYMq +8KA== 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=YhMpfSgWiwz5YwCTs4Myu+wBOJNSIrw04yPdCwBNE50=; b=S4Yj1VXH1o36dymzyI67w0apGGfAHnKp8U4pv5PkDBSy4hy9M9ype4rABmdn+tt/D9 8F5/9basGnrYvvz19zmu/FJiqQafm+qVm9T1I8fWcZzyvyrQ6uSpxdYXifWWMZ12ECye 8RRomY6gWnteYMlmKZZW/HVO5fD/clJ8iFQRcplr+4NNS6UMSwJ21lEsCJXYzJjAFr3H mhzRsoKygZaazxttW4jQqwqQgdACxhvnbD1dirniVdfGV3x6LwDNY61/CcJ0MLn6M9c4 KwKoIRPO6/QyfM4no286Z3LDtV+vjRCK9KQcH/+1wMz0SBoXw+4IuoBBp+6mFVA06zG/ Hr6g== X-Gm-Message-State: AOAM531R072tp+dkKwKxN4dNvhSMHtQanBXAAqu3+vW7aOWyCAdDLMXN DvwezR31Yl6jltBxhjJGQHOce7H9nkJpUx/dlziW X-Google-Smtp-Source: ABdhPJw52ezHtjJqWB+TETPCRXjDoOLrdyfMJSDWhdWgUxKy9vCc38UCsEhiQEswF+AQ1JL8uTWuoTMS1ozgfaM0jWA= X-Received: by 2002:ab0:3b01:: with SMTP id n1mr1390313uaw.6.1606161554503; Mon, 23 Nov 2020 11:59:14 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> In-Reply-To: From: Brandon Long Date: Mon, 23 Nov 2020 11:59:02 -0800 Message-ID: To: Michael Thomas Cc: John R Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e8e81d05b4cba0ab" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 19:59:17 -0000 --000000000000e8e81d05b4cba0ab Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 11:55 AM Michael Thomas wrote: > > On 11/23/20 11:49 AM, Brandon Long wrote: > > > I imagine that the vast majority of intermediaries that break signatures >> number exactly one extra domain, so it's not very hard to reconstruct >> the chain of custody from origin to destination. Assuming the >> intermediary resigns with the incoming auth-res, the destination can >> choose to believe that auth-res or not, right? Since this is an >> experiment, do we have an idea of what the rest of the problem is after >> the typical mailing list-like signature breakers are excluded? >> > > No, as in the RFC says to remove them, so it's a standard part of > implementation. > > RFC 7601 4.1: > >> instances of the header field that appear to originate within the ADMD but > > are actually added by foreign MTAs will be removed before delivery. > > > That's very different than "just maybe it might be removed" > > The receiving MTA in the next domain doesn't have to discard the > information before removing it. The act of removing it is so there isn't > confusion about the ultimate auth-res, especially with MUA's. The incoming > MTA is free to consider the previous auth-res just like it's free to > consider the previous arc auth-res. > Which works for one hop. Brandon --000000000000e8e81d05b4cba0ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 11:55 AM Mich= ael Thomas <mike@mtcc.com> wrote= :
=20 =20 =20


On 11/23/20 11:49 AM, Brandon Long wrote:
=20

I imagine that the vast majority of intermediaries that break signatures
number exactly one extra domain, so it's not very hard to reconstruct
the chain of custody from origin to destination. Assuming the
intermediary resigns with the incoming auth-res, the destination can
choose to believe that auth-res or not, right? Since this is an
experiment, do we have an idea of what the rest of the problem is after
the typical mailing list-like signature breakers are excluded?

No, as in the RFC says to remove them, so it's a standar= d part of implementation.

RFC 7601 4.1:
instances of th= e header field that appear to originate within the ADMD but
are actually a= dded by foreign MTAs will be removed before delivery.

That's very different than "just maybe it might be removed"

The receiving MTA in the next domain doesn't have to discard the information before removing it. The act of removing it is so there isn't confusion about the ultimate auth-res, especially with MUA's. The incoming MTA is free to consider the previous auth-res just like it's free to consider the previous arc auth-res.

Which works for one hop.

Bran= don
--000000000000e8e81d05b4cba0ab-- From nobody Mon Nov 23 12:01:28 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4110D3A0879 for ; Mon, 23 Nov 2020 12:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaixkTiFdwWz for ; Mon, 23 Nov 2020 12:01:25 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 0FB6D3A0858 for ; Mon, 23 Nov 2020 12:01:24 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id x11so9806207vsx.12 for ; Mon, 23 Nov 2020 12:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hmETio1+2IhxneHjwjWB4gkE/ITM66IZlHnKj+CGlTU=; b=IekVX7yXoRLBxHrWH7Gt8LGMztb+sT8s5tWHF4BZ9nZMgSF005hrL2GYv4gy4Hz7wS eatJwUuXxRA5vWRhNlzxhTF7Y9Xkg1NlOweyU2LgCHtxoODW8Gd6CuseBd8J1i88PgBc XX3h+4OE20VtgxJXe3CrlpCEO4sRU1Jw2jPLKn7sPrm1lWyfDp2GSQ6j5U6pD0xfyj1s 64n0EzMMUzkg043XJGP68p7G6d0h5PFPwwiU2CPCpxxf00JcQEGmiQk3q3Alml7E66Me imP6RboiAoa5pjia3yXvGGpkj4vKu3wDD/44BT/DYoZNVJ7oOJ+mpMKaRn7Re7S9gMTy A8xA== 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=hmETio1+2IhxneHjwjWB4gkE/ITM66IZlHnKj+CGlTU=; b=p5WCUecU29m8urMLlbXjypWQ1ImoBHfef7zk4qPq88cg93NTEJVwD36RLNxIKZXSDV tKKh/abIb334RAVHA9dh7u69WUkFVchhUv3DR2a7IWmkL+lVbDxHEuoeA/jT1uC7AY/e zL+VwH7e6CTWTvC7tJhAotUPIbHKObwc6NLhjcdE3nDKXsOiMT+jgf4IQM9/ocsBd0su VY+F2oKRTackQ8tJmnmcVXbcnUxxZRUsL2y0vLM0GidJ2dW8Sl2cokvzaZsTQSv6eBCi GYWPaUHUJA1183vOgwAgSIn6kAXGckWuwQz3kwbjIsWGnJqNfyqw2lnCDh0MICnS5Y9w SYSQ== X-Gm-Message-State: AOAM53208aBaEK1HNP8xO6h7Dz6pRti0z9mIr+U1cKHyPwVXUp6atRY0 tMta7PJAZkUGo9NajLvdEbfXAowKHnDMymEh92Uw X-Google-Smtp-Source: ABdhPJy0VENbmEIJJoo6X0juikf17MeUbAwwROpLPs6UU9G/yeU90s+4qgCasLbXDGhKfuhANLOu2SsifgceiN7kptA= X-Received: by 2002:a67:e90d:: with SMTP id c13mr1307915vso.53.1606161683707; Mon, 23 Nov 2020 12:01:23 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <0102f3db-7bb8-9434-354d-460cf4cf4fc4@mtcc.com> In-Reply-To: <0102f3db-7bb8-9434-354d-460cf4cf4fc4@mtcc.com> From: Brandon Long Date: Mon, 23 Nov 2020 12:01:11 -0800 Message-ID: To: Michael Thomas Cc: John R Levine , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009c8abc05b4cba861" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:01:26 -0000 --0000000000009c8abc05b4cba861 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 11:58 AM Michael Thomas wrote: > > On 11/23/20 11:34 AM, Brandon Long wrote: > > > From the other direction, one could say that ARC is a superset of A-R and > DKIM with > different purpose, and you might be able to subsume them into ARC, but you > couldn't > build ARC out of the originals. > > > It's seems to me that the superset involves explicitly binding an auth-res > to a dkim-like signature. Is there more beyond that? > Right, explicitly binding auth-res to a dkim-like signature that survives through multiple hops. The dkim signature acts like an AMS i=0, and the auth-res is like the AAR max(i) Brandon --0000000000009c8abc05b4cba861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 11:58 AM Mich= ael Thomas <mike@mtcc.com> wrote= :
=20 =20 =20


On 11/23/20 11:34 AM, Brandon Long wrote:
=20

From the other direction, one could say that ARC is a superset of A-R and DKIM with
different purpose, and you might be able to subsume them into ARC, but you couldn't
build ARC out of the originals.


It's seems to me that the superset involves explicitly binding a= n auth-res to a dkim-like signature. Is there more beyond that?

Right, explicitly binding auth-res to a dkim-like signa= ture that survives through multiple hops.

The dkim= signature=C2=A0acts like an AMS i=3D0, and the auth-res is like the AAR ma= x(i)

Brandon=C2=A0
--0000000000009c8abc05b4cba861-- From nobody Mon Nov 23 12:11:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E933A16DD for ; Mon, 23 Nov 2020 12:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=HxbtufbE; dkim=pass (2048-bit key) header.d=taugh.com header.b=g3/sWXK7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmMFC-qnxxLh for ; Mon, 23 Nov 2020 12:10:55 -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 0A8C33A1146 for ; Mon, 23 Nov 2020 12:09:27 -0800 (PST) Received: (qmail 66032 invoked from network); 23 Nov 2020 20:09:26 -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; s=101ed.5fbc16f6.k2011; i=johnl-iecc.com@submit.iecc.com; bh=Hx/23O8VyXVHLFgrUQM7EPsEB//2secofggBFieHXvU=; b=HxbtufbEKIk7IT+xncJHPZ/YGuHP6GKBfD9e5NBi3H+eSYVXLY1bq7XvIh0qp14LYanLd26R7QjfZMqnc3gW7tVJ/nQhSupbUsfaY8HNIT57QUs14j1boCCLE10lcwL4Kon7k8hCUoUO2DlPJFP9hvrAQX2L2aNTjykKaoXJguyoAKxbw8hPhTfRvj0q3viwFnjxEO3d2uQ59vbjd1n33BtdTS40sjLdqNulEBggMhJvyWyS5ZWGVuE4XfRJcdL+uC0E38Jbq5ensR32z9jX3vL2xo/9HwunlAiz4seZckSwcm5sHv2v+6NeKtRMg9meubKQqN2ha6dlBJC9besKuQ== 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; s=101ed.5fbc16f6.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=Hx/23O8VyXVHLFgrUQM7EPsEB//2secofggBFieHXvU=; b=g3/sWXK7pXksxuMV3ofP0EZnFNN/SisQV5MrxHVnG+D8h9JjORsvxar33Pwv+P0L7yzNbhKfHNQFPvvDB6iphjvQR+Gce8wkhI4Tf4gFjDVq8gjMTJpzc0JCSVxDbe1aLE6MdiXV8PT7TeQyKd8Ehp+7Eck/RCgr4Eu7ULZmTm8A8S4+BOKoNz8UOsTjoyOwqBmjNmPAG4z7T329/I/C1JiCGRxN/ZcCCPDeqWTP0biQGocwYl1S3kQ30Yj9xHWgXziEJLfQtBXWAS5Z8Yae2Tmn4TeKFtLh6Wb5Ck4iKiicItTkQKBu2L0BoVUiNhoDQwta1ySQN3LQnbmyy1a2vA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 23 Nov 2020 20:09:26 -0000 Date: 23 Nov 2020 15:09:25 -0500 Message-ID: From: "John R Levine" To: "Michael Thomas" Cc: "dmarc@ietf.org" In-Reply-To: <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:11:03 -0000 > If auth-res is sometimes deleted, why wouldn't we expect the arc auth-res to > not be deleted too? Please see RFC 7001, section 5. > Since this is an experiment, do we have an idea > of what the rest of the problem is after the typical mailing list-like > signature breakers are excluded? Sorry, this question makes no sense. The point of ARC is to deal with the kind of breakage that mailing lists cause. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 23 12:15:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0823A0AAF for ; Mon, 23 Nov 2020 12:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f82TM1KjFBjV for ; Mon, 23 Nov 2020 12:15:30 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 3AB943A09FF for ; Mon, 23 Nov 2020 12:15:30 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id u24so9808257vsl.9 for ; Mon, 23 Nov 2020 12:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=izqBJUV7YSeRJTShUKa13BLKOI5uYFlqS8TxPSQpWS0=; b=SpT+qFzcZ+Z2ZzMgfYaUt9sVf5tTx99ETG7Ugt0njFmhRt2Lh5wgtpFa6CaiLmluJe dC/ASWo7UoU1QrKFwR4xOcn7KTiMmUU8YkpGnKSpSsll3Jo+ZnSVOh5k9nDwa4Sh21gm aI/Gl4kq114sZhUixzrWIPYiyujIgax5aOtK/0I1FgKbs/9ec5DUlmPJ9nJ/Dp3X3xb7 XyXCT8o+tCL4n+vIGkmudyPR+wkYKLcarrD7F0E1BXbp2ss/5pLOIkIOZE/3BreCDEX6 QNEjCK9IpnL9uTynt4PE2T6fvfHBIx2uRCs8F9E8NvJDyhOJvc75UgwXo/rRzs/gM6eT P0HQ== 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=izqBJUV7YSeRJTShUKa13BLKOI5uYFlqS8TxPSQpWS0=; b=SiqoE9Sn3U102eFB94f5YhrtyXkvvOolytTOOcs5dKpst5ZnzNLtq+YWavYV0ACqZg 2tbW+2fEzGpONKKzZaSrlmfwRjWEUl1O5B/gJywjUmoRGUkNqb2oyA+VmyNB7ivG+9S1 o3AatJOIcUCqs38I4LbD0ytil9fl67jcioo2NaKKfXTFdMmegwGdztxePPiMIuOPF02m 2ffUETwUUvqSQ/412777BFoi6khTYb/HMc3qit8RSnNqAkuswzYB0rrfJp1VPgUbuWWf Fg0RPvng7+Nh2KroYI0HOscJo2VdcftpEgrx6Ue0dziFq+BxMMEuar5AK1s/UWbiFAH1 eYuA== X-Gm-Message-State: AOAM533HbDlPfrV0SgSrnY2py8LGI7pd5KjXKIsMJQAXSZA2DY4MCZ5I pcShIAbSQpRFGetx0Zn4mZPB7alEnKYm9DP4uL0E X-Google-Smtp-Source: ABdhPJwx0BiJ7rPHtSIyRI4O0bjAbw/ZOuriM+F2sGsE6LKm+4N3L59Hkz7xAeD5N7TVrecIrH2pVjkZTsOyWU46L3w= X-Received: by 2002:a67:df8b:: with SMTP id x11mr1536798vsk.37.1606162528960; Mon, 23 Nov 2020 12:15:28 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> In-Reply-To: <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> From: Brandon Long Date: Mon, 23 Nov 2020 12:15:15 -0800 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fe016005b4cbda9e" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:15:32 -0000 --000000000000fe016005b4cbda9e Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker wrote: > On 11/23/2020 11:42 AM, Brandon Long wrote: > > > > > > On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker > > wrote: > > > > On 11/23/2020 11:29 AM, Brandon Long wrote: > > > The DKIM-Signature is an "ownership" thing, it's a message > > originator > > > that is saying > > > "associate this message to me". > > > > That is not DKIM's semantics: > > > > "DomainKeys Identified Mail (DKIM) permits a person, role, or > > organization to claim some responsibility for a message by > > associating a domain name" > > > > This says nothing about whether the organization has anything to do > > with > > origination. > > > > There is nothing to prohibit or preclude handling agents other than > the > > originator from signing. > > > > > > Yes, of course, a handling agent can do it, but there are plenty of > reasons > > why they shouldn't. > > Please enumerate and explain. If it's that dangerous, we should > document it, especially I don't recall that constraint being in any of > the design or standardization discussions. > DKIM often ties a domain to reputation and other anti-spam features. If you forward spam to another host and sign it while forwarding, then the other host will think you send spam. DMARC ties DKIM to the From header and at least is interpreted as being an anti-phishing feature. DKIM signing mail that you forward could mean upgrading a phishing message to passing DMARC. This recent article also goes into things that DKIM signatures imply: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ Perhaps this all means that DKIM has been used for more than it was intended for. > > > Intermediaries don't want to take ownership of the message in that > > > sense, though there > > > are some mailing lists that do. > > > > Signing with DKIM does not take 'ownership'. > > > > > > Yes, responsibility is the proper word. My point survives the word > change. > > I disagree. > > > > DKIM says the domain takes responsibility for the message, while ARC says > > the domain takes responsibility for evaluating the status of the message > > when > > they received and forwarded it. > > This implies that the word 'some' is irrelevant. It isn't. And it was > included intentionally. > Automated systems can't really tell how much responsibility an intermediary was intending to take for the message. OTOH, they typically are using it only for a certain purpose, so they assume that the intermediary took responsibility in the sense that they want... or rather, the people who wrote the code do. Or the journalist writing the story. ARC was specified to have a more specific responsibility, and as different from DKIM so that it wasn't mistaken for the uses that people were already using DKIM for. Brandon --000000000000fe016005b4cbda9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 11:53 AM Dave= Crocker <dcrocker@gmail.com&g= t; wrote:
On 11/= 23/2020 11:42 AM, Brandon Long wrote:
>
>
> On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker <dhc@dcrocker.net
> <mailto:dhc@d= crocker.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 11/23/2020 11:29 AM, Brandon Long wrote:
>=C2=A0 =C2=A0 =C2=A0 > The DKIM-Signature is an "ownership"= ; thing, it's a message
>=C2=A0 =C2=A0 =C2=A0originator
>=C2=A0 =C2=A0 =C2=A0 > that is saying
>=C2=A0 =C2=A0 =C2=A0 > "associate this message to me".
>
>=C2=A0 =C2=A0 =C2=A0That is not DKIM's semantics:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "DomainKeys Identified Mail (DK= IM) permits a person, role, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 organization to claim some responsib= ility for a message by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 associating a domain name"
>
>=C2=A0 =C2=A0 =C2=A0This says nothing about whether the organization ha= s anything to do
>=C2=A0 =C2=A0 =C2=A0with
>=C2=A0 =C2=A0 =C2=A0origination.
>
>=C2=A0 =C2=A0 =C2=A0There is nothing to prohibit or preclude handling a= gents other than the
>=C2=A0 =C2=A0 =C2=A0originator from signing.
>
>
> Yes, of course, a handling agent can do it, but there are plenty of re= asons
> why they shouldn't.

Please enumerate and explain.=C2=A0 If it's that dangerous, we should <= br> document it, especially I don't recall that constraint being in any of =
the design or standardization discussions.

<= div>DKIM often ties a domain to reputation and other anti-spam features.=C2= =A0 If you
forward spam to another host and sign it while forward= ing, then the other host
will think you send spam.

=
DMARC ties DKIM to the From header and at least is interpreted a= s being an
anti-phishing feature.=C2=A0 DKIM signing mail that yo= u forward could mean upgrading
a phishing message to passing DMAR= C.

This recent article also goes into things that = DKIM signatures imply:

Perhaps this all means that DKIM = has been used for more than it was intended for.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 > Intermediaries don't want to take ownersh= ip of the message in that
>=C2=A0 =C2=A0 =C2=A0 > sense, though there
>=C2=A0 =C2=A0 =C2=A0 > are some mailing lists that do.
>
>=C2=A0 =C2=A0 =C2=A0Signing with DKIM does not take 'ownership'= .
>
>
> Yes, responsibility is the proper word.=C2=A0 My point survives the wo= rd change.

I disagree.


> DKIM says the domain takes responsibility for the message, while ARC s= ays
> the domain takes responsibility for evaluating the status of the messa= ge
> when
> they received and forwarded it.

This implies that the word 'some' is irrelevant.=C2=A0 It isn't= .=C2=A0 And it was
included intentionally.

Automated syste= ms can't really tell how much responsibility an intermediary was
<= div>intending to take for the message.=C2=A0 OTOH, they typically are using= it only for a certain
purpose, so they assume that the intermedi= ary took responsibility in the sense that they
want... or rather,= the people who wrote the code do.=C2=A0 Or the journalist writing the stor= y.

ARC was specified to have a more specific respo= nsibility, and as different from DKIM so
that it wasn't mista= ken for the uses that people were already using DKIM for.

Brandon
--000000000000fe016005b4cbda9e-- From nobody Mon Nov 23 12:18:18 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728A83A0BFC for ; Mon, 23 Nov 2020 12:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 SkS-d0-atzo6 for ; Mon, 23 Nov 2020 12:18:15 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 569713A0BCC for ; Mon, 23 Nov 2020 12:18:15 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id l1so1165091pld.5 for ; Mon, 23 Nov 2020 12:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=GpbQ72wSaE58vTFhtB46DL9/KxF2S97ARuYVrHej2Mc=; b=CYUDCdmi6tF0DeET1mAQCptaCeOfXsblu5hKYgPilW2k+Of5MLG6bPwfC0ZSW1lOuk LkC/WgRTchTm2wMa1E+gWNCwZirsmvusxdEUOroDtWjyt568pDTTvtUPum1eUmbLxyA2 ygiCxN1Thnxu18pLDratgdGusQCB45r8CXTa99JIFufaLaRR8VrudtxyHsHn3Go+l/6E QcsnSw4pHJVgdMl+gbNKE5l9Xl0aplixf/J7BRCzkATlsblsowZzR+w9W97dqybeHvss wEoH6vvj3QbldZ7WbFDthrFZqzsygvSnKklM0czT/VhOcTsOgnqeH9lP2yXgqgcAuLii eQCQ== 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-transfer-encoding :content-language; bh=GpbQ72wSaE58vTFhtB46DL9/KxF2S97ARuYVrHej2Mc=; b=ecreqa+I4oJh0om15x7jAP8/gE6QzIel95iLgxx+P5ajms6mOa8qMocZ8s1OfWgDNE CucIrTrGvSNjnxP87g8YN0NTXI33OdAvy911eFgnwPctp4WJdKDghoTAdK7bIEuFfHHd Pzhwpf2CAnji0nLGeiIZHhSmmzY3K49Pofo3w4bMyc02wc9SEZ/XAd8UdkQufvsFG4Tn pGgvwjZR02MJfJOBc94sOZ8GLQLCs5Y+N6Ss9VGLcvqS8zw0JTOm/L9B801rrhVEbqAn goS8WGf32vDBWuapYYmwonDuMXnAyeHvePcxL8meRFuR4H4T9AwDiBdDfcbD5VZ9tzwY QzAg== X-Gm-Message-State: AOAM533SMhSVLLq1Vovx3+NKYLRFdlb5Bq9QRjkeAhHXNzoQae2yep6t FvdeeXhjaunwtNtbyaZCrvPllRqvN5++YQ== X-Google-Smtp-Source: ABdhPJxwz+N/rKJricbwdKm0HrjGWOW7Ma8XjH88zzwFlTg2puYev2JcrRf5SbCDp1v4mNiRJoVrhw== X-Received: by 2002:a17:902:6115:b029:da:1968:c734 with SMTP id t21-20020a1709026115b02900da1968c734mr537965plj.75.1606162694520; Mon, 23 Nov 2020 12:18:14 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id b17sm1073299pgs.61.2020.11.23.12.18.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 12:18:13 -0800 (PST) To: John R Levine Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> From: Michael Thomas Message-ID: <8db80384-c03f-109c-c2b4-7d4db96aa727@mtcc.com> Date: Mon, 23 Nov 2020 12:18:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:18:16 -0000 On 11/23/20 12:09 PM, John R Levine wrote: > >> Since this is an experiment, do we have an idea of what the rest of >> the problem is after the typical mailing list-like signature breakers >> are excluded? > > Sorry, this question makes no sense. The point of ARC is to deal with > the kind of breakage that mailing lists cause. > 1) A mailing list creates an auth-res on the incoming mail to the list 2) It modified the message 3) It resigns the message with DKIM 4) It is then delivered to the subscriber's mail server 5) The destination mail server can look at the incoming message including the mailing list's auth-res and decide whether to trust it or not just like ARC. It seems to me this covers the vast majority of cases. What are the other cases where this is not sufficient and how significant are they in reality? Mike From nobody Mon Nov 23 12:29:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1C93A0E29 for ; Mon, 23 Nov 2020 12:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=hHuA2Bmd; dkim=pass (2048-bit key) header.d=taugh.com header.b=I7R8Rkaf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NEj9HaNuvtA for ; Mon, 23 Nov 2020 12:29:53 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658983A0E27 for ; Mon, 23 Nov 2020 12:29:53 -0800 (PST) Received: (qmail 73405 invoked from network); 23 Nov 2020 20:29:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=11eba.5fbc1bc0.k2011; i=johnl-iecc.com@submit.iecc.com; bh=uW1tOhgqcxw055t7DhoKhtL2+CXImQN9uW+871Js56s=; b=hHuA2BmdIabmwNmcSh4QxC4t+BGwGm1ziOMsporFIBIKQ8NEv3VZmFCwrTgE9CmHkl/RQBx+TQgn6Ra2Pb3FAx/S/95d23PD27abgjBTG9bG0USg4I44Z7PWbguNIF7sTI8fXeiqEQqb13oiqqUw2hNZGsqDL4i/WBme7YUW14t8+AqRr6D+8ekSI1vEu3n3TGzpNRQRukf2d1kYWlBFmverbvVrcd88HwV80AXu7Ede5TQgh9YyWSP3Zn9BuZybigfxTsRTYy3/mZbNpOqrdJfaVyJqB5hV5EpgH6JcxaB1/d13x8vpD9zJ49I3DXF8tLzmZrnTU61teJU8oZ0L2g== 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; s=11eba.5fbc1bc0.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=uW1tOhgqcxw055t7DhoKhtL2+CXImQN9uW+871Js56s=; b=I7R8RkafRS/lF1q9PfrDSDVO28S6uxxUtF7wdrKMJf5PR0pbRDsaG6axzqdmrOlQYaPsyUA54YML+eeKHrPaXkN6I1qojkZGgADXTZww14AoeZe7NwhVyNRJsXS/NBl9EKTVq3Qs85xDUwf7/Le4BUgK8V6A49DOIZ7wud4xPf1SOFYgnioF2XFeZ/OOkNXiFmMK764AqGVv4q5IXnBIHfan7xlb1VmIRC+fX2H5aYen+vQTaCHpkLrLE6MqbRVzIh6JyMnthmbm/1a9ZPQnd7Jj48cSNFxM0BJ8qwcLMmcLrgRy1X405gZwio7oA/alh7JAyiGswTAnZ0W7AoRRVA== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 23 Nov 2020 20:29:52 -0000 Date: 23 Nov 2020 15:29:51 -0500 Message-ID: <53b21bdc-546c-c17c-5ec-d6b63ac2cb57@taugh.com> From: "John R Levine" To: "Michael Thomas" Cc: "dmarc@ietf.org" In-Reply-To: <8db80384-c03f-109c-c2b4-7d4db96aa727@mtcc.com> References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> <8db80384-c03f-109c-c2b4-7d4db96aa727@mtcc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:29:56 -0000 > 1) A mailing list creates an auth-res on the incoming mail to the list > > 2) It modified the message > > 3) It resigns the message with DKIM > > 4) It is then delivered to the subscriber's mail server > > 5) The destination mail server can look at the incoming message including the > mailing list's auth-res and decide whether to trust it or not just like ARC. > > It seems to me this covers the vast majority of cases. What are the other > cases where this is not sufficient and how significant are they in reality? Two or more levels of forward are quite common, particularly in large mail systems. Look at mail coming out of Google and Microsoft's hosted mail and you'll see a lot of ARC headers. Considering that the ARC RFC was published over a year ago, and it is implemented all over the place, could you explain what the point of this discussion is? The people who designed ARC are not idiots. If we could have fixed the mailing list problem with existing DKIM signatures, we would have. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 23 12:45:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2ED3A11A5 for ; Mon, 23 Nov 2020 12:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 zD2hxJaxiUmv for ; Mon, 23 Nov 2020 12:45:51 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 985403A11A2 for ; Mon, 23 Nov 2020 12:45:51 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id v21so15379932pgi.2 for ; Mon, 23 Nov 2020 12:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4Zvdew3QresgfjgO7CrQ6j7EiFtm6Lt3tgVDH8guOWY=; b=VwJcyG72oOYUatD9cb9gtdxFroxwucI9OeDcD4XyhfablzcW9dCNgv4UPhcALM3h8R OQwIZt+eX8BZ1jnOArOnFjpjzVTke33JKqndstA04GLom0mS7F4Yt/CxwGZhuQHxuv3L 8gu6Gx4yRraicWc/o9Pk8DcZsbeE19CNyKIzDUQXwuGzPKHlIAq40sv05PsfZPLPXhud z36SmkZn7oDaRAzEl9xpKl1tJyG0RKljTWZayhOm1Hzwx74JDKWfiOD8fmLRZ7iotdw8 MuEBRjPKuTOJ08nDK8LulZWJUHqtOTZOvwAE5GLKYQdhwpEMsb0YtlXwwvHaydjFeVV/ 6ngw== 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-transfer-encoding :content-language; bh=4Zvdew3QresgfjgO7CrQ6j7EiFtm6Lt3tgVDH8guOWY=; b=MwzL705Ek4ynWBc5tEUJYBkg7+u0ow75OPDvlvCH9PLkcB6w76wbihBOaXDNVjG3xD qu2IThBZtcZnqBIggTFOSVd0IKPXeX0lT9HejQjnixW4+1e5F2zYya+6mPNrK7lipOMX NFUAGK0abyDzET/9kclBfBISFcK4cOfmjlqs0mVweRYUYIhkbrN8uuuPdJ9WZu0xIhVs 1L+ovps+mM5TzYv9cKJYTRnTK7mD3hZdXnfZPETwMzkmd2dA4B7pDLmP2xKMAQlRjxOz /2A4FXneEU8vw/TSXzYMcSohLgj5smLn4UGPOVnufGVC+jyHC6Y3nCPWl+Dpibztw4r/ TU9g== X-Gm-Message-State: AOAM530Sy4Ac64uIBhtyS5/IQkG5YLiEcaZkIvmNLZHIXf7KrJmBlE6I lW4cZ3IZZcME58iKujDmjeJgAgQQSfEWJw== X-Google-Smtp-Source: ABdhPJzYdty6aXpOMnsMPY+S2ABxH42e6QnyPsACAIacXa4VNeSEVYU7lLWoP0YCVupHVeLcG5G4ug== X-Received: by 2002:a63:5941:: with SMTP id j1mr1055774pgm.59.1606164350624; Mon, 23 Nov 2020 12:45:50 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id a21sm264089pjh.3.2020.11.23.12.45.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 12:45:50 -0800 (PST) To: John R Levine Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <8fa2d88c-55df-aa8e-932f-8f7bc97d741@taugh.com> <77854271-296a-b4f6-202e-c085036289d4@mtcc.com> <30ecfcdf-a90a-7e1d-8241-64df3332089f@mtcc.com> <8db80384-c03f-109c-c2b4-7d4db96aa727@mtcc.com> <53b21bdc-546c-c17c-5ec-d6b63ac2cb57@taugh.com> From: Michael Thomas Message-ID: Date: Mon, 23 Nov 2020 12:45:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <53b21bdc-546c-c17c-5ec-d6b63ac2cb57@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:45:53 -0000 On 11/23/20 12:29 PM, John R Levine wrote: >> 1) A mailing list creates an auth-res on the incoming mail to the list >> >> 2) It modified the message >> >> 3) It resigns the message with DKIM >> >> 4) It is then delivered to the subscriber's mail server >> >> 5) The destination mail server can look at the incoming message >> including the mailing list's auth-res and decide whether to trust it >> or not just like ARC. >> >> It seems to me this covers the vast majority of cases. What are the >> other cases where this is not sufficient and how significant are they >> in reality? > > Two or more levels of forward are quite common, particularly in large > mail systems.  Look at mail coming out of Google and Microsoft's > hosted mail and you'll see a lot of ARC headers. > > Considering that the ARC RFC was published over a year ago, and it is > implemented all over the place, could you explain what the point of > this discussion is?  The people who designed ARC are not idiots.  If > we could have fixed the mailing list problem with existing DKIM > signatures, we would have. > Then why is it not standards track? And am I to understand that I'm not allowed to comment on an experiment? Perhaps the working group chairs or AD can clarify that. In any case, if this all boils down to whether I trust the intermediary who resigned the message, then that is a previously solved problem: you can base the reputation check based on the resigned signature. I'm not entirely sure what the value of  the previous auth-res is. If I recall correctly, the document was sort of short on what the specific utility is, but I may have missed it. Mike From nobody Mon Nov 23 12:48:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668DD3A11F7 for ; Mon, 23 Nov 2020 12:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEfzD7CeQsZ0 for ; Mon, 23 Nov 2020 12:48:47 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914B63A11F5 for ; Mon, 23 Nov 2020 12:48:47 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id t8so16079613pfg.8 for ; Mon, 23 Nov 2020 12:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Iw7QSKPDqt6/55d83mOJrspmYjT4gDLVRyr++qF7Yyw=; b=kxHArBKZ807dtNzeR2F0ldH81TrgPiVXG5KhxHinJLyYf3uyzw45Vk3wp/cn6dYekT RkmWAhdcAVrKLBKbpnTeZOwjisFnnxTZ5dP4O9CW8bZ5N0jgwG1WtgZ3E5Pq74RjmrFn fR9daWbhGmQ83n12bZbJAD9kLIPROF1KK2ofVTIOPDxXLU7zEcKQXfduDxOi8br1sV2Z RwTBgnqsaSz6JAOBgUpanA8e5NwJYawEp2wP98sXsNZ2W3jELYHM6sK39KhPu5Nasfp+ zmHG3fowvSgVxlS+/6Qf8hFN3x8PS+6c4BSCz13AqUKMl1E/47wsJR01l5M0bXW5IRRw oyMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Iw7QSKPDqt6/55d83mOJrspmYjT4gDLVRyr++qF7Yyw=; b=rIr2KNh8vqSfod+jB7UjeoEx8pNz3mLEPq8/LpWacw70zKIHBSoBb1X5xzG9w6azFf ESJ7LOXKT6cn4pd6+4M/DaqKuEUDzU4IpLL3IFNdIbbDkFv3kNJdG9zHmDCyntRgtgWF pYt3oZSQlExYNCVWalbGQhw1ek4dICtWP4ejS8UlIOyHYR8hkC72WXtWgm0dgzTfYeM/ qSJnUbGGnU0b/jz9Ab+joAjF2pK5SsXKRTpM4qtznn1qKnz3vqgYEjTtOJAHi0FdvPJx ya5OIeXYqoc9S6+zriZIPqqgyys4ujTybCxZRjgGEJ9SEZEPbTznq/WX3diOWkaGFEjg uj9A== X-Gm-Message-State: AOAM532vqJZqdJcSY0WmUqw132d69lSSPm/IXRnb0mmkMC2FUJ+oWlJp s380cxgWZfnnIYBMmtzqJXKj9WEj+1s= X-Google-Smtp-Source: ABdhPJyhXY54cGy5HZytJKqSXlU3Xqaw7DlLwsJViB5IbrK2o5FkMNO79cm3QeHvqsq+AuJ4TDw14g== X-Received: by 2002:a63:1026:: with SMTP id f38mr1006542pgl.181.1606164526641; Mon, 23 Nov 2020 12:48:46 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id a123sm12948662pfd.218.2020.11.23.12.48.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 12:48:46 -0800 (PST) To: Brandon Long Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> From: Dave Crocker Message-ID: <7dbd9d27-83c9-2dc1-1ab9-8b585c9b87cb@gmail.com> Date: Mon, 23 Nov 2020 12:48:44 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A91EDDE04B19E6B2273AC11B" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:48:49 -0000 This is a multi-part message in MIME format. --------------A91EDDE04B19E6B2273AC11B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/2020 12:15 PM, Brandon Long wrote: > On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker > wrote: > > > Yes, of course, a handling agent can do it, but there are plenty > of reasons > > why they shouldn't. > > Please enumerate and explain.  If it's that dangerous, we should > document it, especially I don't recall that constraint being in > any of > the design or standardization discussions. > > > DKIM often ties a domain to reputation and other anti-spam features.  > If you > forward spam to another host and sign it while forwarding, then the > other host > will think you send spam. Well, ummm... errrr... yes.  That's because, in such circumstances, you do. More significantly, the signature makes sure that such as an assessment will only be made accurately, rather than penalizing you for problematic mail that is attributed to you but that you did not handle. > DMARC ties DKIM to the From header and at least is interpreted as being an > anti-phishing feature.  DKIM signing mail that you forward could mean > upgrading > a phishing message to passing DMARC. I don't understand.  The first sentence makes sense to me, but the second doesn't. "Upgrading...to passing DMARC only applies if a) the signature matches the From: field domain, and b) that domain has an associated DMARC record.  But if you don't watch DMARC to apply in that case, what is the DMARC record there fore? > This recent article also goes into things that DKIM signatures imply: > https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ > The level of condescension, ignorance, and error throughout that article is impressive.  Given that it was written by someone whose profession requires extreme care about complex matters, the level of carelessness in the article is especially unfortunate. Conveniently, he put his biggest error in bold font:      "*DKIM provides a life-long guarantee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent."* DKIM does no such thing. and this was quickly followed by the normal-font:    "The key design goal of DKIM was to prevent spammers from forging emails /while in transit/. " This, too, is not what DKIM does.  DKIM provides a noise-free channel for assessing signers, not for detecting spammers.  The difference is important; and I claim fundamental. ps. making sure that DKIM signature become invalid  relatively soon -- I think that removing the keys is simpler and just as effective as publishing the private keys -- seems like a reasonable suggestion. ** > Perhaps this all means that DKIM has been used for more than it was > intended for. "More than" suggests that the use has legitimacy.  It doesn't. > >      > Intermediaries don't want to take ownership of the > message in that > >      > sense, though there > >      > are some mailing lists that do. > > > >     Signing with DKIM does not take 'ownership'. > > > > > > Yes, responsibility is the proper word.  My point survives the > word change. > > I disagree. > > > > DKIM says the domain takes responsibility for the message, while > ARC says > > the domain takes responsibility for evaluating the status of the > message > > when > > they received and forwarded it. > > This implies that the word 'some' is irrelevant.  It isn't. And it > was > included intentionally. > > > Automated systems can't really tell how much responsibility an > intermediary was > intending to take for the message. People who write them can. > OTOH, they typically are using it only for a certain > purpose, so they assume that the intermediary took responsibility in > the sense that they > want... or rather, the people who wrote the code do.  Or the > journalist writing the story. > > ARC was specified to have a more specific responsibility, Forgive me but I think that: > Authenticated Received Chain (ARC) creates a mechanism for individual > Internet Mail Handlers to add their authentication assessment to a > message's ordered set of handling results. specifies a nature and responsibility pretty much identical to what DKIM claims.  The enhancements are a) chaining, and b) carriage of earlier assessments.  But in terms of 'responsibility', this reads the same as DKIM. > and as different from DKIM so > that it wasn't mistaken for the uses that people were already using > DKIM for. Oh? d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------A91EDDE04B19E6B2273AC11B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/23/2020 12:15 PM, Brandon Long wrote:
On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker <dcrocker@gmail.com> wrote:
> Yes, of course, a handling agent can do it, but there are plenty of reasons
> why they shouldn't.

Please enumerate and explain.  If it's that dangerous, we should
document it, especially I don't recall that constraint being in any of
the design or standardization discussions.

DKIM often ties a domain to reputation and other anti-spam features.  If you
forward spam to another host and sign it while forwarding, then the other host
will think you send spam.

Well, ummm... errrr... yes.  That's because, in such circumstances, you do.

More significantly, the signature makes sure that such as an assessment will only be made accurately, rather than penalizing you for problematic mail that is attributed to you but that you did not handle.


DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature.  DKIM signing mail that you forward could mean upgrading
a phishing message to passing DMARC.

I don't understand.  The first sentence makes sense to me, but the second doesn't. 

"Upgrading...to passing DMARC only applies if a) the signature matches the From: field domain, and b) that domain has an associated DMARC record.  But if you don't watch DMARC to apply in that case, what is the DMARC record there fore?


This recent article also goes into things that DKIM signatures imply:

The level of condescension, ignorance, and error throughout that article is impressive.  Given that it was written by someone whose profession requires extreme care about complex matters, the level of carelessness in the article is especially unfortunate.

Conveniently, he put his biggest error in bold font:

     "DKIM provides a life-long guarantee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent."

DKIM does no such thing.

and this was quickly followed by the normal-font:

   "The key design goal of DKIM was to prevent spammers from forging emails while in transit. "

This, too, is not what DKIM does.  DKIM provides a noise-free channel for assessing signers, not for detecting spammers.  The difference is important; and I claim fundamental.

ps. making sure that DKIM signature become invalid  relatively soon -- I think that removing the keys is simpler and just as effective as publishing the private keys -- seems like a reasonable suggestion.


Perhaps this all means that DKIM has been used for more than it was intended for.

"More than" suggests that the use has legitimacy.  It doesn't.


>      > Intermediaries don't want to take ownership of the message in that
>      > sense, though there
>      > are some mailing lists that do.
>
>     Signing with DKIM does not take 'ownership'.
>
>
> Yes, responsibility is the proper word.  My point survives the word change.

I disagree.


> DKIM says the domain takes responsibility for the message, while ARC says
> the domain takes responsibility for evaluating the status of the message
> when
> they received and forwarded it.

This implies that the word 'some' is irrelevant.  It isn't.  And it was
included intentionally.

Automated systems can't really tell how much responsibility an intermediary was
intending to take for the message.

People who write them can.


OTOH, they typically are using it only for a certain
purpose, so they assume that the intermediary took responsibility in the sense that they
want... or rather, the people who wrote the code do.  Or the journalist writing the story.

ARC was specified to have a more specific responsibility,

Forgive me but I think that:

   Authenticated Received Chain (ARC) creates a mechanism for individual
   Internet Mail Handlers to add their authentication assessment to a
   message's ordered set of handling results.

specifies a nature and responsibility pretty much identical to what DKIM claims.  The enhancements are a) chaining, and b) carriage of earlier assessments.  But in terms of 'responsibility', this reads the same as DKIM.


and as different from DKIM so
that it wasn't mistaken for the uses that people were already using DKIM for.
Oh? 

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------A91EDDE04B19E6B2273AC11B-- From nobody Mon Nov 23 12:54:41 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73143A126D for ; Mon, 23 Nov 2020 12:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 naEngm8oT_6t for ; Mon, 23 Nov 2020 12:54:38 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 A17F43A1265 for ; Mon, 23 Nov 2020 12:54:38 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id l11so9469542plt.1 for ; Mon, 23 Nov 2020 12:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=npUtNyZJ5pVOGge30BTRNujHKMUsspz7JfUdoJFdLNY=; b=UsDs3/f1vTizfr0QkeOK8/V3RrrpTm1PDEsHJQHzAGN5hUuCOU22wXKm9UxxfQbshC DWz+laY53sswQItsEnt3owSUxtpFb36BS4wTKLk4DEoDgYMbxTqa3y4II7G3P3yJGwh3 Sk5DE+CmmvqkVFM71J7gS40BwruRnZkPm6O4fFsq64BGeSfF1NfPNdp7xC4oTUAU0tva AbcJFRWLd6HdIBqMiVK7/zs9qcNMJ20Z3291eXjq8sSJ0tlHDNc6HxB8h8B6lqa7GQhn aVoTa0DEXHm/ADrZzxz9RfQxY8SFU73xYKeA61Yui6Z4J2JlO0D8bIbEhhjbG4P3oM/v Xmhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=npUtNyZJ5pVOGge30BTRNujHKMUsspz7JfUdoJFdLNY=; b=bcjX6X7pz85UtVqV+/vUAEL2581oD4DYwTck1G+oK8ZsYGRXiz+IHaJXvCr3Nz/qwi 3YKW8utsV0HMUi0SZ6SG+fIEby6ocCf9BgcTAB5dYvWtHmn0Az/wwrZK8ocUOOecnLXL ixk5XmpOsFRrcoEfX0NbtcN73XD0sAf9hgLumObFzpemQTIIs3FEO86wDB89DTD+GdF7 YMrvlAXppKu3dbz/a3un8SKUtai02qPoI83LpHrXEUekPzcaFMvOfAGila4j7XMWSFMi RYwNICZ0Ruj9qHYtuqti+yimsn1A+JX+/7fc7SK6DoXbPObwos/idWyt85EcbrCNKpOY ixbA== X-Gm-Message-State: AOAM532eSYC9um8ROGWvRlyVMeO84OWv+Gr7oYHPu95SWudT8wNMX9Gs 17UEBV4I/Y4gTHz5hlId17u2hzQEZPwkcQ== X-Google-Smtp-Source: ABdhPJzrZdIpo7mupeTRWlz6zqZacE7dgjMgVc31VCc7nGAL3NLU/PKnSm0dKRPCrYj58WJs2XusjA== X-Received: by 2002:a17:902:c3c2:b029:d6:c4d5:9267 with SMTP id j2-20020a170902c3c2b02900d6c4d59267mr1095600plj.30.1606164877616; Mon, 23 Nov 2020 12:54:37 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id x7sm3927303pfn.85.2020.11.23.12.54.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 12:54:36 -0800 (PST) To: dmarc@ietf.org References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> From: Michael Thomas Message-ID: Date: Mon, 23 Nov 2020 12:54:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8414AD60C21ABEF56DCA2C6F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 20:54:40 -0000 This is a multi-part message in MIME format. --------------8414AD60C21ABEF56DCA2C6F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/23/20 12:15 PM, Brandon Long wrote: > > > This recent article also goes into things that DKIM signatures imply: > https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ > > > Perhaps this all means that DKIM has been used for more than it was > intended for. It is a quirk that we didn't consider at the time. You can't count on that property because providers can change their selectors at any time. That said, there is an awful lot of hand wringing for not much gain. It's not like you need cryptographic non-repudiation to be pretty sure something wasn't forged. That and non-repudiation has its benefits as well. Mike --------------8414AD60C21ABEF56DCA2C6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 11/23/20 12:15 PM, Brandon Long wrote:


This recent article also goes into things that DKIM signatures imply:

Perhaps this all means that DKIM has been used for more than it was intended for.

It is a quirk that we didn't consider at the time. You can't count on that property because providers can change their selectors at any time. That said, there is an awful lot of hand wringing for not much gain. It's not like you need cryptographic non-repudiation to be pretty sure something wasn't forged. That and non-repudiation has its benefits as well.

Mike

--------------8414AD60C21ABEF56DCA2C6F-- From nobody Mon Nov 23 13:04:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A1B3A127C for ; Mon, 23 Nov 2020 13:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5usJbCLszdT for ; Mon, 23 Nov 2020 13:04:18 -0800 (PST) Received: from wmauth4.doit.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) (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 2D30E3A127B for ; Mon, 23 Nov 2020 13:04:17 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QK903LUDP74UBK0@smtpauth4.wiscmail.wisc.edu> for dmarc@ietf.org; Mon, 23 Nov 2020 15:04:17 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-4, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.23.205417, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.19.5790001, SenderIP=[104.47.56.169] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZPg71eUK22Jww8qrq/6u8x8A7RGp9xT4WQhBZo3Rgdhg0ISFYmwm2lI3NV9VcwBboHsWazXBysf3kUGXrAD1c2EnprK6WdJuQA20TKiUZ/SdU7bc7RFognO4BrZF3NRKXo4nA1r8kJGHn+ktu8rK8E7BwgiX0JpF/98YqfXilBo+tOUyM9HWE4IMywMRDqkKWgZ9KtyjmzKPupLuhYRrsFkAScLb5rEVKndU/pQOiAx8YsVLLT/kSjajHBkpZEf3F31GCpwKdvIXJUKADGxcQDT58yk6Oo0lNKXF1znr1obQ0iYJH5uF3M29aCEv3gdmayOJf71Otp6pTOGA81UVWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=89YdeGS2wG4VBjoD2IMHtJ15WznDWAnacy6AbBEET8U=; b=LpSsbCKT5EqT7xRn8yMABk7KesYpur/lxvw1JAuChIk2lZ9USqawPuwk0N4pjO5YbxJhHeyE2i1gIlHs54ofkAUqdtVqjpmH+7NQSY2LtWSdAzRQLYWiPDVaAwPrmC8IMXMbV8aitKYG0djxNOjDTHEllisULUw+AbpnO8ECXobm/zZpPr8yD4HR1O2tHHNpG3ag93aho+0jhmhF6uHAUOzVct2hn3xRWnYcBsdN/saCXoVEYwklLNW/RBgXySxryIJD5yS08hTxqDiFaLVAwPNiI+7Xd3d78ULlCuUXEK9pskEmAWV8ltR0/J/Gzx6cozAYutlRF57DihyfQVWu5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=89YdeGS2wG4VBjoD2IMHtJ15WznDWAnacy6AbBEET8U=; b=mbwfoXZH0b+Rf/VIWzsKxbnQqTG6wYEiIUYaRdnCQHNsnz/saWBj11lhNJxts3N0kbQPeWoE8kU8k9Erp8FInGyxSDVolvYrBFoa/s0CpQPZg6kQ9NWm9nYj4+/z50Dl8iYVJZrnpI78T6FnZRHKrZWICwakd8GSHAJSm8ffem0= Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by MWHPR06MB2640.namprd06.prod.outlook.com (2603:10b6:300:49::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 21:04:15 +0000 Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5%7]) with mapi id 15.20.3589.022; Mon, 23 Nov 2020 21:04:09 +0000 To: dmarc@ietf.org References: <9e6bac98-47fa-92e3-8552-7f4839d37e60@wisc.edu> <77bbde18-5720-63ca-53b0-6b41f2ea60ed@dcrocker.net> From: Jesse Thompson Message-id: Date: Mon, 23 Nov 2020 15:04:06 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-reply-to: <77bbde18-5720-63ca-53b0-6b41f2ea60ed@dcrocker.net> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH0PR04CA0106.namprd04.prod.outlook.com (2603:10b6:610:75::21) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH0PR04CA0106.namprd04.prod.outlook.com (2603:10b6:610:75::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.24 via Frontend Transport; Mon, 23 Nov 2020 21:04:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7c29d591-92be-4c51-ca3d-08d88ff35231 X-MS-TrafficTypeDiagnostic: MWHPR06MB2640: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eU9pFv1qY13kLuj8fQajPgCI+Vo5qfe7iLQzIHuKiFf65EZhyLAy3C6LXMo3zBCDTZPpcLAlmdwNSx2pITG2xtuYinyJ3T437+IO4VfRwLuFo7zzEh6SGED6M0Jf/b/DCNoGIQIxyULnKI/+oyIdiyLBxx9KzitPnXFceOwFuwPvGAqJoDYJDaTvhAKkuBXNNdXsV5b4KHzBNGlcOW2TpCLv2ik0Nn5ZUzCjg+tSetQzZjrukfqTXAtn1AiMr44tHxKHpvEEvy5kG5mBz+/2xIvOvpDepl2gfYkzaz2ynhSed9CKxyAdReAWHupofEMmr/Ld3IxifWpppMPLO88Kphhh9T5WVscah39D4grA9Ol2bIlC5Dn3HyOo/xj1O2352aTZ0+hKsONzBOHqqd1xFJgmqop2cs3Kc58v0ArMXb4= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(136003)(376002)(366004)(346002)(6916009)(8676002)(6706004)(8936002)(478600001)(5660300002)(6486002)(66556008)(75432002)(66476007)(66946007)(4744005)(44832011)(31686004)(86362001)(2616005)(31696002)(956004)(186003)(2906002)(16526019)(26005)(53546011)(786003)(16576012)(36756003)(316002)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?LzZ5WFo5bFlZZDEwUEdDRE9TQWJDRllYdGgrcjh3Mi9FZEFnYXVEWW5tOTdp?= =?utf-8?B?UTMyUlYrWFdYVFRRR2pSUkJ4QWh3QzNFbzBIMlNyenFMM1VyaFhoZHlaRHE2?= =?utf-8?B?Tk10TXo1ZVJiem00V0R5dTFQY1ppcUlVV0R0QVlaQ1BESTMwdlpsR3J4VFpD?= =?utf-8?B?SUhVMEFrb0NNVmZkdWxzaHNjUDFWMFRkZUkrU0Q2Z0luR09hZnR3VDlyUFZZ?= =?utf-8?B?ZzdHNCtHeWF4NW5Gd0JRSHhHOC8weSt6eGlGa093UzFKTVVHMEtuZFZrWURv?= =?utf-8?B?OCtRUW9CQTkyL0UxdDBPRjNkTGVwNDQ2Nkl6S0FIVS9lR0lCa1J2RTRLVnBw?= =?utf-8?B?K0hENnhOVytJbDhvTis4YVdCMS9VUVptWC9oUHV3TzJiOTdHdG1VTUxyemJo?= =?utf-8?B?anE2dFV2TUg4bnVZSjlFdkxnZjJXZm51SzRCVHVOTXRSSWhqNFV6bThlSnll?= =?utf-8?B?NUsvaHBmc3ZVRzdUcUVhbmpqN3FMeUtBMWdDVWUvaFg1RHdGNm5sZ1lrTlJT?= =?utf-8?B?WE9KM2hlQndPcWdiWHhKbCtuZHl1dHVlQzJsUlIyOFdLTWZGSVp4RWZaamxl?= =?utf-8?B?bDlDVlk5QWcrV3g3TWpsZWhKeUx5SGszZ3FzZVNBcTd5dS9yNW54OWpia1A0?= =?utf-8?B?amFWMzI2ZStvaWhDU0ZiZmU3N09OVUdvazhOVlNxbTJGeWl0MEFFWXc2N3hJ?= =?utf-8?B?VEZnU1MyL0htTCsyejg0cGVhYTA1YkloOVpkRTBPSU1nUGF5RCtLenpNZ3Nh?= =?utf-8?B?WFpXSTlKL3FyWXFVRWgyVzdLeDFCNDFUaXlhZDIxSVZ0S0NycWhLQm9UdjZ5?= =?utf-8?B?YUd1V0ltSnNmd2ZtQmVmQUlEa3Y3NGtqV0pFUDBHcUhiSFVKN2hoMGpOU1A3?= =?utf-8?B?d3NsZGNlTGNiWmFoUXlobHZaUm1zUDJkenVxeWU1TDBDclRkRkcvTnE1cDV1?= =?utf-8?B?eVhxNnRibm9MYmRpQWg5R0dhWkM1NHNJdzZsZE9FVHVwMVh4eHJsTHFRbEla?= =?utf-8?B?MEV4RDBiZTZMRCs1UEdTbzBGTUt3OURCbzkrTEhTWnlzRjhuN1lZUllOejd3?= =?utf-8?B?QWFqUW1zRy8vNWVjMXVHbGJjS3c0TE0xUlZGUTZNYWwzdXM5VmNYbmxwZGhH?= =?utf-8?B?V1ZNdHNtaWRuOEdZNWIza1Z3WXIyYm9HUnRPRTZPTjhNK1JKaVJXTXJrekJT?= =?utf-8?B?RWd4SGc0S0pJdUxJTjFuV1NweTRSbmIwaXNMQmsyc2ErS3hjc25RQm9iNndm?= =?utf-8?B?TTRGekpPN252NlhHNlJsaUN2TkhMcEFXZDZXYWJaZFo4OUJOVGVnZUhLRkVS?= =?utf-8?Q?cXxzeNWXop8PBMs9LcuTpK9hTkmHo1ZF42?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 7c29d591-92be-4c51-ca3d-08d88ff35231 X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2020 21:04:09.4144 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: L0yDlstfrnmTIEKZlJl6lf+MrEwaaMnsuUy64flkQ09o831rCLoceYob+CL5VdkwqPza645ic0LF66bbS8G16Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB2640 Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 21:04:20 -0000 On 11/23/20 1:00 PM, Dave Crocker wrote: > On 11/23/2020 10:50 AM, Jesse Thompson wrote: >> Would it help if there was a new DMARC policy tag to trigger the tree walk? > > > policy tags are useful when one has a dmarc record that might contain it.  the challenge here is to find that record. I meant to suggest that the requirement for a tree walk would be that the Organizational Domain would need to have that in its policy. It seems like a decent compromise for the people worried about unnecessary DNS lookup overhead. Jesse From nobody Mon Nov 23 13:05:50 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28803A12BE for ; Mon, 23 Nov 2020 13:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=ZeJfvWDf; dkim=pass (2048-bit key) header.d=taugh.com header.b=fNjpgubW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmdjUkQQX8P1 for ; Mon, 23 Nov 2020 13:05:47 -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 7B30B3A12B9 for ; Mon, 23 Nov 2020 13:05:45 -0800 (PST) Received: (qmail 83539 invoked from network); 23 Nov 2020 21:05:44 -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:cleverness; s=14651.5fbc2428.k2011; bh=xMVU8/uixPoOZF5KPi0+WB0IZqzsSgr5oZVXPjAMVLQ=; b=ZeJfvWDfAstJue3p4VdKr4apoUo1nnu1/hKTLQ1Za5E6sEIkOubXfYm8q6dfKB9ZHayps6Y6rnrAM4w9xSbrHfWBi0PjA7knyZeWfNIkjqqZqdUrW1TO94CiMwvgP3oxn3Fo6UTcFN55/VyKrfgV5x+SsfP04RYGJdK7iir3KY3QU9Ssf/CtmKh6vrHIzpU0MyMQO+IhUAlMNtFcffI+snF6d8VMB9QyoglBB2Y97IpRkVtSA0ShH/AGorNhqw3Gbuerp65iAquPKx6huUWfHIhvHnOkjcUIkRSEPEAYCw0/WeZOGxxn6zJjbsRRMevB6qo+iwcHLLeWkmY6J4V6qA== 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:cleverness; s=14651.5fbc2428.k2011; bh=xMVU8/uixPoOZF5KPi0+WB0IZqzsSgr5oZVXPjAMVLQ=; b=fNjpgubWFVBHScsWsTgbp/6BSt4sMuXe3DRPEMFcDCLbYoBT9QjXo/ga4w8G7BdBblsQaSQHziVm5A1RJ9IBwKH9huKmZCA14KJINJUCAAa3F2G2ack59NR5vXzAhrZ9uDcWhYk+UTzz2I2M/kJuBmz/5HsPsdVtu5ui21uFtJDeZXc8Md84ybkqiAboMVBpvKW0DrOgCVVVEK684JPSN6f4OE1ZREuyZGaQSCSNenMoDtxYtB44pT7U1j9pP/xth400+6qhzfXSypuJynXpQGfWXguFephsRkJLSRH4vdMF/u8HS/kHucl4m85SENIZF2+6yXWi1lJp4svOEJ3lKA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 23 Nov 2020 21:05:44 -0000 Received: by ary.qy (Postfix, from userid 501) id 694B127C778E; Mon, 23 Nov 2020 16:05:43 -0500 (EST) Date: 23 Nov 2020 16:05:43 -0500 Message-Id: <20201123210543.694B127C778E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: eric.b.chudow.civ@mail.mil In-Reply-To: <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 21:05:49 -0000 In article <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> you write: >-=-=-=-=-=- > >Even for .mil, the vast majority of email domains are fairly short with four or fewer labels. Most of the other ones tend to be >individual servers that send automatic performance emails, and I think should be considered more of an edge case and less of our concern. I scraped my logs for the past few months and that's what I found. Nearly everything was four labels or less. Spot checking the few five-label names, I found that most of the mail was all from MAILER-DAEMON@ and it appeared to be spam blowback. There was a trickle of what looked like real mail from stumail.zcs.k12.in.us and feedback.retail.voice-your-views.hsbc.com, I found nothing at all with six labels or longer. So if we made the tree walk limit six or seven I think we'd be unlikely to lose any mail that anyone would miss. R's, John From nobody Mon Nov 23 13:06:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A8F3A127F for ; Mon, 23 Nov 2020 13:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg19ZEDWGGAq for ; Mon, 23 Nov 2020 13:06:34 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 71C2D3A1281 for ; Mon, 23 Nov 2020 13:06:34 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id v21so8216978plo.12 for ; Mon, 23 Nov 2020 13:06:34 -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-transfer-encoding:content-language; bh=/SXFM15uv2XwFa1YMsVdLwdwpSxFxbnuASvK0s3SRp8=; b=PzbRtegdUXEbbIHhnJfl5WeBArotZXgL+f9oklMc77Eoo6DfFP5l8zc4JHfR4QKykS R3EHrgUuk7SWCXWAN6lWESJ4o8Y2aNP4KBNvznIWdSQf9M5UuxqX3s/G8rWieGxfYOGm Pc7dwrbI3wxYXwpMw+b5xWCkyEjz0fnhQ3vKtvwGsAA2yW5Q6t5kDJLa14eCglTL+j30 bniQojqiMEI0VY+2SfOBr45SqfzhhmgW3O0Uprebv8ykq0j04lpcEx8pocb79b+4GZuD uOgypez/EjEkaEDC4sHRPqj1VSODW28HS3JUvRqDtW3R3hUPGrlrieEu2qEQ+xXbhHSa A0Tw== 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-transfer-encoding :content-language; bh=/SXFM15uv2XwFa1YMsVdLwdwpSxFxbnuASvK0s3SRp8=; b=WgEMVIQE6ksYLU4n1DQcAyCgrM3CYOeb4pPH4kV0vAGIPlVyt0qg4Jxz+W8xQ050yT Th7WR4/bPpvUnb7F06UxzQaDxet8jSgF6z9TYkE5zkmqGtGOKvgiCoNgdYG+SE/r1fUi OygzQdykY5hbb2SY8hZKBkN8OmtWQwv7vg6whGmmASRUIEk3zP+0Gl4TCx3e7dlMvAR2 AaLQ6beLV3ZYTtm63Jrjk0u6sRP3ny1h3cAFso3fl7j+0pxtE7TaGpJRU4Zslt3qv8wL v98zncmI9fn0865jWmFdESq3Rj4qVVj/nKsINI28HraLvXLVV47wpGlVYQCjX1Fn0OAt 4D4A== X-Gm-Message-State: AOAM532p2wuzUQaaY6m7J4uT9Vh7xyoTwlrCjamq6ZrD4L7kNMhpawcw MFL2Z8jEw9y1uY7vEx+A6D+RAlAx++g= X-Google-Smtp-Source: ABdhPJxqaVKANiZ/c4driwUXkgCzjKyZjBZxxeMV+opSc69hFpgFPvInpy4refzvgmIef46i1OaDGA== X-Received: by 2002:a17:902:8506:b029:d9:6dd:45ea with SMTP id bj6-20020a1709028506b02900d906dd45eamr1082286plb.72.1606165593640; Mon, 23 Nov 2020 13:06:33 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 205sm10989961pge.76.2020.11.23.13.06.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 13:06:33 -0800 (PST) To: Jesse Thompson , dmarc@ietf.org References: <9e6bac98-47fa-92e3-8552-7f4839d37e60@wisc.edu> <77bbde18-5720-63ca-53b0-6b41f2ea60ed@dcrocker.net> From: Dave Crocker Message-ID: <9f388e33-c15d-9fcc-e9d3-d7719288fb98@gmail.com> Date: Mon, 23 Nov 2020 13:06:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 21:06:35 -0000 On 11/23/2020 1:04 PM, Jesse Thompson wrote: > I meant to suggest that the requirement for a tree walk would be that the Organizational Domain would need to have that in its policy. It seems like a decent compromise for the people worried about unnecessary DNS lookup overhead. Except that it can't 'trigger' a tree walk. On the other hand, it might declare itself to be the (an?) OD. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Mon Nov 23 13:27:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013983A12A9 for ; Mon, 23 Nov 2020 13:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.559 X-Spam-Level: X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PP_MIME_FAKE_ASCII_TEXT=0.11, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=gYl2I0DD; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=BlorD9jQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwCfp1DTMxyj for ; Mon, 23 Nov 2020 13:27:44 -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 3528D3A120B for ; Mon, 23 Nov 2020 13:27:43 -0800 (PST) Received: (qmail 88876 invoked by uid 100); 23 Nov 2020 21:27:41 -0000 Date: 23 Nov 2020 21:27:41 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=15b25.5fbc294d.k2011; i=news@user.iecc.com; bh=6gRe6cR/aIT2Kl+1XoX83eaMLYWoviYc87+uzdY3yiU=; b=gYl2I0DDWXxlfIVU6wds+esMB7DqJ9wPCWA7jImDOn3JMP6wfiIa3DMKD8F1eocPm93ps4ly33cw/I8NdvbTNPicAA+AxFCzT8OvSIPu90ytr2b5wCzM2GR3p567734xL3f1sKJ4dBZg2liN1AtNMDvQPhsj6pTLIXIWsbdhO0BU1R6Axb291cITHCpie1Marvh2PD0bBuaQkpYnGfYDaHoATVqNfuo1WVGDdtVDG/9s2nhDgnAZE7hjCQQnQuLNTcJjD47mqaW5ld9rk6jUIxwe5ulc8g6lZiMh8aCJjUkJELh7SMMbNkp9RwfueKqHSoW/En82VjTr5cpDbp2DfA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=15b25.5fbc294d.k2011; olt=news@user.iecc.com; bh=6gRe6cR/aIT2Kl+1XoX83eaMLYWoviYc87+uzdY3yiU=; b=BlorD9jQiz8MlztWnWSUIZrqKC7GMt3OmcF8+pFrHBHpnp3b5RswzFg67y4wpRnEVezP6t1l1YH7kzwg+XJgFNrI93I5Zgon5aT3ehDBtWDQHrVQNiVATUPNnSstC4EU9qNeSEpu9IBn9KYwmzUjNePqUE67OK/bZYBCVp7C77cMO+5pZS1j5WNrwBZnNM0czgvqcSACIJ0NRIY601XlEVXr6jAU+4PP/mQY08ZgJGDVzYi1brzTFrp9W0//+1UcKGQwa3Etbt29e4jBE1xfNX1fMXJZMDHtNAINWq7onEQrVd6XZiZ7CtcJcV39Vz9+2ikB8SkXMIdoQBAnvkdg2A== Organization: Taughannock Networks References: In-Reply-To: Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 21:27:46 -0000 In article , Dave Crocker wrote: >> I believe, though, that the intent of ARC is that it be scalable in >> ways that manual enumeration of known legit mailing lists and >> forwarders is not. > >"if you know which hosts are legit" buries an assumption that is >problematic, namely that you know who handled the message.  The fact >that a message purports to be handled by a mailing list you trust does >not mean it actually was. Pretty close, but not quite. You know that a message came from a mailing list because you have your list of IPs or DKIM signatures of lists you trust. ARC deals with the problem that most list software forwards everything with a subscriber's address on the From: line and does a lousy job of spam filtering. The question is if the entity sending the message to the list was who it purported to be. For example, if a message from a list fails DMARC alignment, but ARC says it was aligned on the way in, it's likely a real message from a subscriber. If it was unaligned on the way in, it's likely wpam. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 23 13:38:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5C33A12DA for ; Mon, 23 Nov 2020 13:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=Q8v2GQuu; dkim=pass (2048-bit key) header.d=taugh.com header.b=lVuXAcZA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WNlTLue1j5A for ; Mon, 23 Nov 2020 13:38:49 -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 D34D93A12D9 for ; Mon, 23 Nov 2020 13:38:48 -0800 (PST) Received: (qmail 91308 invoked from network); 23 Nov 2020 21:38:47 -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:cleverness; s=164a9.5fbc2be7.k2011; bh=4ixHYdck6oYF/rk4LBRPd5UQienYG00A5kCb0OfMToo=; b=Q8v2GQuue7UQk0yJejirmLcZjoJQzFPsXqHgRxRG3F1sfaAtntcjA00VB4sQA5XjEs91P79KVojfO9uXJTJWLlTGPBJwCOMkGZWhZxTURIORDfvLim+3jqaohL1cAzHM98vprym0q5nj6GQATMIjiyABDBx6X1bFw8wi065gikBb1Snz6WoEYndO9w2D5Lqx2fmnjdUXL8BqhazpmxDpVQefomc4n2uxmHvlZjGvJiDzOkLLAacpQeC9Wo9czwwKM8GIUw1lTgeSwr+haJZJ4vZ2Zx4rU1VkSNTuqg6qKlz5xRITidORZimOSy0uYkluiMXi02LPMS1CrXPiAqc9AA== 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:cleverness; s=164a9.5fbc2be7.k2011; bh=4ixHYdck6oYF/rk4LBRPd5UQienYG00A5kCb0OfMToo=; b=lVuXAcZAxD6xZWsGTEOcjGLGtQ601LUTWKG0vg/6DtzYeuuXYnAwM4NXKah2p1v6Xqy4IQz4KlBzhxclF9U2rVrHcnpV7RLl+V2hTM7RlTpU2jGa4c+SrYUddSawRfHAADLb4ynI49dzDy4mh55dvrtNX0nCr5YHqBMVwdaFVt9dKwVwXROygq31SAiHVBTU0RaQIUOEiLmddr4EXKEAXFIV7LM1pLwsrk8YPCIhmQp/aiJXU9Q3N8tvpRGL5IMRbdwR8kaCTjy21Fr1j1EuxNWCWJv4KQo7SS8Wm1QkHExL4mtqFFyhqoatg5P2sBf9y5Z5vkGNnddOB6EEVqo1KQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 23 Nov 2020 21:38:47 -0000 Received: by ary.qy (Postfix, from userid 501) id EB14127C8160; Mon, 23 Nov 2020 16:38:46 -0500 (EST) Date: 23 Nov 2020 16:38:46 -0500 Message-Id: <20201123213846.EB14127C8160@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@gmail.com In-Reply-To: <9f388e33-c15d-9fcc-e9d3-d7719288fb98@gmail.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 21:38:51 -0000 In article <9f388e33-c15d-9fcc-e9d3-d7719288fb98@gmail.com> you write: >On 11/23/2020 1:04 PM, Jesse Thompson wrote: >> I meant to suggest that the requirement for a tree walk would be that the Organizational Domain would need to have that in its policy. >It seems like a decent compromise for the people worried about unnecessary DNS lookup overhead. If I'm going to go to the effort to download and decode a PSL and find the OD, I'll just use the OD. One of the points of the tree walk is to get rid of the PSL processing. It looks to me that a tree walk limited to some modest number of levels like 7 or 10 would handle close enough to 100% of real mail. When I brought this up in dnsop last week there was some concern about super long tree walks but I didn't get the NO NO NO that we got in the old days. DNS operators now realize that an amazingly large fraction of DNS traffic is garbage, and a little extra noise from the occasional tree walk is not a big deal. In normal mail, the number of labels is usually quite low, here's my distribution by number of dots: 2404 . 1215 .. 152 ... 10 .... R's, John From nobody Mon Nov 23 13:53:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F563A1315 for ; Mon, 23 Nov 2020 13:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=fTSzcc0u; dkim=pass (2048-bit key) header.d=taugh.com header.b=BcC1m4iR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6UKTFf8rlhG for ; Mon, 23 Nov 2020 13:53: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 205523A1313 for ; Mon, 23 Nov 2020 13:53:41 -0800 (PST) Received: (qmail 94821 invoked from network); 23 Nov 2020 21:53: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:cleverness; s=17263.5fbc2f64.k2011; bh=LAUqGYXvI+KnlpMqn3kL1HL9PKv+4HvqncF+4tZsYGs=; b=fTSzcc0uAbdyuSOYH+4lWX0iOsjGhVIRYHkVCrsnam4+yPDpoeyfmk4uzRwdwsLsiSFMut8EJ/gAepsFkhyMupKO/gh5L0W9ocVrfpKiChiWcikejfI5080RGIvh6vyiRy5dfnR52ok7MtfmQh8hB4gQS95ZQnOJKDUyj9YJsCHhdYtSrXhHeLN6FfjfNetirBqpJuC16KorJHNebriCcZjqH1q1uOXzO/RLSdDSONwMsKJQICElhYniLW3cbrrg5x+veijElF/kE2UBuXhcIzWOp+gEVDJaywPJZ7QXmLk/WCJ+4sutcq0QqhR4xjuBXXOeWn28o6TrXVZDKKzjxg== 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:cleverness; s=17263.5fbc2f64.k2011; bh=LAUqGYXvI+KnlpMqn3kL1HL9PKv+4HvqncF+4tZsYGs=; b=BcC1m4iR+M0VTeAb4vlt0lf87USmxp7EL4DRqqFUwAzEP2wE7mTfRXo1NxBNqwYrPsqA8Lbc5cYO7cxerhLMvhK3yb7VJgwmmirTLXBx7yqiYdiZdtIKGTYf8em09ovZaOF0iwmcPYXU1l2TMehJpG8qeU9iHdR02ZJZQxR4itB5CdXzIKJoDxvJkMpdYuWZWvKI1bJXgoGBLbo270hwRK5VBqxtq6p/QD+uVZheSJsl0LVYdnUUE62DQc2UlWsl0iNO09b90yz6iyKOBpx0zkLH8j5qdNL3x2ENj52sF2OmOmJJNs00gxUlOM0Ah2eNeaznSos1xrQLVtZnZ/ZAMQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 23 Nov 2020 21:53:40 -0000 Received: by ary.qy (Postfix, from userid 501) id 07FD027C8BD0; Mon, 23 Nov 2020 16:53:39 -0500 (EST) Date: 23 Nov 2020 16:53:39 -0500 Message-Id: <20201123215340.07FD027C8BD0@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: todd.herr@valimail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 21:53:44 -0000 In article you write: >I suppose that an approach to building up an ARC reputation might be one >where over time a receiving site can compare indirect mail flow that is >purported to have X as an authenticated identifier with mail that comes >direct to the receiving site with X as an authenticated identifier. ... I think it's more likely to be ad-hoc, does this source send mail that looks like mailing lists and the recipients don't flag or complain about it. R's, John PS: >This email and all data transmitted with it contains confidential and/or >proprietary information intended solely for the use of individual(s) >authorized to receive it. If you are not an intended and authorized >recipient you are hereby notified of any use, disclosure, copying or >distribution of the information included in this transmission is prohibited >and may be unlawful. Please immediately notify the sender by replying to >this email and then delete it from your system. Too late. From nobody Mon Nov 23 14:04:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8723A134F for ; Mon, 23 Nov 2020 14:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 m4Ovpg8xKVtB for ; Mon, 23 Nov 2020 14:04:27 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 55E7F3A134D for ; Mon, 23 Nov 2020 14:04:27 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id t18so9577040plo.0 for ; Mon, 23 Nov 2020 14:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=eQFHYmQy1AiCEsCizLiXazaLaGFTJpUzaVThKvfxj9s=; b=Vk4kpVnvLnhztUDOvbapVl14Pj5hTIu3BuBBFr2GBEt54fIB3yqS8RHb3xib+Slflz vO+oOnbERGJuaPcnqq12+wJytt41qrjChCayuz1Deww7s1w2DJnFMORg8Q9TEQMy/86J uvv+ilaMgfuQMnV903BvLmpecQ7lWLBhp9vjTHS1icTzBK8V9SBsuJZyoR+i2UTpTmfP cH8Y3O5GE5Vmbfbjdafv4upMd/G3oKSA843TLqgE4WbimBYYyzTtrwDBbxbJ/a3/HWgq lDFU4t9fAjAUzTVQIaLDz6FmqTZzOBhiHOc8iqVl37/IA8uv0WxTWyhRVc46vm/ZihlY 8CCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=eQFHYmQy1AiCEsCizLiXazaLaGFTJpUzaVThKvfxj9s=; b=mxprv1VvCdOnQg17bbjOOSahGpuLcysUWNsXz1oLTOLo9az6QY90iYxjw698MDePLv zW8Nf/PoR8+ZNLfqJ7QvrsGt8FRG1uwWZJK4ijBLDeb6IDGr2opjrhn1rwZR0D1N6svq elki6fAYUrNgLVWDwHRPcKE7o1vx+o7YTFAPwuHnky8gf3c6gPh9luHU1dHpCulCl0wC c6Zm+Xk1NU6WSGoz1EQHa1h5+9sD4gJDPctKA5E++ayi1eal6l8IkJrkhygvehW2ZlbL A4AV7pbKOzl6XGeXTDt38UcVWYNaP4NV8mKhFquPpAc1VXJPcAh1E+wv33lcLMRGMKwK uing== X-Gm-Message-State: AOAM531zp5vYEFkprSdBLYehYGXO3pO6CBgKCjLpQA2IcfG61RHJT0Gf xwTREJP3kyb2l3KhyWINQiHcxeXzwL6wYw== X-Google-Smtp-Source: ABdhPJxfGRs8up/z1VPOEAAi8AeKz8QIWsXz52YY+z/CeCibQEdYhnTb8/OydGAeV1RxRi2FwJpJXw== X-Received: by 2002:a17:902:9a0c:b029:d6:c6a3:66f with SMTP id v12-20020a1709029a0cb02900d6c6a3066fmr1311207plp.52.1606169066342; Mon, 23 Nov 2020 14:04:26 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id 85sm2953857pfv.197.2020.11.23.14.04.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 14:04:25 -0800 (PST) To: dmarc@ietf.org References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> <7dbd9d27-83c9-2dc1-1ab9-8b585c9b87cb@gmail.com> From: Michael Thomas Message-ID: <36a4b361-67ae-4a3f-b062-24860adfed35@mtcc.com> Date: Mon, 23 Nov 2020 14:04:24 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <7dbd9d27-83c9-2dc1-1ab9-8b585c9b87cb@gmail.com> Content-Type: multipart/alternative; boundary="------------37AF7787E71271789491BC20" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 22:04:29 -0000 This is a multi-part message in MIME format. --------------37AF7787E71271789491BC20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/20 12:48 PM, Dave Crocker wrote: >> This recent article also goes into things that DKIM signatures imply: >> https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ >> > > The level of condescension, ignorance, and error throughout that > article is impressive.  Given that it was written by someone whose > profession requires extreme care about complex matters, the level of > carelessness in the article is especially unfortunate. > > Conveniently, he put his biggest error in bold font: > >      "*DKIM provides a life-long guarantee of email authenticity that > anyone can use to cryptographically verify the authenticity of stolen > emails, even years after they were sent."* > > DKIM does no such thing. > Yeah, that was pretty bad. "DKIM can be used to verify a piece of mail due to operator practices, but there are absolutely no guarantee that a signature will verify in the future due to those same practices." > > ps. making sure that DKIM signature become invalid  relatively soon -- > I think that removing the keys is simpler and just as effective as > publishing the private keys -- seems like a reasonable suggestion. > > Stephen Farrell is threatening to write an ID on the subject of publishing private keys. Frankly the stakeholders -- providers and users -- are not very well aligned on when where and why a provider would do such a thing. And writing an ID to say how to invalidate key when just unpublishing old selectors when you rotate keys is an easy second best shows that inertia is the actual issue, not the technical shortcoming. Mike --------------37AF7787E71271789491BC20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/23/20 12:48 PM, Dave Crocker wrote:
This recent article also goes into things that DKIM signatures imply:

The level of condescension, ignorance, and error throughout that article is impressive.  Given that it was written by someone whose profession requires extreme care about complex matters, the level of carelessness in the article is especially unfortunate.

Conveniently, he put his biggest error in bold font:

     "DKIM provides a life-long guarantee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent."

DKIM does no such thing.


Yeah, that was pretty bad. "DKIM can be used to verify a piece of mail due to operator practices, but there are absolutely no guarantee that a signature will verify in the future due to those same practices."


ps. making sure that DKIM signature become invalid  relatively soon -- I think that removing the keys is simpler and just as effective as publishing the private keys -- seems like a reasonable suggestion.


Stephen Farrell is threatening to write an ID on the subject of publishing private keys. Frankly the stakeholders -- providers and users -- are not very well aligned on when where and why a provider would do such a thing. And writing an ID to say how to invalidate key when just unpublishing old selectors when you rotate keys is an easy second best shows that inertia is the actual issue, not the technical shortcoming.

Mike

--------------37AF7787E71271789491BC20-- From nobody Mon Nov 23 14:30:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406EA3A13EE for ; Mon, 23 Nov 2020 14:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1KBpe5w0-2G for ; Mon, 23 Nov 2020 14:30:33 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C553A13EB for ; Mon, 23 Nov 2020 14:30:33 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id w187so1871961pfd.5 for ; Mon, 23 Nov 2020 14:30:33 -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-transfer-encoding:content-language; bh=JMY/s9PE/S8n0G6avuB5aIdPRTUkHlIZF7mCa8nbzh4=; b=LqUT28XixNVliZMN8IDVT2B29zG5v21Yos0jh/8w55wL+HFe8cP4bunZb3ySvDhiiw SIC9T1kngvr3fUgA0Cq+wH92xiU0igDfYsmmeVl3rwIwnGiMbPyUF2jIq9xtCnGbOvY1 EYvBS4ynQeMNEoATnWu11yuh3uu7CeAlVtUoIg2kF+7wAxUzHSl0bAMsHukmt9fyVR94 jRd6prbmGA+cfaHt9geXDaNptIr4R7t41EmE0SytrFIfFlnphSeSyWA0rFXWuNMObFoJ qBzKUsCvy5XavAaa02ydbEnzyXcKvFbigbLCrOztPZ9hvfZpnkx5o8krSl/4bKMCWn0C aGsg== 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-transfer-encoding :content-language; bh=JMY/s9PE/S8n0G6avuB5aIdPRTUkHlIZF7mCa8nbzh4=; b=qh/pu+dCqTUkb6nrZgFNoGKL+Ww+bssOxnAfFnJswXjbbF817lYy4/rpOOP/JFTyRT j8VMtrA0qZi32A9PU3yiUmETkAhPUQ5UqIqqLnE7o7C/VKVhhVQAXcMT0+ZA7LpOO18N wQC92/tPGqu17wTwXZ7JG3N1xhLvEUJqtvC6HwTEfmGp1keo4sJugc+q8fcVtWA9Mnep wwzyattAYA+udiBUZ+we9q24x0x9KWW6CL+uhjqDpN7fFbsIiGyUN+DgHXfg4pmMaGW3 SMk5mp3MttppxFQAcBWCz9GJ8F9PhxzuiazKqBwvirYW4wuv3Po+G8j5NoL7wKqhLyGb EuhA== X-Gm-Message-State: AOAM530Z5LxkyVxEhnKQ58mfJ3Qs57/4k5GvccQPUwATbmGVS8IrWD7d AfmyYsXsXROsYnl1RCPmc1kavOAnkYY= X-Google-Smtp-Source: ABdhPJz2Kcx540hnv+PPEoMYB3S6xD1Z1ykyE2voWWrsj06I6erIVzviBi8Y71U1TQH9JO4gMXAfRA== X-Received: by 2002:a63:1445:: with SMTP id 5mr1266305pgu.357.1606170632284; Mon, 23 Nov 2020 14:30:32 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 12sm383828pjt.25.2020.11.23.14.30.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 14:30:31 -0800 (PST) To: John Levine , dmarc@ietf.org References: From: Dave Crocker Message-ID: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> Date: Mon, 23 Nov 2020 14:30:30 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 22:30:34 -0000 On 11/23/2020 1:27 PM, John Levine wrote: > In article , > Dave Crocker wrote: >>> I believe, though, that the intent of ARC is that it be scalable in >>> ways that manual enumeration of known legit mailing lists and >>> forwarders is not. >> "if you know which hosts are legit" buries an assumption that is >> problematic, namely that you know who handled the message.  The fact >> that a message purports to be handled by a mailing list you trust does >> not mean it actually was. > Pretty close, but not quite. > > You know that a message came from a mailing list because you have your > list of IPs or DKIM signatures of lists you trust. Except that was not stated or, really, even implied in the text of the message I was replying to.  Rather, something like that seemed to be taken as an assumption, but without any clear foundation. For these kinds of discussions, which are mostly about understanding these capabilities clearly, accurately, and precisely, the core requirement is to separate the essential bits of information and the basis for knowing each bit. > ARC deals with the problem that most list software forwards everything > with a subscriber's address on the From: line and does a lousy job of > spam filtering. Forgive me but I believe misbehavior by mailing lists has never been meaningfully documented for this work.  Quite the contrary. List mail has been collateral damage, not because lists have misbehaved but because they got caught by a spontaneous change in the email service by some providers. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Mon Nov 23 14:42:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A264B3A08BD for ; Mon, 23 Nov 2020 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=GA40fTeN; dkim=pass (2048-bit key) header.d=taugh.com header.b=GbTH0sjs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB2eue6juL8T for ; Mon, 23 Nov 2020 14:42:26 -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 770DC3A08C5 for ; Mon, 23 Nov 2020 14:42:26 -0800 (PST) Received: (qmail 8279 invoked from network); 23 Nov 2020 22:42:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2055.5fbc3ad0.k2011; i=johnl-iecc.com@submit.iecc.com; bh=URm6OUUNg3/gZLJ1VncnVg139McbWyUAwwLb4V3omIQ=; b=GA40fTeNB2XNBpRRp7UEXevm9ZlD5F5/9FYbY292H+7h8zapSrnLDSuWNgL4jQj1ND3gFVU6G33T6gCDoOi3/TJa5vgHMBn6YjT84E/3eu9QiRjIZb5FC3ukvuDn6ZqnhIjFLMDovMWYk+JUQsDV5VSQF3pVFBO2py+n5JiJ7Sp/CvVDr8bZ/cYDRjR6QUkM/wIpSlxA7KIeJa6BsWswquIY+39/OyFwdFXu0mw0vKPb/TkAOreVpo8PAF/AFND5RQ8BsKMXgSq+zWvLqjgkmawLNQkp88KqOLJNfqRUOKnfqki+pWuDTOcn9gjaMf+bpMeX0d2Nwn2BtrueuXw+WA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=2055.5fbc3ad0.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=URm6OUUNg3/gZLJ1VncnVg139McbWyUAwwLb4V3omIQ=; b=GbTH0sjs++t19QmpeRfIorJdQlYUknnuC5/owgWQue2G6dp/pAAmQfewf2qp9atyCydmOD4wS5C0zCS2NDMZzntNgB8zBgjwPJJZfZt2sjkqqYE2GbJHM+CYByMgU2Hsd18sEjFEgs1i2zzWkVmkqhbC2z28anPvhRsYWrUo0LCP+oroiy/ReUtUIMYBZ5CTOP3KCoOYlyTTdkoe4d3kFU6P+DufUT4/MjoAUyz6WucdVaf+3VP7RGN6e+mGPr6vhmH0EsJyMhJ5YCLz0XMe35LcpJeCelo9SACB5TvjFg1WymVDwayi7+FZTU40i0MiiDg3cEX3VdizpGSzKlrl2w== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 23 Nov 2020 22:42:24 -0000 Date: 23 Nov 2020 17:42:23 -0500 Message-ID: From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> References: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1028258319-1606171344=:25011" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 22:42:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1028258319-1606171344=:25011 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT >> You know that a message came from a mailing list because you have your >> list of IPs or DKIM signatures of lists you trust. > > Except that was not stated or, really, even implied in the text of the > message I was replying to.  Rather, something like that seemed to be taken as > an assumption, but without any clear foundation. Well, OK, but it's still true. >> ARC deals with the problem that most list software forwards everything >> with a subscriber's address on the From: line and does a lousy job of >> spam filtering. > > Forgive me but I believe misbehavior by mailing lists has never been > meaningfully documented for this work.  Quite the contrary. I believe that Brandon has specifically said that Gmail sees this problem and that is why whitelisting mail from mailing lists isn't adequate. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1028258319-1606171344=:25011-- From nobody Mon Nov 23 14:52:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E853A0A4D for ; Mon, 23 Nov 2020 14:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo2lJkxIiaeO for ; Mon, 23 Nov 2020 14:52:02 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 4DDD43A0A47 for ; Mon, 23 Nov 2020 14:52:02 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id j19so15633192pgg.5 for ; Mon, 23 Nov 2020 14:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=k7lvgE2FUlo5lUyWmnmV84DVaBiEVoBztry+8hE6pxw=; b=Iq7zjI6aF6vF1bTN1S52ZtiR2Dg3yZb0wkl2DaUy8ClZFVjB9KUCtxDcEreSOnos+1 Mo8L4nqDvK1SygbqtnILc4Wespq8oVbFDfaZDA3veV3zajXBYc2cQZP5FNTqZRN6lIJ8 yTIFadBwoNhlOkkK+BvWjzVt/I82aTvza0ol6PUgt0yx2LFzOnUgTWX8pOBfi7tM8zyq z37aQoIdvWEaIjfiSMQSX7CSBC5ORBdVUSm0H+IoFS+AQnEvV/zbHXRkK61GJO1Tjk6S 9JLU+I/wRbWkn763YZoF0JhBpElYUsh6YLq7ISXPyKjmnDw9DDAhBRHmXvPOWiL0scYc BcAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=k7lvgE2FUlo5lUyWmnmV84DVaBiEVoBztry+8hE6pxw=; b=PlHijKmxdRYcg+mfNKu6PDVCAUE4EfNnvzSsQYJ22ZuGxunMqBCj6eGI9U8EDpgeiG +P8Xx195kZORvduZ2nbWi3uiASFuwNtqHNJvOjkBRAK2D46SjzcAw+kxqTj2XKhc/Ydc r1siwy9Y1TY6nf1GaH2kT/16h7Ioae2DluCF3eHKLxTqB5yYxtAuIVYJMVkXmp7Bghi4 ctPWTFupgW1WSxll6gSq22aLGfxCXyHjsTE37s897rVbolJvPRmEmc5m31R/eE7qeJHM PPH/FpI3IjSxN4X7G4E64hBEjVeyrxCpYCiWCIBMdxySqKT/pgo+6aCGyn4Nf/UANWHE GqXg== X-Gm-Message-State: AOAM533lq9vc3gcr8nNhAFYp79c7oFoEOWjQ91iujAFK428c8slk1IxR kXebSjj5d3q1JW8o5wldRY3gno5Jlgs= X-Google-Smtp-Source: ABdhPJy1kMeZ32W3WCH4TSUxobCX4P8UEIL3HStbwRgAkO1qLYm505wIRrmmA9rM0chuuAAp2EN5ow== X-Received: by 2002:a17:90a:8c8d:: with SMTP id b13mr1384146pjo.2.1606171921439; Mon, 23 Nov 2020 14:52:01 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id g9sm11456946pgk.73.2020.11.23.14.52.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 14:52:00 -0800 (PST) To: John R Levine , dmarc@ietf.org References: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> From: Dave Crocker Message-ID: <5eabd3b5-601b-f3c5-1ffa-80e7a8c4e52b@gmail.com> Date: Mon, 23 Nov 2020 14:51:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4FD5F39FAAD241EB8F0935E5" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 22:52:04 -0000 This is a multi-part message in MIME format. --------------4FD5F39FAAD241EB8F0935E5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/2020 2:42 PM, John R Levine wrote: >> Forgive me but I believe misbehavior by mailing lists has never been >> meaningfully documented for this work.  Quite the contrary. > > I believe that Brandon has specifically said that Gmail sees this > problem and that is why whitelisting mail from mailing lists isn't > adequate. And that constitute "meaningfully document[ing]"? My point wasn't that it isn't a valid concern, but that it was not explicitly stated as the motivation. Again: > ARC deals with the problem that most list software forwards everything > with a subscriber's address on the From: line and does a lousy job of > spam filtering. offers a characterization of mailing lists that hasn't been documented. And, again, when ARC work was pursued, I don't recall anyone claiming that mailing lists were (significant) sources of misbehavior. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------4FD5F39FAAD241EB8F0935E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/23/2020 2:42 PM, John R Levine wrote:
Forgive me but I believe misbehavior by mailing lists has never been meaningfully documented for this work.  Quite the contrary.

I believe that Brandon has specifically said that Gmail sees this problem and that is why whitelisting mail from mailing lists isn't adequate.

And that constitute "meaningfully document[ing]"?

My point wasn't that it isn't a valid concern, but that it was not explicitly stated as the motivation. Again:

ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering.
offers a characterization of mailing lists that hasn't been documented.

And, again, when ARC work was pursued, I don't recall anyone claiming that mailing lists were (significant) sources of misbehavior.

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------4FD5F39FAAD241EB8F0935E5-- From nobody Mon Nov 23 14:58:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4843A0B5D for ; Mon, 23 Nov 2020 14:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=aUY+44Ap; dkim=pass (2048-bit key) header.d=taugh.com header.b=XTM/hugx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptqPg2rtcKc0 for ; Mon, 23 Nov 2020 14:58:39 -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 81B4E3A0B5C for ; Mon, 23 Nov 2020 14:58:39 -0800 (PST) Received: (qmail 12686 invoked from network); 23 Nov 2020 22:58:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=318c.5fbc3e9e.k2011; i=johnl-iecc.com@submit.iecc.com; bh=FwkuCTSWci3UzAeeznayuDPaEpWWRhgQQyKoD5Nudqg=; b=aUY+44Ap255LexWeHLPPMhHrl2Q38YM4n7rdkqe9sb7+tee5h6h1fI7ri+M8g5yMszNAu06cWcYM+VXpqvFDbBBMMZsyB5GC9ff4ZLFs2vNwM/uHpLkcrf6NqWGYN+wJ776nvuTvffDCOnTcK40LsDrPPJym8qz9fs4M1d8tmavwo9h4Qn3J1BscDXdS1AK4edAo6iq2DLlwiw5AVpMrB+SPOU82kO2zn236zRbdgMG1+GLaFcEFU8q207nwUYKkydqugMgM9vwycXV/dXbBLLFJb6rqK6xyDXkycXPFCQTHfn57yeldpJxwurA9iRe4GlEtAnSM44+2FMapFkTUNg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=318c.5fbc3e9e.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=FwkuCTSWci3UzAeeznayuDPaEpWWRhgQQyKoD5Nudqg=; b=XTM/hugx0IFwny/0sdzdbRX65EfsCeUmyEf4olE4tzL9FaW2w0d25VzzbFgNu0EkmgxQxkwALei8pa6gSFgbxzOfAdA6oHq/UJqzkMBlyxfmhFvKsLMs0m71XNEMqAw9olhGZ9D9PLNuLBiDSXA1ioaftswvF2sZUt+txrRQkXX1wyB7v/4r2q5cqnpV5IeAPyUBM118uaDJd9tUbH1/5eViZWhn2QMH/Zi8VoYlHbrTZwUwpUDoZeulizg4aUZOcDRO4TNVLSlKSvRR2ZW1wqQ+jYjWE9sgSQy1VWJfeE12oTbmsq7g9OeS7VcKTd4lDCun38oEwizX+OC4I7O0Jw== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 23 Nov 2020 22:58:38 -0000 Date: 23 Nov 2020 17:58:37 -0500 Message-ID: <9b926abf-2f35-565c-c4fa-49be3fde64c1@taugh.com> From: "John R Levine" To: "Dave Crocker" , dmarc@ietf.org In-Reply-To: <5eabd3b5-601b-f3c5-1ffa-80e7a8c4e52b@gmail.com> References: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> <5eabd3b5-601b-f3c5-1ffa-80e7a8c4e52b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 22:58:41 -0000 >> I believe that Brandon has specifically said that Gmail sees this problem >> and that is why whitelisting mail from mailing lists isn't adequate. > > And that constitute "meaningfully document[ing]"? Works for me. I doubt I was the only person wondering why it needed all that mechanism when whitelisting mailing lists got you most of the way there, particularly since you need that whitelist anyway to know when to start ARC analysis. > And, again, when ARC work was pursued, I don't recall anyone claiming that > mailing lists were (significant) sources of misbehavior. Well, OK. Please feel free to provide footnoted documentation of what the actual motivation for ARC was if you believe it was something else. R's, John From nobody Mon Nov 23 15:00:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B06F3A0BB0 for ; Mon, 23 Nov 2020 15:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C2Fq3Yxze_5 for ; Mon, 23 Nov 2020 15:00:50 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 728D13A0BA0 for ; Mon, 23 Nov 2020 15:00:50 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id 81so15675158pgf.0 for ; Mon, 23 Nov 2020 15:00:50 -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-transfer-encoding:content-language; bh=9HmyM0Y1Jyi3eDDQz22wx+xgeL5x1xkpZTqaRn1rcvw=; b=vTEhJF8Ne9Hk9LmolGuC/6la1sn3+tz5FMgydSrI5qbRBy16NXStsc5ENwoxAyR68g 9LmjZhwE72KjeoJEdWRxgK+YsriY7ubQsNVxhZQNYU40wTYHjt/b8mJYbRtP+NJlXyHh sN5gZXvOv0a9uOyp4MiQr+xx/mU4bCiKUG72L09jnbSeRw6et+S0v9SKAomnDfSUwHfG FAHSq6JLhazrCt8zrlW3GyzHxw01Pc+jIgblEYNEKMuulB0OaRp2w8CVQXw18/twwYXy L6RsMoIVIMYtccL7D8U1s37W46Cpe+sI7HAG6NcirYYxtrn0xhblL9fSedqu8iQmAUwP mYVA== 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-transfer-encoding :content-language; bh=9HmyM0Y1Jyi3eDDQz22wx+xgeL5x1xkpZTqaRn1rcvw=; b=VUQ8BaCVaEUgOCd6b5fhaDZuJ3hlWFtzMjyGJnGIl9hxCJFrUsDcotJ+CeUEExslWj JFi+1kIOWcsz5tu3wNplD+85MKV6oakHT0TviMSwy0W6vxPYRNyXxrqLQCkDOoaWp2AJ q4RQtYNmuCSu6VRQ3zKRrEFgSIttI9qhTgBSOWwbDG2E1Q3RrjE0xjhI3GUYIwyhMFfl 41VX5pekJIhdpxNxWdi9zvUZsVnEXv+Q1Qy1MP1v1piWV9NtZFs1fAp0RaSwxqwC9PAu l0FUEyfiJREZmZnbjUDgshglvqAiqDqmQ3URQ/iXvHVe4WkFeB//RYT2j/dRjRHg1ldI GZDQ== X-Gm-Message-State: AOAM533DgdSN+gfYy3hwL2xBVoHUchwSKWaPvwALr8mFZSZmxnPSY56R 7ocCKr0ALCepiEkDZ01t/cVvhVhtiHs= X-Google-Smtp-Source: ABdhPJwE1F2QMWHRzhrLrZ8xmQdefVCg9Tht5d4rHcIAPY0OKbDebByNE0DH37JC1G/q0+eXdzfXew== X-Received: by 2002:a17:90a:f0c7:: with SMTP id fa7mr1332203pjb.3.1606172449821; Mon, 23 Nov 2020 15:00:49 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id l17sm423535pjy.29.2020.11.23.15.00.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 15:00:49 -0800 (PST) To: John R Levine , dmarc@ietf.org References: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> <5eabd3b5-601b-f3c5-1ffa-80e7a8c4e52b@gmail.com> <9b926abf-2f35-565c-c4fa-49be3fde64c1@taugh.com> From: Dave Crocker Message-ID: <0f1055bd-ef55-2e0d-499a-d2295a4630e6@gmail.com> Date: Mon, 23 Nov 2020 15:00:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <9b926abf-2f35-565c-c4fa-49be3fde64c1@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 23:00:52 -0000 On 11/23/2020 2:58 PM, John R Levine wrote: >> And, again, when ARC work was pursued, I don't recall anyone claiming >> that mailing lists were (significant) sources of misbehavior. > Well, OK.  Please feel free to provide footnoted documentation of what > the actual motivation for ARC was if you believe it was something else. Typically, the burden of substantiating a claim falls on the person making the affirmative claim. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Mon Nov 23 15:51:19 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1364A3A1148 for ; Mon, 23 Nov 2020 15:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 95FEFvWVmUJC for ; Mon, 23 Nov 2020 15:51:15 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 3B9FE3A1146 for ; Mon, 23 Nov 2020 15:51:15 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id 34so15753634pgp.10 for ; Mon, 23 Nov 2020 15:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=oZxmmVt/iP9/mkDrCYYMaAVeS0PwhBakwnBX/U7swAs=; b=ueEWMUHySD457A+fR4OXhlQ+Th8HRZP1GxrcM2rJKjZCaxUyy3Sjgt4C/0cwjo835c MHr0soNRnFPYHIUEb1nwpQLXgO0FzAbYW+s0RSdQ41612qFkeHEBSeDU1Rs0ypqqjrv9 G5WXr88vc1gvyBijaWMZjQoPQawOnrsaVd+oUk/DH/I2Ya3/6mFXzLLSwPjkUdz44jEa 44jD58fcAo7HJ9sdnTZzBeh3qKU4KdI/MT2aUYCKSj0vTSR2BEVKb/oet/MbqLNC/vIy Vm7OdD41rHamWOHwoveppjB9ji7iQzUM70y5AR3t5gLITwS1+ofVeEq7fNbIVyK3kSet nPfA== 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-transfer-encoding :content-language; bh=oZxmmVt/iP9/mkDrCYYMaAVeS0PwhBakwnBX/U7swAs=; b=omR66c2kQRY9fuopLguWE1XTya/4Q316qq4JpQj7f38mWPs20dpfL4VCaPdCAPRae5 s+MSi0QhItW8mZO/DJmImTKP5dgVV2eWTBiC+SFGLo+4NnUBdSy24XrY7HotxfrUakwq YXla67CK8VpgRr3hbFUm/xg8Kq+j9U6pwS5058g00QokPT5NWIYt8GIFTpsO3V6a1iy8 A8wi1XewHnF7zQBNkFeg9E8nrx1mrNjFQ4HmoOr26zCdpbmr2riArV34hb/jmklfsYiD 2J+P/2zq1nkwIGb+UMiPS1yOQmZV8NUhkEJy9L00CJA25cZanaquSmReKFM03z688wWS R8qg== X-Gm-Message-State: AOAM530x93YsZ8G0FmqOMhpkd6UTxmq4FjKMrViU0NhUKtU4908ZW/Fs EaA8312yr0Rexm+hDT2zaTLiqwTCdufq8Q== X-Google-Smtp-Source: ABdhPJyi9GWdVG3G0njIHuJwVgKu6mS+uKKKX8S0v/cHxsEtejFcdPMvL/cLrLfkpWNXIL93PtOUog== X-Received: by 2002:a62:7a47:0:b029:160:193:76bc with SMTP id v68-20020a627a470000b0290160019376bcmr1732204pfc.24.1606175474078; Mon, 23 Nov 2020 15:51:14 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id s10sm3354572pgh.40.2020.11.23.15.51.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 15:51:13 -0800 (PST) To: dmarc@ietf.org References: <4a800bd1-0334-137b-ab71-b98cc1d038cc@gmail.com> <5eabd3b5-601b-f3c5-1ffa-80e7a8c4e52b@gmail.com> <9b926abf-2f35-565c-c4fa-49be3fde64c1@taugh.com> <0f1055bd-ef55-2e0d-499a-d2295a4630e6@gmail.com> From: Michael Thomas Message-ID: Date: Mon, 23 Nov 2020 15:51:12 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <0f1055bd-ef55-2e0d-499a-d2295a4630e6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Nov 2020 23:51:18 -0000 On 11/23/20 3:00 PM, Dave Crocker wrote: > On 11/23/2020 2:58 PM, John R Levine wrote: >>> And, again, when ARC work was pursued, I don't recall anyone >>> claiming that mailing lists were (significant) sources of misbehavior. >> Well, OK.  Please feel free to provide footnoted documentation of >> what the actual motivation for ARC was if you believe it was >> something else. > > > Typically, the burden of substantiating a claim falls on the person > making the affirmative claim. > What I'm struggling to understand is what having authenticated auth-res from a previous hop helps. this is what i found: "With this information, Internet Mail Handlers MAY inform local policy decisions regarding disposition of messages that experience authentication failure due to intermediate processing." that and: "When an Authenticated Received Chain is used to determine message disposition, the DMARC processor can communicate this local policy decision to Domain Owners as described in Section 7.2.2." seems to be the only motivation I can find. without ARC, a receiver could always check the new DKIM signature from, say, the mailing list and look up its reputation to decide whether to pass it along or not overriding the originating domain's policy. my recollection was that this was the "you break it, you own it" policy which i recall being the consensus. and indeed, there is nothing to stop a filter to look at the mailing list's auth-res and take it into account even if it's not part of the headers in the signature. maybe there is some attack there i'm not seeing off the top of my head, but it seems like this really hinges on reputation as was pointed out to me earlier. It would be kind of nice to understand what gap ARC actually plugs and why it's important if you ask me. Also: there seem to be a lot of ways to achieve this, but this one is probably the most complicated one that I can envision. Mike From nobody Mon Nov 23 16:13:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D22F3A1290 for ; Mon, 23 Nov 2020 16:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ckv9ppY3YE-J for ; Mon, 23 Nov 2020 16:13:47 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 B386F3A1260 for ; Mon, 23 Nov 2020 16:13:47 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id y73so10145484vsc.5 for ; Mon, 23 Nov 2020 16:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mIxYqMmNyfnAkxhYRypfwo8kqBymTALQHqVqwTHgeeA=; b=p9wbUWqF4Cnfr04hBUOf7lc8CWyHqRUY8X1KiqOWNynwxP2PUmWspOODkvhp9yTF1d qHVHZhXcVS3WinVNbK4MmDJ+qtrbTY/sqfsXR0pOTkRcoz6CUonXvy0o0ok33xKKQ8BH DgCLwYZ1Bimc1rGuuRVWrMI/8FcAndSYTqKwDUiY42n6d9Rhw1u21SKmsUZL+J7otaKg RhM561RxJdlmRgSYTabFFpXhOsKX/P0dqwin44eliwMIcUFBUZaZZhRxQb7OwHU/1lpO ZX0vji+VSl8/3S/EXaha7Kiq2T2jozl2yMHXAIhLcOLMo/+mTm2sKc6JDutXou6gH5QX tmFw== 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=mIxYqMmNyfnAkxhYRypfwo8kqBymTALQHqVqwTHgeeA=; b=CI4DWVi+v70W5PExFWv5Ssg2C3oHkr9+0wS8s7gsWdjeWkp2zDgEAF1umulcfHP3HJ AweSk6EaSJLihryBGmYxCvafOZ9HVyOcA65r7ZphhExj3wlK7AvBofAmLqQwqg7vTXQe FsSDdyv10qSLWOMFYXzAej0mNO+mt4BYPXvS3CthlXXdPXuP0pfRFy9BRhnPqYq9r+dF oS4QOl1O2vUvF4DGVckLlibVNU8fmxj2tYGtBGarDVaoMNgxWgyOVoYnnZU21yR2g9oG hzFUTzHF1nHRoRR21YjvpvBMX7c4kveXXRsku1UcHWj8ydJ821k4l/PJi+DUp3+EgzgS t5+w== X-Gm-Message-State: AOAM530dUrHRZvv0kLDTycZwyEX0lP6XVMMcTNtAVDUuTtwGc/UkT1az B10o5tmEcrBFik9tSipPqmEEBOx2hkem8aeyC3IDnbFzVD6a X-Google-Smtp-Source: ABdhPJx2IwjrevwiPVykyebICdcntzRc3csfjE4oUyU6FFV/lkO70Aqmb+lcpe7MMO087MAyuOBF+gKDQnDzk7LhbVw= X-Received: by 2002:a67:fb87:: with SMTP id n7mr1839379vsr.58.1606176826444; Mon, 23 Nov 2020 16:13:46 -0800 (PST) MIME-Version: 1.0 References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> <7dbd9d27-83c9-2dc1-1ab9-8b585c9b87cb@gmail.com> In-Reply-To: <7dbd9d27-83c9-2dc1-1ab9-8b585c9b87cb@gmail.com> From: Brandon Long Date: Mon, 23 Nov 2020 16:13:31 -0800 Message-ID: To: Dave Crocker Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003033a405b4cf2fb3" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 00:13:57 -0000 --0000000000003033a405b4cf2fb3 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker wrote: > On 11/23/2020 12:15 PM, Brandon Long wrote: > > On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker wrote: > >> > Yes, of course, a handling agent can do it, but there are plenty of >> reasons >> > why they shouldn't. >> >> Please enumerate and explain. If it's that dangerous, we should >> document it, especially I don't recall that constraint being in any of >> the design or standardization discussions. >> > > DKIM often ties a domain to reputation and other anti-spam features. If > you > forward spam to another host and sign it while forwarding, then the other > host > will think you send spam. > > Well, ummm... errrr... yes. That's because, in such circumstances, you do. > > More significantly, the signature makes sure that such as an assessment > will only be made accurately, rather than penalizing you for problematic > mail that is attributed to you but that you did not handle. > If the result is marking all of the mail from that mailing list as spam, then you've likely done your users a disservice. Being able to differentiate is useful. Also, forwarders often don't have all of the signals that the user's mailbox does.. not the least of which is that different recipients have different judgements on what is spam, and the "this is spam" signal rarely makes it back to the forwarder. > DMARC ties DKIM to the From header and at least is interpreted as being an > anti-phishing feature. DKIM signing mail that you forward could mean > upgrading > a phishing message to passing DMARC. > > I don't understand. The first sentence makes sense to me, but the second > doesn't. > > "Upgrading...to passing DMARC only applies if a) the signature matches the > From: field domain, and b) that domain has an associated DMARC record. But > if you don't watch DMARC to apply in that case, what is the DMARC record > there fore? > I send a phishing message to a mailing list or alias at a domain with a >From header of that domain, and the list blindly re-signs all mail sent to the list, I've now "authenticated" the spoofed message, and it will now "pass" DMARC. Perhaps it upgraded from a quarantine to none, since the mailing list doesn't have the concept of a spam folder, or perhaps the sales@ team has decided they want all of the forwarded messages, even if probably spam, so that they can go through them to make sure... but it lost the quarantine disposition on the forward when it gained authentication. This recent article also goes into things that DKIM signatures imply: > > https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ > > The level of condescension, ignorance, and error throughout that article > is impressive. Given that it was written by someone whose profession > requires extreme care about complex matters, the level of carelessness in > the article is especially unfortunate. > > Conveniently, he put his biggest error in bold font: > > "*DKIM provides a life-long guarantee of email authenticity that > anyone can use to cryptographically verify the authenticity of stolen > emails, even years after they were sent."* > > DKIM does no such thing. > > and this was quickly followed by the normal-font: > > "The key design goal of DKIM was to prevent spammers from forging > emails *while in transit*. " > > This, too, is not what DKIM does. DKIM provides a noise-free channel for > assessing signers, not for detecting spammers. The difference is > important; and I claim fundamental. > > ps. making sure that DKIM signature become invalid relatively soon -- I > think that removing the keys is simpler and just as effective as publishing > the private keys -- seems like a reasonable suggestion. > > > Perhaps this all means that DKIM has been used for more than it was > intended for. > > "More than" suggests that the use has legitimacy. It doesn't. > We don't always have control over how our work is used. If I proposed extending a standard in a new direction that would be perfectly fine with the original intent of the standard, and that clashed with how the standard had come to be used in practice, my extension is DOA. > > > Intermediaries don't want to take ownership of the message in that >> > > sense, though there >> > > are some mailing lists that do. >> > >> > Signing with DKIM does not take 'ownership'. >> > >> > >> > Yes, responsibility is the proper word. My point survives the word >> change. >> >> I disagree. >> >> >> > DKIM says the domain takes responsibility for the message, while ARC >> says >> > the domain takes responsibility for evaluating the status of the >> message >> > when >> > they received and forwarded it. >> >> This implies that the word 'some' is irrelevant. It isn't. And it was >> included intentionally. >> > > Automated systems can't really tell how much responsibility an > intermediary was > intending to take for the message. > > People who write them can. > > > OTOH, they typically are using it only for a certain > purpose, so they assume that the intermediary took responsibility in the > sense that they > want... or rather, the people who wrote the code do. Or the journalist > writing the story. > > ARC was specified to have a more specific responsibility, > > Forgive me but I think that: > > Authenticated Received Chain (ARC) creates a mechanism for individual > Internet Mail Handlers to add their authentication assessment to a > message's ordered set of handling results. > > > specifies a nature and responsibility pretty much identical to what DKIM > claims. The enhancements are a) chaining, and b) carriage of earlier > assessments. But in terms of 'responsibility', this reads the same as DKIM. > I don't see how "claim some responsibility" is the same as "add their authentication assessment". I guess they are claiming responsibility for the assessment, but that's a very specific thing, and not the "some [unknown] responsibility" > and as different from DKIM so > that it wasn't mistaken for the uses that people were already using DKIM > for. > > Oh? > This was definitely a topic of discussion during the initial meetings where we went from XOAR to ARC. Brandon --0000000000003033a405b4cf2fb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 23, 2020 at 12:48 PM Dave= Crocker <dcrocker@gmail.com&g= t; wrote:
=20 =20 =20
On 11/23/2020 12:15 PM, Brandon Long wrote:
=20
On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker <dcrocker@gmail.com> wrote:
> Yes, of co= urse, a handling agent can do it, but there are plenty of reasons
> why they shouldn't.

Please enumerate and explain.=C2=A0 If it's that dangerous,= we should
document it, especially I don't recall that constraint bein= g in any of
the design or standardization discussions.

DKIM often ties a domain to reputation and other anti-spam features.=C2=A0 If you
forward spam to another host and sign it while forwarding, then the other host
will think you send spam.

Well, ummm... errrr... yes.=C2=A0 That's because, in such circumstances, you do.

More significantly, the signature makes sure that such as an assessment will only be made accurately, rather than penalizing you for problematic mail that is attributed to you but that you did not handle.

If the result is marking a= ll of the mail from that mailing list as spam, then you've likely done = your users a disservice.=C2=A0 Being able to differentiate is useful.=C2=A0= Also, forwarders often don't have all of
the signals that th= e user's mailbox does.. not the least of which is that different recipi= ents have different judgements on what is spam, and the "this is spam&= quot; signal rarely makes it back to the forwarder.
DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature.=C2=A0 DKIM signing mail that you forward could mean upgrading
a phishing message to passing DMARC.

I don't understand.=C2=A0 The first sentence makes sense to me, = but the second doesn't.=C2=A0

"Upgrading...to passing DMARC only applies if a) the signature matches the From: field domain, and b) that domain has an associated DMARC record.=C2=A0 But if you don't watch DMARC to ap= ply in that case, what is the DMARC record there fore?

I send a phishing message to a mailing list or alias at a domain with= a From header of that domain, and the list blindly
re-signs all = mail sent to the list, I've now "authenticated" the spoofed m= essage, and it will now "pass" DMARC.=C2=A0 Perhaps it
= upgraded from a quarantine to none, since the mailing list doesn't have= the concept of a spam folder, or perhaps the sales@ team
has dec= ided they want all of the forwarded messages, even if probably spam, so tha= t they can go through them to make sure...
but it lost the quaran= tine disposition on the forward when it gained authentication.
This recent article also goes into things that DKIM signatures imply:

The level of condescension, ignorance, and error throughout that article is impressive.=C2=A0 Given that it was written by someone who= se profession requires extreme care about complex matters, the level of carelessness in the article is especially unfortunate.

Conveniently, he put his biggest error in bold font:

=C2=A0=C2=A0=C2=A0=C2=A0 "DKIM provides a life-long guar= antee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent.&quo= t;

DKIM does no such thing.

and this was quickly followed by the normal-font:

=C2=A0=C2=A0 "The key design goal of DKIM was to prevent spamme= rs from forging emails while in transit. "

This, too, is not what DKIM does.=C2=A0 DKIM provides a noise-free channel for assessing signers, not for detecting spammers.=C2=A0 The difference is important; and I claim fundamental.

ps. making sure that DKIM signature become invalid=C2=A0 relatively soon -- I think that removing the keys is simpler and just as effective as publishing the private keys -- seems like a reasonable suggestion.


Perhaps this all means that DKIM has been used for more than it was intended for.

"More than" suggests that the use has legitimacy.=C2=A0 It= doesn't.

We don't always have control o= ver how our work is used.=C2=A0 If I proposed extending a standard in a new= direction that would
be perfectly fine with the original intent = of the standard, and that clashed with how the standard had come to be used= in=C2=A0
practice, my extension is DOA.
>=C2=A0 =C2=A0 =C2=A0 > Intermediaries don't want to = take ownership of the message in that
>=C2=A0 =C2=A0 =C2=A0 > sense, though there
>=C2=A0 =C2=A0 =C2=A0 > are some mailing lists that do. >
>=C2=A0 =C2=A0 =C2=A0Signing with DKIM does not take 'ow= nership'.
>
>
> Yes, responsibility is the proper word.=C2=A0 My point survives the word change.

I disagree.


> DKIM says the domain takes responsibility for the message, while ARC says
> the domain takes responsibility for evaluating the status of the message
> when
> they received and forwarded it.

This implies that the word 'some' is irrelevant.=C2=A0 = It isn't.=C2=A0 And it was
included intentionally.

Automated systems can't really tell how much responsibility an intermediary was
intending to take for the message.

People who write them can.


OTOH, they typically are using it only for a certain
purpose, so they assume that the intermediary took responsibility in the sense that they
want... or rather, the people who wrote the code do.=C2=A0 O= r the journalist writing the story.

ARC was specified to have a more specific responsibility,

Forgive me but I think that:

   Authenticated Received Chain (ARC) creates a mechanism for in=
dividual
   Internet Mail Handlers to add their authentication assessment to a
   message's ordered set of handling results.

specifies a nature and responsibility pretty much identical to what DKIM claims.=C2=A0 The enhancements are a) chaining, and b) carriage of earlier assessments.=C2=A0 But in terms of 'responsibility', th= is reads the same as DKIM.

I don't= see how "claim some responsibility" is the same as "add the= ir authentication assessment".=C2=A0 I guess they are claiming
responsibility for the assessment, but that's a very specific thing,= and not the "some [unknown] responsibility"
and as different from DKIM so
that it wasn't mistaken for the uses that people were already using DKIM for.
Oh?=C2=A0

This was definitely a t= opic of discussion during the initial meetings where we went from XOAR to A= RC.

Brandon
--0000000000003033a405b4cf2fb3-- From nobody Mon Nov 23 17:09:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB493A14D0 for ; Mon, 23 Nov 2020 17:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4klbwNT-1GgL for ; Mon, 23 Nov 2020 17:09:47 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 EB9B63A14C9 for ; Mon, 23 Nov 2020 17:09:46 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id s63so6049835pgc.8 for ; Mon, 23 Nov 2020 17:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=RhHnxozRh9cw5KciwtkQmLhmmw2/eEzZOYcptwjiwA4=; b=NKC55EoVULy3ty2U7Csga43VcBIgLJuQ7IXa269zgq+qi5HSKWlYXfoGH5xllDSTVs GrGGFqWVb8bXt1nwxyZoQAFAKdiPzEE0rlkWiGoMBHpvGCdLMIusfyB4mlHiY1eRSaKs AVvlAXzbi/nqQz1QC+R1q/k0/870iSWVDsuwXOGNcJiZTTgQLIgx0lcioabMA5wc40U2 IbKSMZmbKjxoiZ8V9jlMHqMdEsGxt1L30ah0+O5xJrmHW2WMXGEudWqYCB/VYz99EE2m gRetF8mp02pKCL2PcT/cqTRCX4+B9/dAae9vXO6PGdzo7agbYFA5fXXfvUHqszjxiv0M PmZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=RhHnxozRh9cw5KciwtkQmLhmmw2/eEzZOYcptwjiwA4=; b=tTMDggfOgJU2GxEqodgYgSJvGaREnHjeHgBrysHTT9hKtHfp0nWSZ2fT1NMDIaSCJe OfVdbZyUmitFMkEGpg3cOsiDvHMZSbOQpfSUFWR2oh8NUxuwtDbBjmJmoDeRQHXvQePz kECN7JNBxRSzJg76ST+gWILJwnjM5RxKwhEN0ij7uXdsLfXWNqoWcceHrK2e+JWRmbbt BySIRbQiz4ak39rggVlPqQWSla/kxv1wpq/UZYQVha68MNj30qfcGmeYIVfjnjOQj9Gf AkNosWKUqiVnkBYE59LzNj9RXAGYYLf/XJDhbig8Lwzoka1WmVYg2xG2H3+lkqhJyUqg vmwg== X-Gm-Message-State: AOAM532S1SG0T/+bil2ZuK+3wm9OCZImTAgKBYI6TdpDhzP07/Spf0Vc 1Xnae9E4P+Xo/aSa24rvKORUDXYR3to= X-Google-Smtp-Source: ABdhPJyxxzp+YF520Jvh0Z6UCG0LkDMuSRuNJPLdTq7QJVg8Izd9OJXbg9WEs3aruKtdi70rJt3icw== X-Received: by 2002:a17:90b:4a0c:: with SMTP id kk12mr1738506pjb.205.1606180186273; Mon, 23 Nov 2020 17:09:46 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id c6sm599156pjr.55.2020.11.23.17.09.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Nov 2020 17:09:45 -0800 (PST) To: Brandon Long Cc: "dmarc@ietf.org" References: <20201122021417.B5E6E27B3E59@ary.qy> <453c4db4-fc62-dc76-5b15-707623d66f9f@mtcc.com> <64f18b-ae8-8c15-3d33-ff2d864c35bc@taugh.com> <884541e6-5076-7f8f-d1d2-d68ea9c5a2bc@mtcc.com> <40aa3391-84fb-bd2d-92ab-e268c674d4a4@gmail.com> <7dbd9d27-83c9-2dc1-1ab9-8b585c9b87cb@gmail.com> From: Dave Crocker Message-ID: Date: Mon, 23 Nov 2020 17:09:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7719A0518F02E57CDBC66F2F" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 01:09:49 -0000 This is a multi-part message in MIME format. --------------7719A0518F02E57CDBC66F2F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/23/2020 4:13 PM, Brandon Long wrote: > > > On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker > wrote: > > On 11/23/2020 12:15 PM, Brandon Long wrote: >> On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker > > wrote: >> DKIM often ties a domain to reputation and other anti-spam >> features.  If you >> forward spam to another host and sign it while forwarding, then >> the other host >> will think you send spam. > > Well, ummm... errrr... yes.  That's because, in such > circumstances, you do. > > More significantly, the signature makes sure that such as an > assessment will only be made accurately, rather than penalizing > you for problematic mail that is attributed to you but that you > did not handle. > > If the result is marking all of the mail from that mailing list as > spam, then you've likely done your users a disservice. Why would you put forward a hypothetical that might reasonably be characterized as unreasonable, especially given that you also make clear why it is unreasonable? (*) > Being able to differentiate is useful.  Also, forwarders often don't > have all of > the signals that the user's mailbox does.. not the least of which is > that different recipients have different judgements on what is spam, > and the "this is spam" signal rarely makes it back to the forwarder. Except that mailing lists are also recipients, notably including likely history from authors, and possibly more history than a final recipient? There are, of course, possible signals a final recipient might have about an author, that the mailing list won't have. Equally there might be others the list has that the final recipient doesn't, such as knowing about other mail from the author, to other lists the mailing list system operates... >> DMARC ties DKIM to the From header and at least is interpreted as >> being an >> anti-phishing feature.  DKIM signing mail that you forward could >> mean upgrading >> a phishing message to passing DMARC. > > I don't understand.  The first sentence makes sense to me, but the > second doesn't. > > "Upgrading...to passing DMARC only applies if a) the signature > matches the From: field domain, and b) that domain has an > associated DMARC record.  But if you don't watch DMARC to apply in > that case, what is the DMARC record there fore? > > I send a phishing message to a mailing list or alias at a domain with > a From header of that domain, and the list blindly > re-signs all mail sent to the list, I've now "authenticated" the > spoofed message, and it will now "pass" DMARC. There are so many different ways this represents really poor mailing list setup, operation and possibly design, I again wonder at your offering it as an example of any point relevant to this exchange. It's not that what you suggest hasn't happened, it's that the fact that it represents multiple problems also suggests it can -- and probably should -- have multiple solutions. > Perhaps it > upgraded from a quarantine to none, since the mailing list doesn't > have the concept of a spam folder, or perhaps the sales@ team > has decided they want all of the forwarded messages, even if probably > spam, so that they can go through them to make sure... > but it lost the quarantine disposition on the forward when it gained > authentication. More problematic hypotheticals, all of which arguably represent poor services, just as originators can be poorly run services. >> Perhaps this all means that DKIM has been used for more than it >> was intended for. > > "More than" suggests that the use has legitimacy.  It doesn't. > > We don't always have control over how our work is used. No, but we do have control over a) how we write about it, b) how we talk about it, and c) what we do about misuses of the work. You appear to be taking the view that however others choose to interpret a specification is what the specification is for and how it operates.  Except that that is only one -- and I'd argue highly problematic -- approach to misuses of a specification. > If I proposed extending a standard in a new direction that would > be perfectly fine with the original intent of the standard, and that > clashed with how the standard had come to be used in > practice, my extension is DOA. Possibly.  But not automatically. For reference, note that 90+% of email is spam.  Does that mean that a proposal to counter that (inappropriate) use of email is DOA?  That seems to be the logic you've applied. > Forgive me but I think that: > >> Authenticated Received Chain (ARC) creates a mechanism for individual >> Internet Mail Handlers to add their authentication assessment to a >> message's ordered set of handling results. > > specifies a nature and responsibility pretty much identical to > what DKIM claims.  The enhancements are a) chaining, and b) > carriage of earlier assessments.  But in terms of > 'responsibility', this reads the same as DKIM. > > > I don't see how "claim some responsibility" is the same as "add their > authentication assessment".  I guess they are claiming > responsibility for the assessment, but that's a very specific thing, > and not the "some [unknown] responsibility" I cited assessment as a difference.  And yes, that's the only difference in responsibility.  Otherwise, it's just an authentication of having processed the message. >> and as different from DKIM so >> that it wasn't mistaken for the uses that people were already >> using DKIM for. > Oh? > > > This was definitely a topic of discussion during the initial meetings > where we went from XOAR to ARC. Sorry, I don't recall that. d/ (*) https://en.wikipedia.org/wiki/Straw_man -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------7719A0518F02E57CDBC66F2F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/23/2020 4:13 PM, Brandon Long wrote:


On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker <dcrocker@gmail.com> wrote:
On 11/23/2020 12:15 PM, Brandon Long wrote:
On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker <dcrocker@gmail.com> wrote:
DKIM often ties a domain to reputation and other anti-spam features.  If you
forward spam to another host and sign it while forwarding, then the other host
will think you send spam.

Well, ummm... errrr... yes.  That's because, in such circumstances, you do.

More significantly, the signature makes sure that such as an assessment will only be made accurately, rather than penalizing you for problematic mail that is attributed to you but that you did not handle.

If the result is marking all of the mail from that mailing list as spam, then you've likely done your users a disservice.

Why would you put forward a hypothetical that might reasonably be characterized as unreasonable, especially given that you also make clear why it is unreasonable? (*)


Being able to differentiate is useful.  Also, forwarders often don't have all of
the signals that the user's mailbox does.. not the least of which is that different recipients have different judgements on what is spam, and the "this is spam" signal rarely makes it back to the forwarder.

Except that mailing lists are also recipients, notably including likely history from authors, and possibly more history than a final recipient?

There are, of course, possible signals a final recipient might have about an author, that the mailing list won't have. Equally there might be others the list has that the final recipient doesn't, such as knowing about other mail from the author, to other lists the mailing list system operates...


DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature.  DKIM signing mail that you forward could mean upgrading
a phishing message to passing DMARC.

I don't understand.  The first sentence makes sense to me, but the second doesn't. 

"Upgrading...to passing DMARC only applies if a) the signature matches the From: field domain, and b) that domain has an associated DMARC record.  But if you don't watch DMARC to apply in that case, what is the DMARC record there fore?

I send a phishing message to a mailing list or alias at a domain with a From header of that domain, and the list blindly
re-signs all mail sent to the list, I've now "authenticated" the spoofed message, and it will now "pass" DMARC.

There are so many different ways this represents really poor mailing list setup, operation and possibly design, I again wonder at your offering it as an example of any point relevant to this exchange.

It's not that what you suggest hasn't happened, it's that the fact that it represents multiple problems also suggests it can -- and probably should -- have multiple solutions.


Perhaps it
upgraded from a quarantine to none, since the mailing list doesn't have the concept of a spam folder, or perhaps the sales@ team
has decided they want all of the forwarded messages, even if probably spam, so that they can go through them to make sure...
but it lost the quarantine disposition on the forward when it gained authentication.

More problematic hypotheticals, all of which arguably represent poor services, just as originators can be poorly run services.


Perhaps this all means that DKIM has been used for more than it was intended for.

"More than" suggests that the use has legitimacy.  It doesn't.

We don't always have control over how our work is used.

No, but we do have control over a) how we write about it, b) how we talk about it, and c) what we do about misuses of the work.

You appear to be taking the view that however others choose to interpret a specification is what the specification is for and how it operates.  Except that that is only one -- and I'd argue highly problematic -- approach to misuses of a specification.


If I proposed extending a standard in a new direction that would
be perfectly fine with the original intent of the standard, and that clashed with how the standard had come to be used in 
practice, my extension is DOA.

Possibly.  But not automatically.

For reference, note that 90+% of email is spam.  Does that mean that a proposal to counter that (inappropriate) use of email is DOA?  That seems to be the logic you've applied.


Forgive me but I think that:

   Authenticated Received Chain (ARC) creates a mechanism for individual
   Internet Mail Handlers to add their authentication assessment to a
   message's ordered set of handling results.

specifies a nature and responsibility pretty much identical to what DKIM claims.  The enhancements are a) chaining, and b) carriage of earlier assessments.  But in terms of 'responsibility', this reads the same as DKIM.

I don't see how "claim some responsibility" is the same as "add their authentication assessment".  I guess they are claiming
responsibility for the assessment, but that's a very specific thing, and not the "some [unknown] responsibility"

I cited assessment as a difference.  And yes, that's the only difference in responsibility.  Otherwise, it's just an authentication of having processed the message.


and as different from DKIM so
that it wasn't mistaken for the uses that people were already using DKIM for.
Oh? 

This was definitely a topic of discussion during the initial meetings where we went from XOAR to ARC.

Sorry, I don't recall that.


d/


(*) https://en.wikipedia.org/wiki/Straw_man

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------7719A0518F02E57CDBC66F2F-- From nobody Mon Nov 23 18:05:00 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6234D3A0E8A for ; Mon, 23 Nov 2020 18:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=HbkX8cBg; dkim=pass (2048-bit key) header.d=taugh.com header.b=Voj4mi7Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK8BVzant4EY for ; Mon, 23 Nov 2020 18:04: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 3CD203A0E88 for ; Mon, 23 Nov 2020 18:04:56 -0800 (PST) Received: (qmail 53558 invoked from network); 24 Nov 2020 02:04: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:cleverness; s=d131.5fbc6a46.k2011; bh=GMwj+/EMbT3eNwIZBrXuGbi9JZskwOSrvaeaV6womxU=; b=HbkX8cBgzaCteyE+X9Yd3Eg8CCWjsNkszP60hJzu/IvBZJaCMep4iVYCFXV4eV2iSpkbnkqQ9qhFNBBs8XYxm3bpG2NOXNaiYUV6IHZY2QX7ZF9CSPDPmkPFUqjDeruwxCLeEu4J/ojKCDVgYPJI9qvQA9272x5kDh7Ftyg4RD3+LdxeLKpdJ9/3rVWsyeI/twUqAn8B7tleyWxxNPxLJet3khTxCH1xXpjnhaGFZYs4r6L1y0zMuC03sDMwXHdtcS+civqPA5elwr/OZpwLL1Gy65kYXjMAq/YKMs2q9knlfdyy2BvFn+HsEbMavHJ7XNZdBowBerz9oHr9fUaHBA== 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:cleverness; s=d131.5fbc6a46.k2011; bh=GMwj+/EMbT3eNwIZBrXuGbi9JZskwOSrvaeaV6womxU=; b=Voj4mi7QMSbs7/SUPMPfnqECw6QbrO4wyORPhSjCHHSrTqH4mpZiJ15MhK56scbLKXV3C+92q9xcOPW9cfrBCBA7QXq+ssLzBN+TO5jeoYi5b3fj/xLvD1p0DTBz421eVO4Qk716siqIyzBu0dQMMuMo/2eWZK8XEdomqlu0Tl3tGFzP+7EFtrdt02uC6qEFGrKvn+zbt5HiVhJ4LV1hlV5bj/mNtbyLUF0DqR3eysnjLOsgwNizcEhAqPv7hRV7uYFGNW5gRtb3oBFBDNthYhcoRgF2VgYkbVFMk6lFa0NijIzNRpLkeYGw6xXe78WCvFWG8HoFikZu39jBLIfIFQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Nov 2020 02:04:54 -0000 Received: by ary.qy (Postfix, from userid 501) id AFDC027CE5C8; Mon, 23 Nov 2020 21:04:53 -0500 (EST) Date: 23 Nov 2020 21:04:53 -0500 Message-Id: <20201124020453.AFDC027CE5C8@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 02:04:59 -0000 In article you write: >What I'm struggling to understand is what having authenticated auth-res >from a previous hop helps. this is what i found: See some of the previous messages. My usual example is a mailing list message that fails DMARC at the final recipient but passed DMARC (as recorded in AAR) when it arrived at the list. This lets the final recipient distinguish between real messages from subscribers and mail from spambots that happened to scrape both the list address and some subscribers' address and sends mail to one pretending to be from the other. (That definitely happens, I've seen it on lists I'm on.) I agree that the ARC document does not do a great job of explaining that. >It would be kind of nice to understand what gap ARC actually plugs and >why it's important if you ask me. Also: there seem to be a lot of ways >to achieve this, but this one is probably the most complicated one that >I can envision. If you want to pass the A-R results through multiple rounds of forwarding, you can't do much less. R's, John From nobody Tue Nov 24 04:20:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97E53A09DA for ; Tue, 24 Nov 2020 04:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QNABZE-QwCzS for ; Tue, 24 Nov 2020 04:19:59 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A32C3A09D3 for ; Tue, 24 Nov 2020 04:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606220394; bh=W48jF7itlL5KNQbKXEYZU1TJ78Fxz1S3ID9r4ch9VUM=; l=820; h=To:References:From:Date:In-Reply-To; b=A+e9I1E3Cc0n7Z1cZ4jcFlFuipjOjlUnn/m8GiLVqT4sSaT83XLqDzWf6t2b8D1zT nG5FwV1nm/Epbbd6LHjhmuRlVXBaZFj05PHI8ZyVSFhI8CPbTurgsrjzZ5d25ECGrQ vr7c0CmOKbvi4uVrcjWzX0KwO8YvVwsO5oPQ2cCMCxzP86O+fI03parI7lIzQ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FBCFA6A.0000614A; Tue, 24 Nov 2020 13:19:54 +0100 To: dmarc@ietf.org References: <20201123213846.EB14127C8160@ary.qy> From: Alessandro Vesely Message-ID: Date: Tue, 24 Nov 2020 13:19:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201123213846.EB14127C8160@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 12:20:01 -0000 On Mon 23/Nov/2020 22:38:46 +0100 John Levine wrote: > In article <9f388e33-c15d-9fcc-e9d3-d7719288fb98@gmail.com> you write: >>On 11/23/2020 1:04 PM, Jesse Thompson wrote: >>> I meant to suggest that the requirement for a tree walk would be that the Organizational Domain would need to have that in its policy. >> It seems like a decent compromise for the people worried about unnecessary DNS lookup overhead. > > If I'm going to go to the effort to download and decode a PSL and find the OD, I'll just use the OD. > > One of the points of the tree walk is to get rid of the PSL processing. The PSL processing is a local lookup on an in-memory suffix tree. How is it a progress to replace it with a tree walk? A PSL search is lightning faster than even a single DNS lookup, isn't it? Best Ale -- From nobody Tue Nov 24 04:53:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5853A0BF4 for ; Tue, 24 Nov 2020 04:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 zv44WQumtQkm for ; Tue, 24 Nov 2020 04:53:18 -0800 (PST) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 D2F893A0BB0 for ; Tue, 24 Nov 2020 04:53:18 -0800 (PST) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AOCjORo006141 for ; Tue, 24 Nov 2020 07:53:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=x1xY9BSXaEuybIoj/1YP1B0+Xded9Ob9RyJD41WodhQ=; b=EJPl+A6PoBtLuFzAf/DG8ya/R//oxu/svB0NnI/mOr2awSpr4wy7J06j14aa7BV4/T/3 0AO1BXf+qvi1h2E2a/503kCuaMiLTi4nAz47LxtA0AmY2MJumgClk6lTWbr1NsEkqyWk GtFZoZGvwi2G2iiDcabpq8R+0moBFThXTPfQxANtH//Wr5EemRBF8aN8ElULfL/WW2iB wIVh39Zg8bLH3y3LmoWMjdsIrYqI4/c+yMkGfncbnLe30nZxw98B2bW2v/LKl5Mi2eSL wUnMUGYuEOYbQmLTkAIerSU8JQ6rz+Ymv6N5ucTRlm4FMCDXLR351OqHY4/WmXMk7rCW fw== Received: from copdcexc37.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 34xy3q8qmh-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 24 Nov 2020 07:53:18 -0500 Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXC37.cable.comcast.com (147.191.125.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 24 Nov 2020 05:52:58 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Tue, 24 Nov 2020 05:52:57 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Nov 2020 07:52:44 -0500 Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB3313.namprd11.prod.outlook.com (2603:10b6:208:60::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.24; Tue, 24 Nov 2020 12:52:43 +0000 Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::d4a7:d9e:d031:c24c%6]) with mapi id 15.20.3589.022; Tue, 24 Nov 2020 12:52:43 +0000 From: "Brotman, Alex" To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd Thread-Index: AQHWwHaVhBEGBcHryUmeC3DSrkQxLanTqm8AgAILEoCAABNcAIAAbwWAgAEHt2A= Date: Tue, 24 Nov 2020 12:52:43 +0000 Message-ID: References: <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> <20201123210543.694B127C778E@ary.qy> In-Reply-To: <20201123210543.694B127C778E@ary.qy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com; x-originating-ip: [2601:43:101:380:f556:d089:d888:4427] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bb24839b-6b7c-4214-0a7d-08d89077d5a1 x-ms-traffictypediagnostic: BL0PR11MB3313: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Th7D2AFIj5+5AOUu/xCpymL+wOmLFKBGug5TJHQQzdefIX/hVWmXt7sJyBeaxZBpGJydHalLySv1kdyd+bPKtoKMsmHtZ4lubyBjgz2nUJxd3lee6JOd+4aRbduQs16Dp1SG9S9EqShALLkPRjThxjRrXGLsnwnIGbvIz+TDUA6D+oibrAA4NeJ78CXdB+p0wkekztVyZEketnm5uFg8UazdO48CAKQiNw3SmdFPVbFq/Fldh/HN/oBE8LVHt9Zm0dAAkbSSLlJV0r68UVdT0jAsoaVqqrhrFl/8OB5LtH1eU5J6TbQ3nKnaS8tvuqSeOq+JPx3r3ZOBRUaJJeZo0T2TMoyJPZSe1MVhlmn8JONG1cIue0qqoecQH7qt+7y/QoLKQkxzs7WVeysiAcmDC6qI5FdB4YA43C/Af/kmG+hjiRwk2taccNTfLGnsn65GTzmjc7TslLPiyxLrWKTpOA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(2906002)(9686003)(86362001)(7696005)(55016002)(33656002)(8936002)(53546011)(316002)(6506007)(478600001)(186003)(6916009)(5660300002)(52536014)(966005)(66446008)(76116006)(66946007)(66556008)(64756008)(83380400001)(66476007)(71200400001)(8676002)(46394003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CdyytesNAi365fiKnqmvdQjnuh9YkJByUGvg0SsbiWXuc/wSq68jj1vQ5BVvJHhwMhmXgfQJgB1yrRMahufCIddU1WeADXkogybbo2OMHfEqLsRcQY3piDosxmRhtK9Fu02U/jfgzZqmnK6x3xXDNXx4I8RXsawiQtA2Trum086nS7K+RNEjoKtEX/qR6VZX3e1L8kaI1+o086fPNe55brcxFRiHTyoEsE4SXGTXA1/Y2mGhbwElVptmMYziJ6XrYmBM0x0Jure5362h04KDzXt+roiViHAsET7VqtHTO788IWFx6m9HMBKQSwKDVHI8slLmJCUp9Tk4PlfSpRoh1+jIza1+mPvLOqNSrPQVMyeL0C3GFvk575IeLMy9mdFOrjSdfZJXu9IEuSowIjrK4zx5uQKLq5cvhxzn7ePFZqlSG9lBlQ0O4uCxstMYaSW+1KnmXaerByOKKaB9et3vcsBsf9XE8glHdnv08MxMIMD/bGfhJoqrR/uQB/mcvo5K07BjGr0pJ2c5eR4u/LvYphyMJbgGkrjdYvhL6oi8UdqF5jbDjkxD20Cc9LalFvmrjYJRYGNffWf7svxQx+3woVKDnKqdLP/k7Ctz1w1QS/CQwOVcntxGGLQNd+VTi88T5lq2QWSz9mATSCHDbnjDhHVNbxyHQp2SxDd1x01gsJsOqfSh65oS5xIRJGETdOte8MIYPCYxW0IZ/m8WtGhomMWbfpStMWOeVZ+zSJjo/gdSKl7CKBR8SNodUM6y5B9fM5f/f9YaqI9dM7hkVSJvBWzG9u+a6mTp+2t9IzltRbOATH1+SKrkg/hzQBlE+P3Obwrqk4L15h6YkAQ2BhRLU7jQAapfKpY4Sk1W2tpYpM61zNPa0K0YG1EdreYEKWaD+V95WfI0P5u3Lq+x+EIhpW2cyX7qSmNE6V5R/8q7hTaJ+mkwxJ7/ZheSD2POtJDPjWCaltH4ZpTvtE0qSud4wg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BoIt7I0x0t2gXjisCBbXsFWE1eGhmRhTLsWMFpAFyW7XxrMWA4L8dECHrzpiW8LHDXS0NIFX5R4uwRKil3KBFyKYdVaW97kFq75Pwx0wJbJPzoa/URTO/6vMECSTpIFsH7ZBe4SX/niv/KJA4NQhqoty2Z8CYeb1BdU9h3mu+IeeVPKz/iCJ8X8KOHkSpKAP1ftTc4nNa6bmk/jkLqNbbrqzWHiZdwmoef/HZ8Fjnag39BookTpkAcxOkVx349Pho5hSz2KiUcWz3wCCPOi9+0rkdFVas5YADGis0QZuhbnv3/hmiG/MGfDAjdGnZDXxqQD5QjAQjG7HKnQQOaU+sw== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+lTqoxxLvnfcCAP5GO0voPZL827XFYX+wTW8h5Vm/+E=; b=PMSUc+VfFmBdtCPTasug8QEqzAnFwyQUc8tUCLGZLtvDav9MqQ5xr8J6TyAnOuZ6txgWSW8TdFDl36/qvaAxP/bmWaP820Zwp5Hg9iJnruxMlS71WgWOWynicobaziv5QX+czcLicOYuvLitMnUXxcnwHrYIlq8lavYs3MPqMlTTUoabDdjiwGuTPUKr0uKjKiJGXn6dAPZpW3bpE6WsIGpTVN3kLJyS+Q+zayjy91wNsmoStHc65LCnfTf8N0aoN75VUN9ejbyZXw2CXWnysRQa0hbmhqlXLZtRDQYGgWOMR3/qT1txo9wOzodvQI3dMxpwvbzYNOUqz0IMLuwydw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: bb24839b-6b7c-4214-0a7d-08d89077d5a1 x-ms-exchange-crosstenant-originalarrivaltime: 24 Nov 2020 12:52:43.1580 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: th0F6lbjZ9o28ZoYQnPf7su1Eq/S28aUpjPdBbaG0oRyGfM+8ygrcvgBJvgMRXE7Yt3UAx1ftxLjQYhqxPwvvxcIA7p+RmjHgjOjlQ1dhsY= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3313 x-originatororg: comcast.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward AAETWT X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-24_04:2020-11-24, 2020-11-24 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 12:53:25 -0000 I was sort of curious yesterday and checked as well. Most were four or les= s. I had a number that were five or six. A couple dozen were at eight. I= had one spam message that had 13 parts. It included both "_mta-sts" and "= mta-sts" in there, as well as "mail" nine times. The last two parts were t= he org domain. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc On Behalf Of John Levine > Sent: Monday, November 23, 2020 4:06 PM > To: dmarc@ietf.org > Cc: eric.b.chudow.civ@mail.mil > Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draf= t- > ietf-dmarc-psd > > In article > <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.dis > a.mil> you write: > >-=3D-=3D-=3D-=3D-=3D- > > > >Even for .mil, the vast majority of email domains are fairly short with > >four or fewer labels. Most of the other ones tend to be individual serve= rs that > send automatic performance emails, and I think should be considered more = of > an edge case and less of our concern. > > I scraped my logs for the past few months and that's what I found. > Nearly everything was four labels or less. Spot checking the few five-lab= el > names, I found that most of the mail was all from MAILER-DAEMON@ mailhost-name> and it appeared to be spam blowback. There was a trickle = of > what looked like real mail from stumail.zcs.k12.in.us and feedback.retail= .voice- > your-views.hsbc.com, > > I found nothing at all with six labels or longer. > > So if we made the tree walk limit six or seven I think we'd be unlikely t= o lose any > mail that anyone would miss. > > R's, > John > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__= ;! > !CQl3mcHX2A!TIKw8O7ptxZvJLkZ0GxAxe4haD43V7NWTdLfVAZUiJUaCqFVIV1co > wazKVYiV8c2YXTskHmvzw$ From nobody Tue Nov 24 07:00:33 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55513A10A4 for ; Tue, 24 Nov 2020 07:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.421 X-Spam-Level: * X-Spam-Status: No, score=1.421 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_12=1.629, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OByKUU1fvS_n for ; Tue, 24 Nov 2020 07:00:30 -0800 (PST) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 A3CF53A109F for ; Tue, 24 Nov 2020 07:00:30 -0800 (PST) Received: from pps.filterd (m0167071.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AOEgZ7X024791 for ; Tue, 24 Nov 2020 10:00:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : content-type; s=pps01; bh=ZJrnhvvYDWS6vx0idnPgr5Jk9JJFyELpTvYuA3LuPpI=; b=LccpUTKTNBuzwmm2MdQGuwAAzfiVUrnjL3JoYIBZekNBtpmoF/nJMO4Xjw2UZuFLo8sM NZOrmfX3Z3JrF1+WFR46lQYpD0SOOaqQeKCCfzwUsymBGKxVRqmNGLvyZ/I/1hmwWOBP 3vL5xPRmGFOxHwzfWXWD0IwLoffVJK8PXTrA0lftWpcRya3hXPwbmG/yiXKCeW192qV0 bkkgOUkQ9HBYWmW61L/Ah/C9o2nHZa5trb9zQ7vs/ku9ZC6bu/koEQVXaIqGWMWEkRSX mh++3Za4h585l8wB5NQVI+Vjxd9ci3ffH+Gh5EAEmfy1WtdkSMNWl+MibsNpnzaAir9b PQ== Received: from sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0a-00364e01.pphosted.com with ESMTP id 34y0qu9av3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 24 Nov 2020 10:00:30 -0500 Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0AOF0SRH016315 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 24 Nov 2020 10:00:28 -0500 Received: by mail-io1-f70.google.com with SMTP id b4so15799311ioa.4 for ; Tue, 24 Nov 2020 07:00:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZJrnhvvYDWS6vx0idnPgr5Jk9JJFyELpTvYuA3LuPpI=; b=WDhy4jPxbtcLUXiJbvz7hPvqOZYf9O9h0Mpxp4aZV59tWt1rCzk6OAowZEuTrgHAbM tCmRL2cC4Eyj16iVCPiVwBg1kQvX/G+ImjrmkgrPB2r6sLQCYcOIZakF9H8DXkPv6fa5 JUvSLEuFvZiK9wErFgoOtQPbHuOfRYod+/F7KZYF0zYt/lYbB9YVBA/uGdhnajbLEBpo L9F/Z5iBdTCjQORSD7sDSv7JIkkrjLLwft8ENR+m8onlNJbOaj+xHLNRPj8lTYwrVL+N uO5T/AkBBsf6DP+Dr/mYYybA2PPuF3IT4dgUmKw3d3UQTT+bUDJ4CyxFJcTw5LbGgJet FnWQ== X-Gm-Message-State: AOAM531BmvnFmtvm++UEpHvJJRC80ZpN/32xNvrvqkbtF8YbOarm0CEM vhnjPsoxHYRFTJAaSrjp9BiIHqEDUnEeWNe96yLoPswVvU8NESooOUHdsbN1V2uOXbVGh/G0xcv 6HlVQ4oK9VPp+4dHmYl+S7iFnVO5KNg== X-Received: by 2002:a92:d03:: with SMTP id 3mr4754736iln.197.1606230027855; Tue, 24 Nov 2020 07:00:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJz8C234tLryo8GbPsOjzVfFku1+l/fVkCN5yQC500DunDGF0/WVqp9ACn5AigG+S1nBej3IMozI3PNbLlqC+/8= X-Received: by 2002:a92:d03:: with SMTP id 3mr4754704iln.197.1606230027483; Tue, 24 Nov 2020 07:00:27 -0800 (PST) MIME-Version: 1.0 References: <20201123213846.EB14127C8160@ary.qy> In-Reply-To: From: Joseph Brennan Date: Tue, 24 Nov 2020 10:00:16 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000003758dc05b4db9218" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-24_04:2020-11-24, 2020-11-24 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 malwarescore=0 priorityscore=1501 spamscore=0 mlxscore=0 phishscore=0 clxscore=1015 lowpriorityscore=10 suspectscore=2 mlxlogscore=661 impostorscore=10 bulkscore=10 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011240091 Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:00:32 -0000 --0000000000003758dc05b4db9218 Content-Type: text/plain; charset="UTF-8" I will ask why the recipient system should look up anything but the dmarc record for the specific domain in the Header From. In some cases looking up related domains is useful, and in some cases it can lead to disruption. We don't look up SPF records for related domains, because they are deliberately different in many cases, e.g. one domain for mail from end users, another for mail sent by a vendor, yet another for another vendor. Why is dmarc different? -- Joseph Brennan Lead, Email and Systems Applications Columbia University Information Technology --0000000000003758dc05b4db9218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I will=C2=A0ask why the recipien= t system should look up anything but the dmarc record for the specific doma= in in the Header From.=C2=A0

In some cases looking= =C2=A0up related domains is useful, and in some cases it can lead to disrup= tion. We don't look up SPF records for related domains, because=C2=A0th= ey are deliberately different in many cases, e.g. one domain for mail from = end users, another=C2=A0for mail sent by a vendor, yet another=C2=A0for ano= ther=C2=A0vendor. Why is dmarc different?


--
=
Jose= ph Brennan
Lead, Email and Systems Applications
Columbia Unive= rsity Information Technology


--0000000000003758dc05b4db9218-- From nobody Tue Nov 24 07:15:48 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5E03A10DF for ; Tue, 24 Nov 2020 07:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGiSeL68RTV7 for ; Tue, 24 Nov 2020 07:15:45 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 9CF113A10DC for ; Tue, 24 Nov 2020 07:15:45 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id y7so18759164pfq.11 for ; Tue, 24 Nov 2020 07:15:45 -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-transfer-encoding:content-language; bh=seFLp5JxenbBzENuGE6kDYNZEy+A0125LxXmWA33g/M=; b=fDGqiMW2SeizdN+7U83E4uOPb2kvcQsc10cddwPKhBo5iBtale/N2vGGIXQdpGo8YD 6fBrvz1BEj1cUlwvYqRqALnFJx/PGknjvGyb9j3Uxi0J4HTPjNucK7c42w+3AUn/d4YE 7aYBPLq61m7JxrZEuY2c7D/D9qOj+Ec6MhbkNqgOeVu7YQrkOgKXstAN9TKWQBtrgIrS vBeeWwhHmJFRxq9ynFdh285S8lOYfCY4b7AM0xnJuPI/XtSmufQWVHGEqySYDPFapezj 2mZMxFuJWoEG5PFai7Nw7I83EZr5GSCbdKuFvXIFf7c9EDwE5OSqeB/NyqPV1BHVAsED fC1Q== 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-transfer-encoding :content-language; bh=seFLp5JxenbBzENuGE6kDYNZEy+A0125LxXmWA33g/M=; b=e+jr4jVBm/VhQYl+L9kf3/LXRiw8RpuH+FvFharCOY5rRv3acuSnO+lzi85L3YZAhz mAP2iJDXBn6xDYWHxk6B0aH5Rm631gJYLAaRqaVwuHAQ6ZN/QgwxxqhMh8xvB1a2JQeI rqeiScjJzzY2UrlpFbPit0Ybsx8Bt9oc69TW5FNp63J5FKQXouFFPSIR28WTHS+xr9eT fcOt8/W+x4oGDcdtDETJeRYZ068KI3Zwd6uwiLnKaYde2Iha/FanGkmvgbmAQoLNokaU M4ugpw9+g8msNsOnkTCHCsXXV+PpRXAioYIziEJtLREYLxMoo20EMAuqkO41e0pKJ0rU Qazg== X-Gm-Message-State: AOAM531FuF4b3eONEW1SnH5qgAAby1qv/RjnPd94LnGhxIdehkBWAuSV WO5BaFdiY7u6OgyvwMF5mg23mlKtFHI= X-Google-Smtp-Source: ABdhPJwRqnTZ7mWJPrkW4kaTKJ2apV9iaoS/P3n2x2vQ3T3vxFgR1eDFoBL88ou/9jSfgZ5R/wL5Fg== X-Received: by 2002:a17:90b:8d8:: with SMTP id ds24mr5312088pjb.5.1606230944671; Tue, 24 Nov 2020 07:15:44 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 23sm13755972pgs.19.2020.11.24.07.15.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 07:15:44 -0800 (PST) To: IETF DMARC WG References: <20201123213846.EB14127C8160@ary.qy> From: Dave Crocker Message-ID: <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> Date: Tue, 24 Nov 2020 07:15:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:15:47 -0000 On 11/24/2020 7:00 AM, Joseph Brennan wrote: > I will ask why the recipient system should look up anything but the > dmarc record for the specific domain in the Header From. Hmmm.  Unless I've missed it, the DMARC spec does not explain the reason for needing the Organizational Domain. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Tue Nov 24 07:29:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA33A0D8C for ; Tue, 24 Nov 2020 07:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UNmxzACSmnc for ; Tue, 24 Nov 2020 07:28:57 -0800 (PST) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 BDC2E3A0D86 for ; Tue, 24 Nov 2020 07:28:57 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id g19so10788619qvy.2 for ; Tue, 24 Nov 2020 07:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0+T03RTK7Ilo2WH0LmrZLfF50dTQ9UtnoawOZkoOW/I=; b=MMJs+k4FN/GiDJZLUip6f0PF7lOKv4iIV+MwrT86NNhYXsAVv59QHIaDw04+t+jgZW mKoXsfzKsUbpPCarzl9pdBFTJeFRTQAfWcyz0LJLSEnoK1J+tYxEavh8dsfeiL2u/fkT cBSp2F3Hoc7GmrX1Kv3da2zmiIB0e+CKpwHmt0rsmaTXSsJEa3W4FDOLf495enUbQjFE sUTxHlzYhpZwJiimbdcmGZSUsKbf0zmf1Q43/88C4uc3cTZaR2B8Wm+SHc155anoaSML mvgZunxpfQ8k5oiVhISeASsdK/9Y0aVt7NFR/wMDBB2KnVCOvLMlIT6zCmISO3CiUZ6i QaaQ== 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=0+T03RTK7Ilo2WH0LmrZLfF50dTQ9UtnoawOZkoOW/I=; b=hG9/RFJdkJmgZb07SXAz2d++0tN2BgKDc6Go4xCeyh/lImfJXy5wtzavJfxVEXHF+9 d3xaKuZf0Zv3dBTKM/WKvTjdAJNPlyzfTmfnMP/NnlWP9GRdlfIKoCAEo+hLqbDUp4EG wkpVeOYX9VE+HrKot1oxlmmqrTGBGmYOf2WiOODANejTV7xqxGS13uidj/99wYGYn3dc mIetHGgghtPC6cw48oon3+v8rwHlTHkO1W0mgnpsqZkQThDfj/1YjU9Na8FUPEEUTFSh gXRvU/FXVCVmxbp++2L91qaZRGzmfaP1lwMJj+0rbt4Yj0ACKg/nEMPdakGMaDT1ny+o gYkg== X-Gm-Message-State: AOAM530g3ot0SoZzz7znQPhY6e3OCChdlsXI6W1X6oGf+iD/2nHPoTqe r2sb3y70OjVykJt4SGwUVzr+ENSCymMdahODTs9oqQBxosLGzg== X-Google-Smtp-Source: ABdhPJwQS90JAmZebvMJLbMBi9EJsFH10R5zbl58r9F0RLfjZHn383mN4FHTqDzwBZDbWHfswf2l/MGqDwSoAHKkKMs= X-Received: by 2002:a0c:db11:: with SMTP id d17mr5239354qvk.39.1606231736452; Tue, 24 Nov 2020 07:28:56 -0800 (PST) MIME-Version: 1.0 References: <20201123213846.EB14127C8160@ary.qy> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> In-Reply-To: <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> From: Todd Herr Date: Tue, 24 Nov 2020 10:28:40 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000014268e05b4dbf854" Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:29:00 -0000 --00000000000014268e05b4dbf854 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 10:15 AM Dave Crocker wrote: > On 11/24/2020 7:00 AM, Joseph Brennan wrote: > > I will ask why the recipient system should look up anything but the > > dmarc record for the specific domain in the Header From. > > > Hmmm. Unless I've missed it, the DMARC spec does not explain the reason > for needing the Organizational Domain. > > There are two reasons (at least) for needing the Organizational Domain, and they are discussed in RFC 7489: 1. DMARC also allows for the explicit or implicit expression of policy for sub-domains at the Organizational Domain level. This matters for those times when _dmarc.RFC5322.From.domain is non-existent and RFC5322.From.domain is a sub-domain of the Organizational Domain. 2. The default mode for authenticated identifier alignment, relaxed, requires only that the Organizational Domains for both identifiers are the same, and so the Organizational Domain must be known in order for relaxed alignment to be ascertained. What is perhaps missing from RFC 7489 is the reason that the authors chose to make these two items part of the specification. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000014268e05b4dbf854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2020 at 10:15 AM Dave Cro= cker <dcrocker@gmail.com> w= rote:
On 11/24/2020 7:00 AM, Joseph Brennan wrote:
> I will=C2=A0ask why the recipient system should look up anything but t= he
> dmarc record for the specific domain in the Header From.


Hmmm.=C2=A0 Unless I've missed it, the DMARC spec does not explain the = reason
for needing the Organizational Domain.


<= div>There are two reasons (at least) for needing the Organizational Domain,= and they are discussed in RFC 7489:
  1. DMARC als= o allows for the explicit or implicit expression of policy for sub-domains = at the Organizational Domain level. This matters for those times when _dmar= c.RFC5322.From.domain is non-existent and RFC5322.From.domain is a sub-doma= in of the Organizational Domain.
  2. The default mode for authenticated= identifier alignment, relaxed, requires only that the Organizational Domai= ns for both identifiers are the same, and so the Organizational Domain must= be known in order for relaxed alignment=C2=A0to be ascertained.
<= /div>
What is perhaps missing from RFC 7489 is the reason that the auth= ors chose to make these two items part of the specification.=C2=A0

--
<= p dir=3D"ltr" style=3D"line-height:1.656;margin-top:0pt;margin-bottom:0pt">=

Todd Herr | Sr. Technical Program Manager
p: 703.220.415= 3


This email and all data transmitted with it con= tains confidential and/or proprietary information intended solely for the u= se of individual(s) authorized to receive it. If you are not an intended an= d authorized recipient you are hereby notified of any use, disclosure, copy= ing or distribution of the information included in this transmission is pro= hibited and may be unlawful. Please immediately notify the sender by replyi= ng to this email and then delete it from your system.

--00000000000014268e05b4dbf854-- From nobody Tue Nov 24 07:36:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9323A116A for ; Tue, 24 Nov 2020 07:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRPt6WKeNJsS for ; Tue, 24 Nov 2020 07:36:44 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 776F43A0D93 for ; Tue, 24 Nov 2020 07:36:43 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id f17so9261627pge.6 for ; Tue, 24 Nov 2020 07:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=OLeFYglhiv88SgM6fL+7yXnLbd0shima2eWYO8QbDNw=; b=aQTvSz8gIcnZ8rq40yUjc0t5TqnjZNjeH+jT97tFm4/xy1equDQGk1ORUR7dkD9Spi ESTgPunvboV18SNwfT+CEbpUs5y1Zo8vCOgxunRMmn3HgIpH3ZITzRjb4gTKUPonYX7t YKqU3MszSkdZZsu+SF3sCT1+JtTEpQPYuN2rnStpDQ6TMaH/c+oYVIWaZIUbRAAc2XJv 9sjfU5WtZclBYOwkR9F5H6GyY5g3bxJAMM2o7qRkTiULGydS3mlejw/GB0PMGIL/x5Yo Ap1C1ymdR17yb+cZO+bP0ct3mPebw8hoR0mqlSBs8Vt+J9CYbzp5BYT0+n11icNsh5My nm2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=OLeFYglhiv88SgM6fL+7yXnLbd0shima2eWYO8QbDNw=; b=bklBJHiJcRimyFh6UjIn+rs2X6yFoLmzqkxnYMpl0NqDJXC6LY7Idm5pg9NsfdWXAE w+Q6VZYVss65DjYh1mu6Um/mJS4lcajgqgQ/vBDcs6L8E2sFGpSzQPMxxJrhvMLmzPw2 2dmh5IAW2xn2xOkXct6SffmL9/zT+l7im73n6d6R6J9sf8ZCiyPEf+c1dkjvU9EHyIlG SVIAsl5L0SRxzETSdZOknIRw9ioVsYnfSWvJZEgSjM6k4NXCMWPQPj+K7JgiQ5635Vud +vNBoNnRL2a+EoXeRnRxHBQ/5xM5VfoZ142eUfA2b1zKHbla0TXKNrPDkATmthRXd+bz uaoQ== X-Gm-Message-State: AOAM531QP0l8ig+jNEfgnacQS2L64AHDi3MkQFYha3RR85AfUza4Sa9+ h+BqlSebVzm/ObZ1XGIRI6kULR2CcyM= X-Google-Smtp-Source: ABdhPJxwm8tSyzzodFt7So4POlrrqGVjfR1wyf3o3us/0lmXbDaznctIC9RG49vB1hfLhXJ7CyWq8A== X-Received: by 2002:a17:90b:518:: with SMTP id r24mr5388320pjz.16.1606232202859; Tue, 24 Nov 2020 07:36:42 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id e128sm15091858pfe.154.2020.11.24.07.36.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 07:36:42 -0800 (PST) To: Todd Herr , IETF DMARC WG References: <20201123213846.EB14127C8160@ary.qy> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> From: Dave Crocker Message-ID: Date: Tue, 24 Nov 2020 07:36:40 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E4170C9B242709A8958C89C" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:36:53 -0000 This is a multi-part message in MIME format. --------------1E4170C9B242709A8958C89C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Just to be clear, I'm not challenging the need.  Rather I'm just looking for text that explains the need.  And I'm not finding it... On 11/24/2020 7:28 AM, Todd Herr wrote: > There are two reasons (at least) for needing the Organizational > Domain, and they are discussed in RFC 7489: > > 1. DMARC also allows for the explicit or implicit expression of > policy for sub-domains at the Organizational Domain level. This > matters for those times when _dmarc.RFC5322.From.domain is > non-existent and RFC5322.From.domain is a sub-domain of the > Organizational Domain. > 2. The default mode for authenticated identifier alignment, relaxed, > requires only that the Organizational Domains for both identifiers > are the same, and so the Organizational Domain must be known in > order for relaxed alignment to be ascertained. > Except that I do not find either of these points provided in the document. > What is perhaps missing from RFC 7489 is the reason that the authors > chose to make these two items part of the specification. That would, of course, also be nice to include. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------1E4170C9B242709A8958C89C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Just to be clear, I'm not challenging the need.  Rather I'm just looking for text that explains the need.  And I'm not finding it...

On 11/24/2020 7:28 AM, Todd Herr wrote:
There are two reasons (at least) for needing the Organizational Domain, and they are discussed in RFC 7489:
  1. DMARC also allows for the explicit or implicit expression of policy for sub-domains at the Organizational Domain level. This matters for those times when _dmarc.RFC5322.From.domain is non-existent and RFC5322.From.domain is a sub-domain of the Organizational Domain.
  2. The default mode for authenticated identifier alignment, relaxed, requires only that the Organizational Domains for both identifiers are the same, and so the Organizational Domain must be known in order for relaxed alignment to be ascertained.

Except that I do not find either of these points provided in the document.


What is perhaps missing from RFC 7489 is the reason that the authors chose to make these two items part of the specification. 

That would, of course, also be nice to include.


d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------1E4170C9B242709A8958C89C-- From nobody Tue Nov 24 07:52:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1E3A11D3 for ; Tue, 24 Nov 2020 07:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZLo8RJ6ReqS for ; Tue, 24 Nov 2020 07:52:47 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 AC9773A11AA for ; Tue, 24 Nov 2020 07:52:47 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id q7so10784126qvt.12 for ; Tue, 24 Nov 2020 07:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+egr6+GzifR3d+2b7EaZwIfmk+omQ/GlZzsaixKHNXk=; b=DtxFVMuY9N5hk2YVY7yWR9HK0/csGcrGol75huqLUxFWTSnQe2x74rzW64b6kk3Fl/ dG2mGbwqzA0zCidMvenBPXl2otiJQpXHhHJwAYto4Q6K49UVPTlccH9BbhSKF1DuwNYH ifFCEdZcrJb9yHShLROBFGoXUa2xzcs/YGe4iCx1lrH5Wg0+taQ/RZtZaiPVl0PB7Pzk MfNKjS0uMe+9xr4nFjAQ+UL5DAE8hnQIK5Q0Bj7liYBJSmBzbDAYMioDqO58uYMeMVmq NL+GEaWXrlOoekbQPm+0ZO9//go+tn9eTVxXzIpZTAmWZ4exISn/nfn/LdKxMbmfZoVP RRww== 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=+egr6+GzifR3d+2b7EaZwIfmk+omQ/GlZzsaixKHNXk=; b=tubNfrTsMMVWR/U52rw7VkcEkT2Bwgb3gg8z9sSp24iRuud+NY9WSTfr0AtbF+v/AW 2JkcThxFdw/D0dKPI19Cj5s6/6UZLPODwwbu6Rn397LRMwiCYlD6Kuc6963sH9t/okqT S/6aOV2JfTYzqDMHSFw36ZNJ+KFraYGNHWO+4cUo1/omQDRF8Sdxu6rTQgzJa6pLZc+C wLJ8SIWmgAVmWxckxXt20cXgIe/+AjOhlRjNTDSq8AdXBUnjSKi4dVfLy/ujgYyf5UGM XR/LQneb4/3VOryF0zGsuTaIPuWx97Ch8s2wSB1YenfJpCY3PnncEZ1XecL4lS3egKap VRog== X-Gm-Message-State: AOAM53108wKvWUc4RY0I2/+WueRN7q9ZseKAkruTLRVecWP8BmvpQWQo BTs7TM6QEAtWmRwLPGF7Q5YS9y8chZTdGDaupEeuL7cnY6iy5A== X-Google-Smtp-Source: ABdhPJxZYcCLitO5E9+TRLYbwwoh2UuJU8mTSim+s9NmUiCMnP/MUkl8awjwShyt7+pbXtBJkGg2cw0FwAyNJW5zWX8= X-Received: by 2002:a0c:f809:: with SMTP id r9mr5571253qvn.17.1606233166437; Tue, 24 Nov 2020 07:52:46 -0800 (PST) MIME-Version: 1.0 References: <20201123213846.EB14127C8160@ary.qy> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> In-Reply-To: From: Todd Herr Date: Tue, 24 Nov 2020 10:52:30 -0500 Message-ID: To: IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004ff1c505b4dc4ddf" Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:52:55 -0000 --0000000000004ff1c505b4dc4ddf Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker wrote: > Just to be clear, I'm not challenging the need. Rather I'm just looking > for text that explains the need. And I'm not finding it... > > On 11/24/2020 7:28 AM, Todd Herr wrote: > > There are two reasons (at least) for needing the Organizational Domain, > and they are discussed in RFC 7489: > > 1. DMARC also allows for the explicit or implicit expression of policy > for sub-domains at the Organizational Domain level. This matters for those > times when _dmarc.RFC5322.From.domain is non-existent and > RFC5322.From.domain is a sub-domain of the Organizational Domain. > 2. The default mode for authenticated identifier alignment, relaxed, > requires only that the Organizational Domains for both identifiers are the > same, and so the Organizational Domain must be known in order for relaxed > alignment to be ascertained. > > Except that I do not find either of these points provided in the document. > For point 1, this is from Section 6.6.3, Policy Discovery: 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the one found in the RFC5322 .From domain in the message. A possibly empty set of records is returned. 2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322 .From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned. For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers: In relaxed mode, the Organizational Domains of both the [DKIM ]- authenticated signing domain (taken from the value of the "d=" tag in the signature) and that of the RFC5322 .From domain must be equal if the identifiers are to be considered aligned. In strict mode, only an exact match between both of the Fully Qualified Domain Names (FQDNs) is considered to produce Identifier Alignment. Also for point 2, this is from Section 3.1.2, SPF-Authenticated Identifiers: In relaxed mode, the [SPF ]-authenticated domain and RFC5322 .From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.herr@valimail.com *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000004ff1c505b4dc4ddf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2020 at 10:37 AM Dave Cro= cker <dcrocker@gmail.com> w= rote:
=20 =20 =20
Just to be clear, I'm not challenging the need.=C2=A0 Rather I'm just looking for text that explains th= e need.=C2=A0 And I'm not finding it...

On 11/24/2020 7:28 AM, Todd Herr wrote:
There are two reasons (at least) for needing the Organizational Domain, and they are discussed in RFC 7489:
  1. DMARC also allows for the explicit or implicit expression of policy for sub-domains at the Organizational Domain level. This matters for those times when _dmarc.RFC5322.From.domain is non-existent and RFC5322.From.domain is a sub-domain of the Organizational Domain.
  2. The default mode for authenticated identifier alignment, relaxed, requires only that the Organizational Domains for both identifiers are the same, and so the Organizational Domain must be known in order for relaxed alignment=C2=A0to be ascertained.

Except that I do not find either of these points provided in the document.

For point 1, this is from Sectio= n 6.6.3, Policy Discovery:

   1.  Mail Receivers MUST query the DNS for a=
 DMARC TXT record at the
       DNS domain matching the one found in the RFC5322.From domain in
       the message.  A possibly empty set of records is returned.

   2.  Records that do not start with a "v=3D" tag that identifie=
s the
       current version of DMARC are discarded.

   3.  If the set is now empty, the Mail Receiver MUST query the DNS for
       a DMARC TXT record at the DNS domain matching the Organizational
       Domain in place of the RFC5322.From domain in the message (if
       different).  This record can contain policy to be asserted for
       subdomains of the Organizational Domain.  A possibly empty set of
       records is returned.


For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers:= 

   In relaxed mode, the Organizational Dom=
ains of both the [DKIM=
]-
   authenticated signing domain (taken from the value of the "d=3D&quo=
t; tag in
   the signature) and that of the RFC5322.From domain must be equal if
   the identifiers are to be considered aligned.  In strict mode, only
   an exact match between both of the Fully Qualified Domain Names
   (FQDNs) is considered to produce Identifier Alignment.


<=
/pre>

Also for point 2, this is from Section 3.1.2= , SPF-Authenticated Identifiers:

   In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce Identifier
   Alignment.



--

Todd Herr | Sr. Technical Program Manager
e: todd.herr@valimail.com
p: 703.220.4153


This email and all data transmitted with it contains confidential= and/or proprietary information intended solely for the use of individual(s= ) authorized to receive it. If you are not an intended and authorized recip= ient you are hereby notified of any use, disclosure, copying or distributio= n of the information included in this transmission is prohibited and may be= unlawful. Please immediately notify the sender by replying to this email a= nd then delete it from your system.

--0000000000004ff1c505b4dc4ddf-- From nobody Tue Nov 24 07:56:15 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F703A11A4 for ; Tue, 24 Nov 2020 07:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qH_UR8HKk5z for ; Tue, 24 Nov 2020 07:56:13 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 64DBC3A11A5 for ; Tue, 24 Nov 2020 07:56:13 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id bj5so10079877plb.4 for ; Tue, 24 Nov 2020 07:56:13 -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-transfer-encoding:content-language; bh=Zl/rdY4BN4hO0PuwXdrAFwpcTVP6m7Mk4wAvXj7l/tQ=; b=GIo7nPYM3fNQmjvuebb4m5385ka1rnvv+kfvjNEIUsjQcZcicRMDfiD5qKFjyYSsLF tv9sObOG+Fje3WJNbX/rGSG7OyPuIBBIDAqjaCwd8dBZJsQKrYtCu1MFnx+x3D6+O0dt GYzWl+dRvO0sNy/9dfgZfMm6aMOnSjVdw/EtYHf61Ynk+AtU2/h+qTr5+ZTF7HYCLNdb 359QemKWo2kzFRbjR++Vja9yfuU4kgpyzlxL3kocOoBMkfPEEqXly2RJMt+Meww8zWd+ lx4mDqVJc07aBlfTTsqFmv1nBSSgM5iGV1C/ZCceS8Hs7WYfbf5O6OMSIw9iQevj6q7K LQbQ== 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-transfer-encoding :content-language; bh=Zl/rdY4BN4hO0PuwXdrAFwpcTVP6m7Mk4wAvXj7l/tQ=; b=dVuXLXTmJMaXTdfflReZdzCfzQVPpiNXAb4g0/MUstuBpP1d1Vnfc/JMnMpaYUJG3E E0ml0Sx494YoLvhhbevzMDrs/0LRV0FufqCkZ7etVkC1H0w7esogrjuREk6A7ElXOFEt ygkgKr2OXByk8rByx2+QvqbGLe0nNPp0Hg6P4RijgLRjd4Ou/1wqxt7/PZctnKow/9X6 5tdTnrJjaJ0H5vi9i6DrLkyrb2j0AW4uuj9xyX/+U1T5K+068I2/N/dySZ8RiWMAMTzU aSLZFQTB+hWK7XikvWKurreWGTF14ZHXj4Y74j/TSx1pOKbU2seD0/S7q7gFMHi1HARB T5lA== X-Gm-Message-State: AOAM533Gpd4h2pGSYiYwNHQcZNkbiUOJ+zDLZoDU2rnWTCcigFLkyKYd tzl27KzedrzD2oEyTbg3q9fUfnu/Z0c= X-Google-Smtp-Source: ABdhPJyJRjAUbj/FHkfoHthjrEU8HhRWulLdwxNXAQZ2mO5C+zB/Y7aqz+86nI0JyNPE2oZQapDq8g== X-Received: by 2002:a17:902:bf0b:b029:da:274:c754 with SMTP id bi11-20020a170902bf0bb02900da0274c754mr4425845plb.43.1606233372637; Tue, 24 Nov 2020 07:56:12 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id f17sm15792353pfk.70.2020.11.24.07.56.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 07:56:12 -0800 (PST) To: Todd Herr , IETF DMARC WG References: <20201123213846.EB14127C8160@ary.qy> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> From: Dave Crocker Message-ID: <4e1239c3-7b3c-1e03-4138-082be0c49dc4@gmail.com> Date: Tue, 24 Nov 2020 07:56:10 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 15:56:14 -0000 On 11/24/2020 7:52 AM, Todd Herr wrote: > For point 1, this is from Section 6.6.3, Policy Discovery: > ... > For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers: Perhaps I am misreading these, but I see them only as 'what' and 'how', not 'why'.  The 'why' is important.  It is often noted in our discussions, but seems to be missing from the spec. d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org From nobody Tue Nov 24 08:47:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528713A11F0 for ; Tue, 24 Nov 2020 08:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xb53nPlWAPH for ; Tue, 24 Nov 2020 08:47:03 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 366203A11F1 for ; Tue, 24 Nov 2020 08:47:03 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id r14so11411803vsa.13 for ; Tue, 24 Nov 2020 08:47:03 -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=jFhnoH9gBguRHskt2wc0YfNylXZqtpM8O4hHwroA+4Y=; b=fBgsT0zujGsNBIsk8YIAyD722iaP1sc/iRpdUbJx7DeqhOh1ECP62NkEj/AdWkit+b 5IyicB+7iWYP6yvCwquviYxxAu0ZoIkBG0bgUVNx7s3f2K9qaiywrmYFF1hpFi4FLkhO xpV2SNGdWTEeAEFNfLU4mwdz8IedTiN7EVfWZ4mdPlSLp2/2ZAVGGqHNS2tJruiFAPLL W3yyU/C4BtMDKTQn66Z40tL5Lid8nTTyfjC8wVnqjza9s4ONltOzTMsDDqQu7TXlkqro wnrvbQOFLZh7xfYF18j/KNT9vlHuZCZUkLzZSMe/oOcW/Z2XPFkX4PHM7iGkp96N7tgT tdCA== 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=jFhnoH9gBguRHskt2wc0YfNylXZqtpM8O4hHwroA+4Y=; b=iol6jd9vNVohyyyDrO6NcZyLWlpkn8t4VLjX0bFjTGMV8AKBfCKOc0smgjC00STzZ7 mrqp9QH5YYsHpcKS64yOmLnNo2bnTeiRsgn+idy5KQlrFqhTr5zep1yWklxn/LLWAhyl 9lZAvg7EkumJkit2JzPbCnhfqdI2eX0Lemm9KNQfBspRwzGJpAKrZ63F4T1WzM4veHPb mgws15s6Thk7iC9kC3d47xMjbCRq31ELKc9IfVQttsnvUszwy1B+6cnejJ0qIWP1VcPO /dRBj0ggxbKXDSifqTN5/N7Ff6wr782QhYBYSKhUhN7qEOWJAgOWzdyG1Sn0BYrSP7f9 pYkA== X-Gm-Message-State: AOAM532IVj/R9+dUILE9acAbKL1DWiY0XlM4iNavRb4cBUUlLrhea10w M/HxqDA36i+P363QNG/lCb9FdhFDSlyTtEHY0oI1O/Z5 X-Google-Smtp-Source: ABdhPJz6tZpLXykcuUtY3sXUMby0I/6dE/tLVay5um3flpjzV3I+oUMs25FewG5q5fAkKPXbDD+y5w5110C+N6Esa/w= X-Received: by 2002:a67:783:: with SMTP id 125mr4599864vsh.15.1606236422036; Tue, 24 Nov 2020 08:47:02 -0800 (PST) MIME-Version: 1.0 References: <20201123213846.EB14127C8160@ary.qy> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> <4e1239c3-7b3c-1e03-4138-082be0c49dc4@gmail.com> In-Reply-To: <4e1239c3-7b3c-1e03-4138-082be0c49dc4@gmail.com> From: "Murray S. Kucherawy" Date: Tue, 24 Nov 2020 08:46:46 -0800 Message-ID: To: Dave Crocker Cc: Todd Herr , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000005c615105b4dd0f4a" Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 16:47:04 -0000 --0000000000005c615105b4dd0f4a Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 7:56 AM Dave Crocker wrote: > Perhaps I am misreading these, but I see them only as 'what' and 'how', > not 'why'. The 'why' is important. It is often noted in our > discussions, but seems to be missing from the spec. Seems like something the -bis document should tackle. -MSK --0000000000005c615105b4dd0f4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2020 at 7:56 AM Dave Croc= ker <dcrocker@gmail.com> wr= ote:
Perhaps I am misreading these, but I see them only as 'what' and &#= 39;how',
not 'why'.=C2=A0 The 'why' is important.=C2=A0 It is often = noted in our
discussions, but seems to be missing from the spec.

Seems like something the -bis document should tackle.
-MSK
--0000000000005c615105b4dd0f4a-- From nobody Tue Nov 24 08:50:38 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613673A11F3 for ; Tue, 24 Nov 2020 08:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS6ykBJNPNm6 for ; Tue, 24 Nov 2020 08:50:35 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 199363A11F1 for ; Tue, 24 Nov 2020 08:50:34 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id s123so10774695vsc.0 for ; Tue, 24 Nov 2020 08:50:34 -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=Uv9/NsakBYDus7U5hxuSWCTWC+9UdeQcjp0M/GtzVvI=; b=KaG1zSSBHwu9PnJLQ/jbGAvn4xwRJ8iEcdbxbPeH/x5QrwBMxDEo5wsJaAs55WzgBy OfGPFyaXwGO4l8N/QKOQvLlsZ7S6GFgMMHpFBXwIZMUFuql7gxaRlnVJhc7D41TOzzmK LrVVi2i6zjcTsVhASr9NL7wEgQsyEE5Q8voa+c6z7rbqmQOmOJc5JNx8BNNO3lKGrHOn QTXRIbyGgGbxrEf6Pnh8ClvX6BiPXLQALpsc0enqniaTyMsRtINtgjSW7rhoigo0iqZt 0BOU0Mr3+V3tdXQRAAckxwhKRvOamFMFdXxtRP6N9dSzu3gdBmTWh2RCjhgqhaSe86RC rRbQ== 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=Uv9/NsakBYDus7U5hxuSWCTWC+9UdeQcjp0M/GtzVvI=; b=rXpkPXuAK1y+yh3LXc6zKc/kzu5k6NLyBMfmw/sLeFBLiz8DAqFF+3h0gspncPEUiM FGUrDSlBD7nhkM7AYDyc9NryPiC8LFVaZ8OID3RN+Iv10t88BoIJM2dWfBb5o6hsltxs ajsfK/HLTYFJjM2GqLmQPfYsMQV/AFfJ9yHMKpPJVY0rmKyrpNbX5H5VTTXEQAN7e3ME J5ghC32wi7LSMFBPuYsbcTvI/0LKWRJyNmhNQABavd89I/GS4PJaNxgHRjLNuoMf9hN8 FXv3C+ZTbLu9YpRdoKtRFdrgzwut+zB2fXaU+aAjLgx1/HKugjYo9VlFqGDvtQeQfoNH Iqgg== X-Gm-Message-State: AOAM53264YXIPgeYPDb1TNZvwkTWlpspq0NQvCuN54RaQ7FDsJqOwr1M PxXkRt3DkDlRtCgMqvLZyvkvKv+rti4l3k3PTQ8NedDl X-Google-Smtp-Source: ABdhPJz7+qmDZF0znISkYUt8J5mnT2UkW6Tal7abgyMM9xdnh0hL7SlPwCZj/nBia/+1mpKgHTz+XCQKsF/qLZtyDzw= X-Received: by 2002:a05:6102:21c6:: with SMTP id r6mr4695423vsg.0.1606236633758; Tue, 24 Nov 2020 08:50:33 -0800 (PST) MIME-Version: 1.0 References: <20201123213846.EB14127C8160@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 24 Nov 2020 08:50:20 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000fafe2b05b4dd1b61" Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 16:50:36 -0000 --000000000000fafe2b05b4dd1b61 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 4:20 AM Alessandro Vesely wrote: > > If I'm going to go to the effort to download and decode a PSL and find > the OD, I'll just use the OD. > > > > One of the points of the tree walk is to get rid of the PSL processing. > > The PSL processing is a local lookup on an in-memory suffix tree. How is > it a > progress to replace it with a tree walk? A PSL search is lightning faster > than > even a single DNS lookup, isn't it? > Sure, but only if you think the PSL is accurate. Otherwise you're basing your shortcut up the tree on data you don't have reason to trust. On the other hand, a tree walk, while more expensive in terms of queries, isn't a heuristic based on possibly stale information. -MSK --000000000000fafe2b05b4dd1b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2020 at 4:20 AM Alessandr= o Vesely <vesely@tana.it> wrote= :
> If I'm going to go to the effort to download and deco= de a PSL and find the OD, I'll just use the OD.
>
> One of the points of the tree walk is to get rid of the PSL processing= .

The PSL processing is a local lookup on an in-memory suffix tree.=C2=A0 How= is it a
progress to replace it with a tree walk?=C2=A0 A PSL search is lightning fa= ster than
even a single DNS lookup, isn't it?

Sure, but only if you think the PSL is accurate.=C2=A0 Otherwise you'r= e basing your shortcut up the tree on data you don't have reason to tru= st.=C2=A0 On the other hand, a tree walk, while more expensive in terms of = queries, isn't a heuristic based on possibly stale information.

-MSK
--000000000000fafe2b05b4dd1b61-- From nobody Tue Nov 24 08:51:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790F03A11FB for ; Tue, 24 Nov 2020 08:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uYKgscXLJUO6 for ; Tue, 24 Nov 2020 08:50:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70ECE3A11F7 for ; Tue, 24 Nov 2020 08:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606236655; bh=X2Aq1tO4k9TvAvzlIb3dGT2PIQfKCKJjDI8yKBro+uE=; l=513; h=To:References:From:Date:In-Reply-To; b=C0Oag6cN5FLzdKl2hcqDgN8AW3QnCYNG/5UkMfedp4Pcn62SuD1N6PPM+n/WY9Bag LpYm80/eTE+yFevv7F7Bf1cM4AoB3Y2Lhe7WkkIg+7KWxQbk1Tdm+AaruT78oVF57I tFAxFbQskKlvzYFvbd0Gy8Q+C0qW8ClPtwTIIlwSQCv6ebIdBv/7F7MqrxSpS Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C6.000000005FBD39EF.0000018F; Tue, 24 Nov 2020 17:50:55 +0100 To: dmarc@ietf.org References: <553D43C8D961C14BB27C614AC48FC0312811FC37@UMECHPA7D.easf.csd.disa.mil> <20201123210543.694B127C778E@ary.qy> From: Alessandro Vesely Message-ID: Date: Tue, 24 Nov 2020 17:50:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 16:51:00 -0000 On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote: > I had one spam message that had 13 parts. It included both "_mta-sts" and "mta-sts" in there, as well as "mail" nine times. The last two parts were the org domain. If the message happened to authenticate, negative reputation is better added to that org domain rather than to .com or to some random mta-sts.mail.something. IOW, if we need the OD anyway for alignment, there's no point in discovery DMARC records by tree walk. Best Ale -- From nobody Tue Nov 24 08:55:39 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643BC3A11FF for ; Tue, 24 Nov 2020 08:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxnIM_OD19mt for ; Tue, 24 Nov 2020 08:55:36 -0800 (PST) Received: from wmauth1.doit.wisc.edu (wmauth1.doit.wisc.edu [144.92.197.141]) (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 ED15B3A1203 for ; Tue, 24 Nov 2020 08:55:35 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) by smtpauth1.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QKB0069K8C4ZAM0@smtpauth1.wiscmail.wisc.edu> for dmarc@ietf.org; Tue, 24 Nov 2020 10:55:17 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-1, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.24.164518, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.56.175] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qs6eXZoNhfV5TCcS7ijgz2pXg9zU9ZVZ7133ucwOannfCtb0q01x11wLVqnStmA3bg8pc9qpYUunZ8Rw21ed8S/61Q5DIj4pY2nKZeSJ7/X6EIehfvxhW7qyYLObsDJhf9ULsEeic+pWeD11UoSPeZbnK27M2WHkO4ZHMnOYazoyLM8LzBAHaamVB+n57xEaJloCzlMRd7euIaa6Ht9pUD8mdI+VC5mfzmARpPKfmrRMqjQa2STXuNVQlDHy8fgl5Q9HUQqs9ZdICLJhOPfDor5OV7i5ljsWKZ85124CNn18AHP0kI7FRJ+UDrKfJT7US7rHWPJFtcA68COyzbdPyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8dRFGUtsnmQe1iFTy8PCkUu0gZFyDF3DA8TxI86jam8=; b=DNaRDDKUyCZX3Qm+3hsqwOeUar74DP47cNVJN7lnzwscKNH5nBVl6Wv0GX8vPf9f27UmWzULRyQq+QmjmIMZzoBBNEg9gQdtxXW4K3aeNZb7tBz/nl2pdsE8HLRuc6dzn9xVgzWr0cXIa10Uf45LxPFKuMgAjej/yR+2Aus1KNip7O7S6pMCDRG+dY/rPOKzEEZWlZ3F5OhPE+ODT6a0ZjLVOCUmOKhEh5z5hXUlHT9cbhSs6W6sVvdksVOVPdAtxzScM9l2v+tgnaYXu0wPe0Fil2teAOsBBKKtLfWNTjBm3/LTJrgIMmhkKwjcNTJ/uMUKzh6FBNj01IodkCIz+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8dRFGUtsnmQe1iFTy8PCkUu0gZFyDF3DA8TxI86jam8=; b=tB2HFGxUp+W0gAlTEL9OLX6pEvIUlIWwqyfJaCAX+GxIr1oIxcitjX7pVb6Xj8JySWTMlJcr2lHF1Ka2E/aquomsLBbI7/zn+UetaZMQy9aPHsEozM2wCkpHtNhgZ/7tncHrooyXtjIqqPH6MwGhS5Z9YgN61/j/hlasgTAmPJg= Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by CO6PR06MB7252.namprd06.prod.outlook.com (2603:10b6:5:345::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.29; Tue, 24 Nov 2020 16:55:15 +0000 Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5%7]) with mapi id 15.20.3589.022; Tue, 24 Nov 2020 16:55:15 +0000 To: dmarc@ietf.org References: <20201123213846.EB14127C8160@ary.qy> <29d3b145-1652-8b62-5eb2-74993e95eb45@gmail.com> From: Jesse Thompson Message-id: <9ab0d7b9-2e35-f64b-02ea-a111c10acabd@wisc.edu> Date: Tue, 24 Nov 2020 10:55:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-reply-to: Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [47.12.96.133] X-ClientProxiedBy: CH2PR05CA0045.namprd05.prod.outlook.com (2603:10b6:610:38::22) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.0.2.111] (47.12.96.133) by CH2PR05CA0045.namprd05.prod.outlook.com (2603:10b6:610:38::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.9 via Frontend Transport; Tue, 24 Nov 2020 16:55:14 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a2273de3-541c-48bc-8df4-08d89099b737 X-MS-TrafficTypeDiagnostic: CO6PR06MB7252: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: U9VqaDXqoAZJdE0Lp4mvtLxdKbTRJWDqMs+i1NCg4yLmmb9HLDwPn8NQYozHtvEGDzcQX7A+goJr1NW+4dUZbwU3/Tx3UKHphpiXM5yz+t3JDCei0BZO56UHLPoRr7pc4y7qCCnTewZOmWTHNHXwumeG3IgltNXh8Ca7NqUjeATOObFH+am0t03PsDaANOt3blRpn76ofHYm5qggNdl07+srwFn0s7EaET+ZqE5UJ0KNTvzANgmOSXjHcklN5+Unq+v0WW/M+tgAlj5wBneqSu48cQqFsKXKDwL29vp5ZUxzucoQGuKkxmmNaJfnBvgyuMm77vG+qf0IcAT9/lGu9tW3uqZ1Trog3LaYuyrhEl91UG25S2uA2y3bpRiXyJEU4R58e62P6zU3VKV4zb/neGJLLU39mYGVL+3XY6kkoXUey8ZOsPNZC1grLXtfAnJGIJ0A1cBGWmDfFcnZEEBylw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(346002)(376002)(39860400002)(366004)(6486002)(31686004)(53546011)(66476007)(66556008)(66946007)(316002)(786003)(26005)(6916009)(16576012)(5660300002)(75432002)(83380400001)(16526019)(31696002)(186003)(2906002)(478600001)(44832011)(956004)(36756003)(8936002)(8676002)(2616005)(86362001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VUF5MzNqcVhkRkk0UmpyTWhEc2pIWlNIc3A4ZlhickdoYlZyRTkyRTUrQm9B?= =?utf-8?B?ZlB0Uk9jVHV4cm5JVnRKWGpLcHR6eEl4VVlSTlBPd0tlb2JUYXllQ2h4QlYz?= =?utf-8?B?c0w2amVSZ2p1Z1ZoRldBUHpseVdNUGJkTlNBQWh5SkovQS9nWlFMR2hiWmxY?= =?utf-8?B?QmFRbnY5ZGIrdHl3ekFZREJXSEoxTnpSYllXVFhjK2FCTFJQUnhRUHNlb3Qv?= =?utf-8?B?R1VCNVBzdlE1WkQyNi9aNGR0KzdrY3BpQjFTckNtRXRuQ3lEOHBQb3JRTTVl?= =?utf-8?B?NExrLzZsbEppbndocUhRSjF0UzhDTmhQaGJtVGVYU01jMERxU1dqem9WN1Zs?= =?utf-8?B?Vjd6b0l6a0dyaFpBQ2lJK1o2TWM1TnZ3L05QU2prUHdsaFJQZFlmMkhUK3pt?= =?utf-8?B?L1M3NWcrYytRc0NsTUJhSWszZ1JhbUlaOCtxZFhiU0lncTVlT3RxOXR0YVBL?= =?utf-8?B?YWpOMjFnSk9sajl5Rk0zcTh3Mi9MamlyZHN6ZmtVaG52T21nVXFzblpHRjFQ?= =?utf-8?B?WGYvRlFpdWNDYk0vczdzN0pkZDJuY256N0lqZXNHOTRSSngrZktuYTgvN1dy?= =?utf-8?B?T2d3SVVLT253NnpveHJiSlg5VGN4UnlNYTZyWHN4MmJMRTFzL0tmbCtOK01y?= =?utf-8?B?dVl2WEt6UWM3aDNEU0VVMmR3Q2wzTzY2OUR4R2x0RlhHaHRqY3BhTWlzODBU?= =?utf-8?B?SGZmR1ZWd2Z1emx6TlpQOWg5c1dWUStXZW90TGhaWFBmUGpCV3FLUXNpVWZn?= =?utf-8?B?QUVuTDRQM1V2QXFLZDhzaUlmaVdFSHV1eUdMQUVmeWtJRzZqU282K042STdi?= =?utf-8?B?YW05NVRZY2grdXpzMXVlcENGOWJwYmhHTllLSmdRd01xakJwczk4R2llWnVk?= =?utf-8?B?bkt4Y1RyOUhWaXBhbm9RUEdUWmNVZUpjdFlheWg2WktmeDE5NG1GSmx1cVli?= =?utf-8?B?bktWM1VNbmJGMzFGZVkrZHpmQWQxZG9OYk42bkIwc1M5SjZLVGVwYVpXVDJD?= =?utf-8?B?KzRhYzgzVXlLeitVNkw0ZFdrR1pOMTFwMkRYU1ZWTjdwa3ZTbWFlQXBKa24y?= =?utf-8?B?Z3hOb0tTSy80MzVLUjJZN0tPR2Uwczd3S3Z4YjFHY1dDYzhya0FpenprQlRG?= =?utf-8?B?Q2hpNllsU1REUVpTL0NQVC9SWDN2dDJuZ3VCb294U1IxQWdTeDdhNUlkbnJw?= =?utf-8?B?NnNpcFB4S2ZuTUNQRE00OUx2ZXBMeCsxcmlIYTNBWStNUkNqVHNTY2lEbEZU?= =?utf-8?B?MlVMKzhMdjdKT2ZvRkNLaGFMWi9kc0JOdVBtTEl0TWlmcmFZa1hid3RGVU53?= =?utf-8?Q?eEoGNyRbyvR1ZHX33wuo2EcvJce/KVeEj7?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: a2273de3-541c-48bc-8df4-08d89099b737 X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 16:55:15.2984 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: N92Mh2zqXO2hjiAkUB4Kg+tB/BjWae7AdDsTJHrsq/ec9/ds8LMMuVENnGkkkC6C5QQZ9avTm+QX85I/WPHIHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR06MB7252 Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 16:55:38 -0000 On 11/24/20 9:52 AM, todd.herr=40valimail.com@dmarc.ietf.org wrote: > On Tue, Nov 24, 2020 at 10:37 AM Dave Crocker > wrote: > > Just to be clear, I'm not challenging the need.  Rather I'm just looking for text that explains the need.  And I'm not finding it... > > On 11/24/2020 7:28 AM, Todd Herr wrote: >> There are two reasons (at least) for needing the Organizational Domain, and they are discussed in RFC 7489: >> >> 1. DMARC also allows for the explicit or implicit expression of policy for sub-domains at the Organizational Domain level. This matters for those times when _dmarc.RFC5322.From.domain is non-existent and RFC5322.From.domain is a sub-domain of the Organizational Domain. >> 2. The default mode for authenticated identifier alignment, relaxed, requires only that the Organizational Domains for both identifiers are the same, and so the Organizational Domain must be known in order for relaxed alignment to be ascertained. >> > Except that I do not find either of these points provided in the document. > > For point 1, this is from Section 6.6.3, Policy Discovery: > > 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the > DNS domain matching the one found in the RFC5322 .From domain in > the message. A possibly empty set of records is returned. > > 2. Records that do not start with a "v=" tag that identifies the > current version of DMARC are discarded. > > 3. If the set is now empty, the Mail Receiver MUST query the DNS for > a DMARC TXT record at the DNS domain matching the Organizational > Domain in place of the RFC5322 .From domain in the message (if > different). This record can contain policy to be asserted for > subdomains of the Organizational Domain. A possibly empty set of > records is returned. > > > > For point 2, this is from Section 3.1.1, DKIM-Authenticated Identifiers: > > In relaxed mode, the Organizational Domains of both the [DKIM ]- > authenticated signing domain (taken from the value of the "d=" tag in > the signature) and that of the RFC5322 .From domain must be equal if > the identifiers are to be considered aligned. In strict mode, only > an exact match between both of the Fully Qualified Domain Names > (FQDNs) is considered to produce Identifier Alignment. The end of Section 3.1 might need to be clarified: "Relaxed mode can be used when the operator also wishes to affect message flows bearing subdomains of the verified domains." * I assume that relaxed mode can be set in the DMARC policy of a subdomain even if the Organizational Domain doesn't have (or want) that in its policy * The subdomains in this context are the subdomains of the Organizational Domain, rather than the subdomains of the domain that published the relaxed mode in its policy So if acme.example publishes aspf=s adkim=s It does not prevent finance.acme.example from publishing aspf=r adkim=r Which would align widgets.acme.example with finance.acme.example even if the intent was to only align delegated-esp.finance.acme.example with finance.foo.example Suggested better wording: "Relaxed mode is determined from the policy of the RFC5322.From domain or from the Organizational Domain policy if the RFC5322.From domain has no policy. It can be used when the operator also wishes to affect message flows bearing subdomains of the Organizational Domain." If "walking the tree" is viable, then perhaps it should be: "Relaxed mode is determined from the policy of the RFC5322.From domain or from [something about walking the tree to determine the policy]. It can be used when the operator also wishes to affect message flows bearing subdomains of the domain that published the relaxed mode policy." Jesse From nobody Tue Nov 24 09:03:59 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88E03A1216 for ; Tue, 24 Nov 2020 09:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=F/5vcwQy; dkim=pass (2048-bit key) header.d=taugh.com header.b=UE4tdDcB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIGQX7wiSfaQ for ; Tue, 24 Nov 2020 09:03:55 -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 18CC33A120E for ; Tue, 24 Nov 2020 09:03:54 -0800 (PST) Received: (qmail 62593 invoked from network); 24 Nov 2020 17:03:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=f47a.5fbd3cf8.k2011; bh=Rwb9F7Ch3DF9LiCvHSpZ3mT1Yu9Sp+USyxrBrzIT5to=; b=F/5vcwQynWWHZSPbAwjNxvp+FldHPf84FVl/ae1/kp7R3V193xAj1LhUfX/E3R4VZCXtk56MJYmcq9F91AnZ7M8hHfxmrqg1bXBxMD3yZViFynI/PqlC72x60MIWabHLGW7iFMLBozkwLrXea/6bt3iI9K4gVFY0AUduR2r2RrHKr7+UvXpamvnE4fbSkylkqt5OfJzLa9Dhum4wgTgDrHhyUjyLx1N1hQC6pZoc2+5B2NycWvs/Q2xI9ivBA2eDGOlENUfMK0v6XurAVdW7yiA4k2h/OMknHay2b3U9SAdgXy8/WeTxjEpC6PCFPG8pAnt6VS195e/5hA/MY5TYCA== 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:cleverness; s=f47a.5fbd3cf8.k2011; bh=Rwb9F7Ch3DF9LiCvHSpZ3mT1Yu9Sp+USyxrBrzIT5to=; b=UE4tdDcBzjqfOZ/gC4dZnzdmg3g14pYDKnVPmKrmBZvI3lZqma/F0Qh5agXPH4sS23Dx8QBBSr5P/NY3SrJ6JV3E4d4di2wh9F1p01oiiWzu/z61atCd7Uwe6+v/0QTR4J98u51ZFXiUin3mMDYv5PZtDChxbn3E3vnbGCQ++ObMGX9832pHRnD5VEcF5SVQPbR3swkEMSGKv+DAWwRPA6g17qIh1D1ohqtKMzdsXa8GoaSaxAuZu2656MsymR2bkx2s6eACLL9FY0/YT5kv6iSlGJHasajhykhKknKQmcc2bb4XGB0GoLtSNP8tWQZ5l3Cp/M5IChnG4I4amBV+sA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Nov 2020 17:03:52 -0000 Received: by ary.qy (Postfix, from userid 501) id C430227DFEBF; Tue, 24 Nov 2020 12:03:51 -0500 (EST) Date: 24 Nov 2020 12:03:51 -0500 Message-Id: <20201124170351.C430227DFEBF@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 17:03:58 -0000 In article you write: >> One of the points of the tree walk is to get rid of the PSL processing. > >The PSL processing is a local lookup on an in-memory suffix tree. How is it a >progress to replace it with a tree walk? A PSL search is lightning faster than >even a single DNS lookup, isn't it? You have to download a copy of the PSL, read it into your program, and parse it into some internal form. The PSL is over 200K of text and 13,000 lines, so while it's not a large file, it's not zero either. If you're lucky you can amortize your PSL parsing across multiple DMARC checks, but your DNS cache amortizes DNS lookups across mutiple checke, too. The DNS approach has the advantage that you don't have to depend on a third party's text file updated at unknown intervals, and also makes it easier to deal with what I've called the Holy Roman Empire problem. R's, John From nobody Tue Nov 24 09:07:11 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF9C3A09E0 for ; Tue, 24 Nov 2020 09:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=KutuFFqx; dkim=pass (2048-bit key) header.d=taugh.com header.b=gMUyAMOu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOFghyE1jb5t for ; Tue, 24 Nov 2020 09:07:07 -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 E60153A1218 for ; Tue, 24 Nov 2020 09:06:23 -0800 (PST) Received: (qmail 63416 invoked from network); 24 Nov 2020 17:06:23 -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:cleverness; s=f7b6.5fbd3d8f.k2011; bh=u6yHm8+DcWEQtz/+cRbIq+LICM9yHFCHwOEz4l1jCo8=; b=KutuFFqxujr3/bvhCs9gGtqQXAebcVbitnkbLhYEuFPaGPkhOmXg4cM65ljlnVnuSrvHaFD0YLJMByV4kgS9+BrHwlFoZojWyhd4SK6dgghrxl1Ck0k+RyNs/5zGO8lPiNIjPQGj8Jeg1BsBxoeiF0hi/SlEnYwe9H/Q3uCNKbWyhg1DQdlJU0tUAE6v+l3lgmio6euksHZJvuZIjs2EpSjhFO00XUnfPMOg4F/X5X8yJ1IX+ewmKag9vJ23aqFioS3Nv7BWHP66ddNTvdq6xTsoR2r85UAa206T9vomMH5Q9Ices+SfWZMuc7yB0h3nDyzHqntSDtYIC9eAwlo4tg== 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:cleverness; s=f7b6.5fbd3d8f.k2011; bh=u6yHm8+DcWEQtz/+cRbIq+LICM9yHFCHwOEz4l1jCo8=; b=gMUyAMOuCT3NAk+nOsidhMIlgV99VL8YOaa0ZYnmke/ncTzgXLB29OQ8wqHRa9zD64AI6C/KjVWQvgZKETBa3B01Go1Ktt2TwvVCeylP9OgA1phhd7MfyC7xGu//dL5HyIKLgSQBQqPC+qZpKI1082I/flm2PmTp/4miR0rglGsbv7dHPhntdF4S1iGlMJ7FvT3fDD8wb1ytpz+LGRHchWepVy7zEyDA+YcUgqgaMVp0QWD9usSeZVvhjDHZzNAKzS9glzmN6ocpCRMcLn1mGxNOTPpe3t4lWNttP6InmvjdSN8F9s8uPEZS1M9OY6WQ5gLWUwDlDFA8yTAP3o9/Kw== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Nov 2020 17:06:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 4A1C127DFEF1; Tue, 24 Nov 2020 12:06:21 -0500 (EST) Date: 24 Nov 2020 12:06:21 -0500 Message-Id: <20201124170622.4A1C127DFEF1@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: vesely@tana.it In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] tree walk and Org and PSD, Second WGLC for draft-ietf-dmarc-psd X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 17:07:10 -0000 In article you write: >On Tue 24/Nov/2020 13:52:43 +0100 Brotman, Alex wrote: >> I had one spam message that had 13 parts. It included both "_mta-sts" and "mta-sts" in there, as well as >"mail" nine times. The last two parts were the org domain. > >If the message happened to authenticate, negative reputation is better added to >that org domain rather than to .com or to some random mta-sts.mail.something. Why would you think that spam was sent by the actual holder of that org domain? Since the address contained an underscore, it's invalid anyway so you could probably reject the message without a lot of extra checks. >IOW, if we need the OD anyway for alignment, there's no point in discovery >DMARC records by tree walk. My plan is that whatever you discover by the tree walk replaces the OD. In the likely common case that the tree walk ends at _dmarc. you get the same result either way. R's, John From nobody Tue Nov 24 09:21:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E133A0A2C for ; Tue, 24 Nov 2020 09:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=FeavMwqi; dkim=pass (2048-bit key) header.d=taugh.com header.b=LQeFbyyC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTbmXxB_6QBq for ; Tue, 24 Nov 2020 09:21:44 -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 890D93A0A29 for ; Tue, 24 Nov 2020 09:21:44 -0800 (PST) Received: (qmail 69193 invoked from network); 24 Nov 2020 17:21:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=10e45.5fbd4127.k2011; bh=82E23BdelowRJCxiiFrxW4KXIW2lSD37jXzPyOV7kCw=; b=FeavMwqi/Fw1NPM62e9jCIvKI4AcN0wwhNpcOLG2HoC36Ri8e5diEF3eVhGa1NqUm/duRYEWo4Rq3epYvbT1X+H3oTtzUd6D2WvkjqV1Lk1MqonIDQwxKdGMYbLHN6pH4jrIqwGfdvEJp524YNYAGBFZx1nfyFQQMhZ34cNU4HVztVpvT6Gl4PbJvGu41LkVLRo0y7yDf6jJKVq9OeVlF6UJNGQRjh05nPsjHkn+dd2VPRqO1mUeIFZH3gTnp3SFnnKeVOU6/ljwb18ho9HeiJi5ILgmK7s/qkbBVI3AshH3azp89Hv8sJ6CzSiVhEw5b0b+NLbzkPOVjvDM5iCYjw== 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:cleverness; s=10e45.5fbd4127.k2011; bh=82E23BdelowRJCxiiFrxW4KXIW2lSD37jXzPyOV7kCw=; b=LQeFbyyCTpVd/AWz5VEJHoKWmIUIeNLLTyR9RfEd2EQ7qwIA6fR8cn/hS6XGKayCEkPIrvmhcXKIWuNA5jYQ4io842N/nfOiZ8ckA+oCtZNcjAs20o9c1k4zTOLemWo5rKPeY6VPcudnw+1JZU0s33bXvBuRnTA+sk3ImcMK5cBqRDrPayVQNTVrY/xqeWYnoAPZsZv+Vu7EOFfXr2CxZnwTbmuWnRk+a39cTM+K0beZf2c5rD9UIhYF+ewK0T73OyzxKbAtYEZAKOLr/E8yfMEC0yeCLeh1gC+/z5q3pOvPLKBbDBif83HNEqOtujCCnBus9mbE9Zm+fiHOU2a4Nw== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Nov 2020 17:21:42 -0000 Received: by ary.qy (Postfix, from userid 501) id 3721027E0851; Tue, 24 Nov 2020 12:21:41 -0500 (EST) Date: 24 Nov 2020 12:21:41 -0500 Message-Id: <20201124172142.3721027E0851@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: jesse.thompson@wisc.edu In-Reply-To: <9ab0d7b9-2e35-f64b-02ea-a111c10acabd@wisc.edu> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 17:21:46 -0000 In article <9ab0d7b9-2e35-f64b-02ea-a111c10acabd@wisc.edu> you write: >So if acme.example publishes aspf=s adkim=s >It does not prevent finance.acme.example from publishing aspf=r adkim=r >Which would align widgets.acme.example with finance.acme.example even if the intent was to only align >delegated-esp.finance.acme.example with finance.foo.example With the tree walk, I was thinking that if the tree walk finds a _dmarc record, that acts as the organizational domain, so finance.acme.example can only allow alignment with itself or its descendants. This is different from the way that OD works now, but the questions are is it worse, and what will break if we do it. R's, John From nobody Tue Nov 24 10:18:14 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097203A0930 for ; Tue, 24 Nov 2020 10:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayzpj236S73P for ; Tue, 24 Nov 2020 10:18:10 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD13B3A0880 for ; Tue, 24 Nov 2020 10:18:10 -0800 (PST) X-ASG-Debug-ID: 1606241887-11fa313c014d030001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id 9zfNu4gTYEie5OrB (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for ; Tue, 24 Nov 2020 13:18:07 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=fpKL18yL2No17rnHrewEaB1doFGZLn7dZTnL//Eq64w=; b=AGVsrEgIFKbN1ZK3aXNJsDwdvTGitzBQR8xys0k2EalEan5PjUUE+27HnTvojFaQA NQnNP3KtgFDyiyW8FQMw5H3C9NWjnL/4jJCKOLbdVipb0gisgh9WqRvIlSH/YPbOA iswd8SUDfSO7ZsnxoDp83r/aWV5+b1+u7raNHcuzw= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 24 Nov 2020 13:17:58 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'IETF DMARC WG'" References: <9c1dc4dd-48b2-9d2c-4cb4-dac733169a0f@dcrocker.net> In-Reply-To: <9c1dc4dd-48b2-9d2c-4cb4-dac733169a0f@dcrocker.net> Date: Tue, 24 Nov 2020 13:17:59 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] org domain and dns-perimeter draft Message-ID: <00a301d6c28e$23adddf0$6b0999d0$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL2Inrsj+hkDBhutDtDqei8L1UW9aeYz32Q Content-Language: en-us X-Exim-Id: 00a301d6c28e$23adddf0$6b0999d0$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606241887 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 3915 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86095 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [dmarc-ietf] org domain and dns-perimeter draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 18:18:13 -0000 I am intrigued by Dave's document. I have not yet read John's. John described this topic as a battle, so I wonder if we need a crash course in the results of those battles before revisiting the topic. One of the issues that did not seem sufficiently addressed was split-mode nodes, where some descendants are public suffixes and some are organizations. At that point, the plan becomes dependent on organizations publishing BEGIN records. Similarly, if we ask PSL's to put a flag into their DNS entries, we have to assume that some will comply and some will not, and some will do so in phases. TThe document did not provide a mechanism for the evaluator to assess whether data is complete or missing. I am attempting to fix those concerns. Nonetheless, these thoughts are an abstraction inspired from Dave's document. Note: I only know how to make this work if we assume a tree walk that goes downward. At each public suffix entry in the DNS hierarchy, we check for these flags: Public suffix flag: This is a PSL entry, it neither sends nor accepts email. You must look for an organization start somewhere below this point. (Optional) End flag: There are no public suffixes below this point. Every lower entry is an organization start node. Entries with a public suffix flag are stating an organization preference or spoofing. Deployment flag: All public suffixes below this point have been tagged. - Once this flag is detected, if the search finds a node without the PSL flag, it is an organization, not a public suffix - If this flag has not been detected and the search finds a node without the PSL flag, use the old PSL to find the organization node. An evaluator can walk down the tree and can always find one of these: - an Organization entry, - an ambiguous ending which triggers the need to consult the old PSL, or - an excessive search depth which is handled as no-data-found and possible malicious intent. Spoofing assessment: We cannot prevent people from mimicking a PSL flag, so we just need to limit the risk. As the tree is walked downward, the first entry without a PSL flag stops the search. The PSL flag should never be checked based on a walk up the tree. This eliminates the opportunity for mid-tree spoofing. I see no great risk if an organization wants the top of its DNS structure to behave like a public suffix, so I don't know that mimicking a public suffix is a problem. The only caveat is that we need a maximum depth to limit malicious DNS structures intended to waste search effort by evaluators. Doug Foster -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Wednesday, November 18, 2020 12:55 PM To: IETF DMARC WG Subject: [dmarc-ietf] org domain and dns-perimeter draft Given the renewed discussion about organizational domain and alternative boundaries, I'll suggest that this draft from last year might be relevant: DNS Perimeter Overlay > Abstract > > The Domain Name System (DNS) naming syntax provides no meta-data for > indicating administrative transitions through the hierarchy. For > example, it does not distinguish the higher-level portions that > operate as public registries, versus those that operate as private > organizations. This specification creates a basic overlay mechanism > for defining a logical Perimeter between administrative entities > through the naming hierarchy. The mechanism can then be applied for > a variety of independent administrative indications. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Nov 24 10:19:21 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6E3A091B for ; Tue, 24 Nov 2020 10:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9BI4ai64ZbS for ; Tue, 24 Nov 2020 10:19:18 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 E014A3A0880 for ; Tue, 24 Nov 2020 10:19:17 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id t37so18114310pga.7 for ; Tue, 24 Nov 2020 10:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=7qZpRFjNFggQYJgr6V+4N8Qp6b7AOfJCmWyd2gB5T78=; b=jPTdfT/O3SC7OzCaamsZlCHV71LRK+Wbuayij4HIHTPlN1VaxC+i5IfvnLkZth8BXt tOVsVKWygsVlzppHOS9uF2CYeuNMNQGu8umhhFlmwuyDPLwfpWJUdovaWQ67YxN4hopE kDG54zJRS9JXTSea9CDT8rzYtmFM19jufkb+70PpbuMQT1KZQe25f7NLUyOohCS+RLS7 t0TTULuKKAFxAKW89qQbfX3as+xVksVrWcrpUN8kQ+FyTN6hWLFSnReUqOcZ6qVfXubZ Pfyx2Uj1HAfidQyxQrJUjxgIUeElnaOM4f0SLeFfMtgOIC3LJE5R026tYHUXWjhIFCYJ AATg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=7qZpRFjNFggQYJgr6V+4N8Qp6b7AOfJCmWyd2gB5T78=; b=H1NJJGHrgI+pnVHnpp1AMymZZjyJFKITDC8hnFriGnJrnZRxOQfX5mJa4eZCEt44wU 25UUgCISPLMMXeIYQtwrs5t936ZksLVQnhQF/QdwT+ZJE3a4QsagTqpoCzdRgm6hR0Yj Ukt0WW3nVWynV5Ofv/7JsPBvlq6d1ZRvour1iioY1X0OwTYKt28DeDB3TqgVh9b1fKDY 0Rm+QXk+guPEwlsDIVBGxTBi68eSzdHCBO2/pxrj3b3GI6+dwB/d2KI69c9i7zBS6IdU yhUQ3797pzhWx87sOkXcVA29rXGfwc4lpRbnZKnQua0ihgqWN0FCLwY86JC1PRYkV89u T5tA== X-Gm-Message-State: AOAM532rhsfOgmnpLefCZN7rg6vLfb57zHSLKJD1Y/HY4NePKN4/O07p t6Hy/lPEdTqSOoORjLVZn03uJQJ82+o= X-Google-Smtp-Source: ABdhPJw6zGDswtDwsf9NmJnGG/LA8Hz4/FMChjfj8vyzxRQljJ2D2cbhbNDmvShVKxbXOePBZuXlRQ== X-Received: by 2002:a62:8f4e:0:b029:18b:bd18:75b7 with SMTP id n75-20020a628f4e0000b029018bbd1875b7mr5050350pfd.48.1606241957103; Tue, 24 Nov 2020 10:19:17 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net. [24.130.62.181]) by smtp.gmail.com with ESMTPSA id 199sm14582731pgg.18.2020.11.24.10.19.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 10:19:16 -0800 (PST) To: dmarc@ietf.org References: <20201124172142.3721027E0851@ary.qy> From: Dave Crocker Message-ID: <6e5a3818-651a-6ae7-9639-3380ef2c111d@gmail.com> Date: Tue, 24 Nov 2020 10:19:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201124172142.3721027E0851@ary.qy> Content-Type: multipart/alternative; boundary="------------17A4F7F7FCC701073BF4CC01" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 18:19:19 -0000 This is a multi-part message in MIME format. --------------17A4F7F7FCC701073BF4CC01 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/24/2020 9:21 AM, John Levine wrote: > With the tree walk, I was thinking that if the tree walk finds a _dmarc record, that acts > as the organizational domain, so finance.acme.example can only allow alignment with itself > or its descendants. > > This is different from the way that OD works now, but the questions are is it worse, and what > will break if we do it. Let's consider some attributes, starting with a trivial initial set... *Accuracy:*       How accurate is the data that gets retrieved? *Reliability*:    How likely is it that a query will complete successfully? *Latency:*        How long does it take for a query to complete? *Vulnerability:*  How easily/likely is it that the service can be compromised? *Scaling:*        How well does it operate, at Internet scale? *PSL* *Tree-Walk* *Accuracy: *       Known problematic        100% *Reliability:* High                     Mixed *Latency: * None                     Potentially high *Vulnerability:*     Generally none           DOS *Scaling:*           Poor admin, good ops     Good admin, potentially poor ops d/ -- Dave Crocker dcrocker@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org --------------17A4F7F7FCC701073BF4CC01 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/24/2020 9:21 AM, John Levine wrote:
With the tree walk, I was thinking that if the tree walk finds a _dmarc record, that acts
as the organizational domain, so finance.acme.example can only allow alignment with itself
or its descendants.

This is different from the way that OD works now, but the questions are is it worse, and what
will break if we do it.


Let's consider some attributes, starting with a trivial initial set...


Accuracy:       How accurate is the data that gets retrieved?

Reliability:    How likely is it that a query will complete successfully?

Latency:        How long does it take for a query to complete?

Vulnerability:  How easily/likely is it that the service can be compromised?

Scaling:        How well does it operate, at Internet scale?


                   PSL                      Tree-Walk

Accuracy:          Known problematic        100%

Reliability:       High                     Mixed

Latency:           None                     Potentially high

Vulnerability:     Generally none           DOS

Scaling:           Poor admin, good ops     Good admin, potentially poor ops


d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crocker2@redcross.org
--------------17A4F7F7FCC701073BF4CC01-- From nobody Tue Nov 24 10:48:01 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381863A1390 for ; Tue, 24 Nov 2020 10:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Fpp2c3ZNTTl0 for ; Tue, 24 Nov 2020 10:47:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB2A3A138E for ; Tue, 24 Nov 2020 10:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606243675; bh=eYAN+aL8mldSx4aJC3qyuC0ggiQOhe1+ZJdYTIZpa1M=; l=2561; h=To:Cc:References:From:Date:In-Reply-To; b=DUKp2Yj70frJ6fSkmyj2I+hp1bYJ3AZ8As3sKBl08keLhBlC/1tv+11wqIG28GkOg UUZhQqFzQtBthH74Po7UCzbgBUfB8CBOEHoJZ9mzo1rMi6Rl0iuMeBkko++U6Qpi1O kp1/4fb7r2sbj4WsKntuG6KHmav56HbSpThgbG0m71CJCXFdGb8fj9ViompUz Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: IETF DMARC WG Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC081.000000005FBD555B.00000E81; Tue, 24 Nov 2020 19:47:55 +0100 To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20201123213846.EB14127C8160@ary.qy> From: Alessandro Vesely Message-ID: <7ab9e796-0385-5206-d202-97522802393b@tana.it> Date: Tue, 24 Nov 2020 19:47:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 18:48:00 -0000 On Tue 24/Nov/2020 17:50:20 +0100 Murray S. Kucherawy wrote: > On Tue, Nov 24, 2020 at 4:20 AM Alessandro Vesely wrote: > >>> If I'm going to go to the effort to download and decode a PSL and find >>> the OD, I'll just use the OD. >>> >>> One of the points of the tree walk is to get rid of the PSL processing. >> >> The PSL processing is a local lookup on an in-memory suffix tree. How is >> it a progress to replace it with a tree walk? A PSL search is lightning >> faster than even a single DNS lookup, isn't it? >> > > Sure, but only if you think the PSL is accurate. Otherwise you're basing > your shortcut up the tree on data you don't have reason to trust. On the > other hand, a tree walk, while more expensive in terms of queries, isn't a > heuristic based on possibly stale information. The PSL is the result of a community-maintained effort. They do not follow intricate naming restrictions that ccTLDs might theorize, but actively track subdomains as they become visible/ noticed. It is remarkably good. The reason why one may happen to use stale information is because updates are not so well organized. Arguably, it's not going to reach a stable state until it's considered a sort of hack. For one, the CA/Browser forum had that stance: On Feb 1, 2013, at 10:25 AM, Phillip wrote: The public suffix list is a hack. It should go away. There needs to be a mechanism for determining if a domain is a public suffix or not but that information should be distributed through the DNS and not through an ad hoc list that a third party is meant to be maintaining under ill-defined criteria and without the active participation of the TLD operators. https://archive.cabforum.org/pipermail/public/2013-February/001146.html That stance is justified by Section 8.2 of RFC 6454. However, their current Baseline Requirements state the following: Determination of what is “registry-controlled” versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a “public suffix list” such as the Public Suffix List (PSL), and to retrieve a fresh copy regularly. https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf And, noticeably, the URL Living Standard references the PSL plainly. They call *registrable domain* what we call Organizational Domain. See: https://url.spec.whatwg.org/#host-public-suffix Best Ale -- From nobody Tue Nov 24 10:49:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BF43A13AE for ; Tue, 24 Nov 2020 10:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWaenedpLSzf for ; Tue, 24 Nov 2020 10:49:36 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264F63A13AC for ; Tue, 24 Nov 2020 10:49:36 -0800 (PST) X-ASG-Debug-ID: 1606243774-11fa313c014de90001-K2EkT1 Received: from webmail.bayviewphysicians.com (webmail.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id klQHJcorM3HUswNQ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 24 Nov 2020 13:49:34 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=DHTDMSCKnKqk1eX+FEo5ZvonRUItifKX9OpXcUae7bU=; b=M7O0lpdHr/2eViUN7AbBMr56WiO4DJ0t5iZPa+tjwB65kt+VyxuQO0BjNakhdu6GF EXgIVuxZqmoqBwx2TIRRdLfTRruIsuAg364KixwwRTvYzd+oSzSn/hdMwkz1kodP1 TtLkKQzDeTtqxHQkwoER72QUFWTwwFhSHiJj/Hk7Y= Received: from MSA189 (UnknownHost [192.168.2.194]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Tue, 24 Nov 2020 13:49:26 -0500 From: "Doug Foster" X-Barracuda-RBL-IP: 192.168.2.194 To: "'Dave Crocker'" , References: <20201124172142.3721027E0851@ary.qy> <6e5a3818-651a-6ae7-9639-3380ef2c111d@gmail.com> In-Reply-To: <6e5a3818-651a-6ae7-9639-3380ef2c111d@gmail.com> Date: Tue, 24 Nov 2020 13:49:26 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] Doing a tree walk rather than PSL lookup Message-ID: <001601d6c292$88a189b0$99e49d10$@bayviewphysicians.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01D6C268.9FCC9320" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKk2KKCq/FP3JYUwX5q4FLoKNwVTwN9iY3TqB+HDpA= Content-Language: en-us X-Exim-Id: 001601d6c292$88a189b0$99e49d10$ X-Barracuda-Connect: webmail.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606243774 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 9514 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 18:49:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0017_01D6C268.9FCC9320 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Better a correct answer slowly than an incorrect answer quickly. =20 For the existing PSL, it is not just the accuracy of the document = itself, but also the accuracy of the parsing process. Is there a = well-trusted parser floating around? =20 DF =20 From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker Sent: Tuesday, November 24, 2020 1:19 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup =20 On 11/24/2020 9:21 AM, John Levine wrote: With the tree walk, I was thinking that if the tree walk finds a _dmarc = record, that acts as the organizational domain, so finance.acme.example can only allow = alignment with itself or its descendants. =20 This is different from the way that OD works now, but the questions are = is it worse, and what will break if we do it. =20 Let's consider some attributes, starting with a trivial initial set... =20 Accuracy: How accurate is the data that gets retrieved? Reliability: How likely is it that a query will complete = successfully? Latency: How long does it take for a query to complete? Vulnerability: How easily/likely is it that the service can be = compromised? Scaling: How well does it operate, at Internet scale? =20 PSL Tree-Walk Accuracy: Known problematic 100% Reliability: High Mixed Latency: None Potentially high Vulnerability: Generally none DOS Scaling: Poor admin, good ops Good admin, potentially poor = ops =20 d/ --=20 Dave Crocker dcrocker@gmail.com 408.329.0791 =20 Volunteer, Silicon Valley Chapter American Red Cross dave.crocker2@redcross.org ------=_NextPart_000_0017_01D6C268.9FCC9320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Better a correct answer slowly than an incorrect answer = quickly.

 

For the existing PSL, it is not just the accuracy of the document = itself, but also the accuracy of the parsing process.=C2=A0=C2=A0 Is = there a well-trusted parser floating around?

 

DF

 

From:= = dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave = Crocker
Sent: Tuesday, November 24, 2020 1:19 PM
To: = dmarc@ietf.org
Subject: Re: [dmarc-ietf] Doing a tree walk = rather than PSL lookup

 

On = 11/24/2020 9:21 AM, John Levine wrote:

With the tree walk, =
I was thinking that if the tree walk finds a _dmarc record, that =
acts
as the organizational domain, so =
finance.acme.example can only allow alignment with =
itself
or its =
descendants.
 
This is =
different from the way that OD works now, but the questions are is it =
worse, and what
will break if we do =
it.

 

Let's consider some attributes, = starting with a trivial initial = set...

 

Accuracy:       = How accurate is the data that gets = retrieved?

Reliability:    How likely is it that = a query will complete successfully?

Latency:        How long does it take = for a query to complete?

Vulnerability:  How easily/likely is it that = the service can be compromised?

Scaling:        How well does it = operate, at Internet = scale?

 

           &= nbsp;       = PSL          &nb= sp;           = Tree-Walk

Accuracy:          = Known problematic        = 100%

Reliability:       = High           &nb= sp;         = Mixed

Latency:           = None           &nb= sp;         Potentially = high

Vulnerability:     Generally = none           = DOS

Scaling:           Poor = admin, good ops     Good admin, potentially poor = ops

 

d/

-- 
Dave Crocker
dcrocker@gmail.com
408.329.0791
 
Volun=
teer, Silicon Valley Chapter
American Red =
Cross
dave.crocker2@redcross.org=
------=_NextPart_000_0017_01D6C268.9FCC9320-- From nobody Tue Nov 24 11:24:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407AE3A181C for ; Tue, 24 Nov 2020 11:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3Fb2hr2utW_Y for ; Tue, 24 Nov 2020 11:24:27 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABA43A181A for ; Tue, 24 Nov 2020 11:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606245863; bh=aD8z3lpeE4lLTHlPFFgAlfJ5yGmHfh2LjQfz6FS9reo=; l=1741; h=To:References:From:Date:In-Reply-To; b=DT06STzHcIqj4J1f1rizIOJwp/Hm9A8TLZRsR1bhWfEFRaP6x8gEXlM4Nhvcm66+W i1s7u1+0Xc64hiulmhQGiHmDCFSCdaXiNqeDcpTFjofnukomzB6/M/n0IFroNqzD++ +9MWgciOhUIXy+DAM9D3FyQj3R/6GevYR+G5DXd+ALb594LCSuoCYeMnMfKto Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005FBD5DE7.00001244; Tue, 24 Nov 2020 20:24:23 +0100 To: John Levine , dmarc@ietf.org References: <20201124170351.C430227DFEBF@ary.qy> From: Alessandro Vesely Message-ID: <36f4f840-0911-56f5-185b-3f60166eab47@tana.it> Date: Tue, 24 Nov 2020 20:24:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201124170351.C430227DFEBF@ary.qy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 19:24:29 -0000 On Tue 24/Nov/2020 18:03:51 +0100 John Levine wrote: > In article you write: >>> One of the points of the tree walk is to get rid of the PSL processing. >> >> The PSL processing is a local lookup on an in-memory suffix tree. How is it a >> progress to replace it with a tree walk? A PSL search is lightning faster than >> even a single DNS lookup, isn't it? > > You have to download a copy of the PSL, read it into your program, and > parse it into some internal form. The PSL is over 200K of text and > 13,000 lines, so while it's not a large file, it's not zero either. Right. The optimal solution would be to load the list and the lookup algorithm as a shared object. Currently, my filter has its private copy of it. But then I don't reload the filter so often that parsing the file is noticeable. To wit, loading the virus database takes much much longer. > If you're lucky you can amortize your PSL parsing across multiple > DMARC checks, but your DNS cache amortizes DNS lookups across multiple > checks, too. I doubt I'd get comparable efficiency, even if my mail server has a dedicated caching resolver. Mail servers that rely on stub resolvers would experience a noticeable degradation. > The DNS approach has the advantage that you don't have to depend on a > third party's text file updated at unknown intervals, Agreed. > and also makes it easier to deal with what I've called the Holy Roman Empire > problem. Uh? The Holy Roman Empire became a disconnected tree soon after Charlemagne's death, so that looks like some of the dystopic scenarios that ISOC conceived a few years ago. Not sure what you mean. Best Ale -- From nobody Tue Nov 24 11:29:30 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5A93A18CC for ; Tue, 24 Nov 2020 11:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=G2Qhvc/f; dkim=pass (2048-bit key) header.d=taugh.com header.b=VgjvjKLC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pzmFGUl-hg3 for ; Tue, 24 Nov 2020 11:29:20 -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 223E03A18A6 for ; Tue, 24 Nov 2020 11:29:13 -0800 (PST) Received: (qmail 399 invoked from network); 24 Nov 2020 19:29:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=18c.5fbd5f08.k2011; i=johnl-iecc.com@submit.iecc.com; bh=conPJty6UtVWwEDdqFhACUuqtNHlEt+ET2B2zB38sKQ=; b=G2Qhvc/f6h0mJo4OWqVS7Wo3IlSjbJgoWl0aDRP6df4R6Sg3OOwOd/lwc4wMdvVnEVrpuJWdmVJcjbsvzpve3jNFbc35kNh9NqIpJFjetZ6s5o1l8PzH8Y/+7eoGSVFoeIdKVgIuutyelymZGl24V9mJsV2V3xEgH2d89pQwsdCX+K90AX7GifNREUS3Vey+KgatroXq1cKi/jB7avbBo1gb71hiUEHAVo5FGdjVVhA5gquPzdpjZ7NIaJFM7U7FilWDNgNPu2PTG1F79ID3PpIrEOYC8pg2eEAdIXarao2NzHsoKdZa38Y9DQT/BhAaZAbLrU4FEZelN2Jf7WikJA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type; s=18c.5fbd5f08.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=conPJty6UtVWwEDdqFhACUuqtNHlEt+ET2B2zB38sKQ=; b=VgjvjKLCastTppH+TfBDLRecCsIuoH+iAg5GZdSBBPGGQXqwykz5AsoqmeMdls97rLbTMcmLm0d9IDwrbQTC7j+qe1Zu5d76G7OWfQoU4+I5PXkdo3DUe/s72ojGpptn/J2ZPnoL1QDHU8K0PPTk3ib7jkuiZV/XuMuQj+SQiY1AkpfEFHxKrjzcjFVaTUpVu4K7890ibLhC6Y7vQeF/bIDwmIWb4/INQIWjuhkVKhCHcFcMKAYBEAZsdB5r2RGcXF8GfIun+MuSQ9rJ+hRh95RQ5mHwV+6/hL7Njem2s7sAI+lVh+mKWWz82a+ZfzZ0e3fBgykT6HzqbmF1dWMzYQ== Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 24 Nov 2020 19:29:11 -0000 Date: 24 Nov 2020 14:29:11 -0500 Message-ID: From: "John R Levine" To: "Alessandro Vesely" , dmarc@ietf.org In-Reply-To: <36f4f840-0911-56f5-185b-3f60166eab47@tana.it> References: <20201124170351.C430227DFEBF@ary.qy> <36f4f840-0911-56f5-185b-3f60166eab47@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 19:29:29 -0000 > Right. The optimal solution would be to load the list and the lookup > algorithm as a shared object. Currently, my filter has its private copy of > it. But then I don't reload the filter so often that parsing the file is > noticeable. To wit, loading the virus database takes much much longer. Indeed. I don't think that processing the PSL is an overwhelming amount of work, but I also don't think there is much difference in performance between using the PSL and making DNS queries that are likely to be answered from a local cache. > "Holy Roman Empire" Organizations, typically universities, where the nominal organization tree and the actual control are different. The PSL isn't useful because the party that controls their Org domain often doesn't control lower parts of the DNS tree. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Nov 24 14:49:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BCB3A0E87 for ; Tue, 24 Nov 2020 14:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 e5CpeP3TDGDy for ; Tue, 24 Nov 2020 14:49:20 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 2609C3A0E84 for ; Tue, 24 Nov 2020 14:49:19 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id v21so59546plo.12 for ; Tue, 24 Nov 2020 14:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=hbuWHpxqWEfZ3IZZQNk1q+802DhIb3RsgVi3cvpOB0Q=; b=N/evXsHuQKLY6iAz2CapNQFqAkVpE3ke9jVw2LDbFMzKkr0mxtsVE1kCXB8c8sA2n4 5fqI8wUFZgwvzHkweN3GtEdHlqH0Lm8g2U07Lm8s427AfQ6gr1eE534CAo0f1hv+xDpE V3vbSQe+WbXj+9HEP8xD7ZnM8vS9f47t4LueGoTn5h8OTomTVOtqRHZaxYcCJvz40vmZ EVBQlPdoIYoi6ubL5vi5vTwRIhuiAp03KnU+N17O66qiMtGmaPRusfXybynevsmzj4pG ACZrJT5hG8SCB9ggbWA01sFvrUD5hAbN+FcUF4TD6sV9FNHZ/uNyPIdTBqiZmQAhwUwC UUpA== 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-transfer-encoding :content-language; bh=hbuWHpxqWEfZ3IZZQNk1q+802DhIb3RsgVi3cvpOB0Q=; b=FQNvbj9yy2Mpkn3HU8jcpVsM2oHs9UTnpbhYBGfFSEDDDDrG5kpuIV/fXjD+lYRHQW P8XgoeAJcowiVkmYuWJ18ebN2obIxgdd6hJ9B3wPYXH9tafyl6+GdFipAPiP62JL/X9t 2IutBNj12A9YaNlyXdOpOnObXrVLpYj6knIgDvY5dEvEqOewXWVY252FhcpOAWYgkKgV fYs4jiNnixCRlrNqHPM6CePKqntYHaQGrLyvyrCpFQKFmkHRCFXhD5oJXjwTFYU9x+T+ Qz9X8ntXWvGSoZydYc1Ks7TV8S86rKURAYLH2mK4JjlYRERaXH4UKW889QonCN6mLNHc txYw== X-Gm-Message-State: AOAM531UuAczw+IpYbjsOcp4HnVLKgnbSfS0x1vsrhK0hc9JfudeXd9L lZjzOFhXuJbfSMabkFN60EP/qvcJ4WOM+w== X-Google-Smtp-Source: ABdhPJyBlqQMh/Bfl4G7zXZe/RaDDbhptItfOR33i35OzeyYDGLnS2Ox+knQsNeAHa4VSM0q+FugDw== X-Received: by 2002:a17:902:6b45:b029:d6:c43e:ad13 with SMTP id g5-20020a1709026b45b02900d6c43ead13mr550625plt.77.1606258159062; Tue, 24 Nov 2020 14:49:19 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id w2sm228799pjq.57.2020.11.24.14.49.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 14:49:18 -0800 (PST) To: John Levine , dmarc@ietf.org References: <20201124020453.AFDC027CE5C8@ary.qy> From: Michael Thomas Message-ID: Date: Tue, 24 Nov 2020 14:49:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201124020453.AFDC027CE5C8@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 22:49:21 -0000 On 11/23/20 6:04 PM, John Levine wrote: > In article you write: >> What I'm struggling to understand is what having authenticated auth-res > >from a previous hop helps. this is what i found: > > See some of the previous messages. My usual example is a mailing list > message that fails DMARC at the final recipient but passed DMARC (as > recorded in AAR) when it arrived at the list. This lets the final > recipient distinguish between real messages from subscribers and mail > from spambots that happened to scrape both the list address and some > subscribers' address and sends mail to one pretending to be from the > other. (That definitely happens, I've seen it on lists I'm on.) > > I agree that the ARC document does not do a great job of explaining that. > >> It would be kind of nice to understand what gap ARC actually plugs and >> why it's important if you ask me. Also: there seem to be a lot of ways >> to achieve this, but this one is probably the most complicated one that >> I can envision. > If you want to pass the A-R results through multiple rounds of > forwarding, you can't do much less. Sorry, changing the auth-res to old-auth-res and dkim signing the message would be completely sufficient, and far easier to understand with a lot less bloat. All of this hand wringing about dozens of message manglers in the path before it get to the destination and not be able to figure out which auth-res was which seems wildly out of proportion for what the normal case is: 1 message mangler in the path before it arrives at the receiver's domain. Just like this message right here. That's why I asked how common that was, which was dismissed, but not answered. Mike From nobody Tue Nov 24 14:57:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC73A07DB for ; Tue, 24 Nov 2020 14:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 sPpzTZO9G0HT for ; Tue, 24 Nov 2020 14:57:45 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 7E81F3A07D3 for ; Tue, 24 Nov 2020 14:57:45 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id q10so512381pfn.0 for ; Tue, 24 Nov 2020 14:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=dChT9mInGD32S8kkDlaGO/jlD0cO5koPuFgkfXxgYrc=; b=cmWnkQmB9ZxENXVrjc/3pxEDCW5qF+l+GFymSHSnVxdyotbX9pIlmqGSxXKMYUVgVj 7ZBAHrFpN2m5fYBGUkvVSrVsDeiqr986h2+FG2X7bdGJvCWZbDJGJ0AL9ck84ISAX63K HyZfAN7fouxNShTBhM8+5LmUIkJxdcx7ljqI9IOI8+H5prZfemzl6FUROJTS/OcXGdM0 j10YW64bE8KFQH2NzZy44E7kX/fcSdW73XsgBJKjr2M/3JxibqqDy9+rHKIGmGK8LP8K ZFy6t0bD4NxmlpZv9cBpsjv9Nz1BWpaiyWTD3PYXIu1oLYlaW6+f5fu456+gYPYXPLK6 eCtw== 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-transfer-encoding :content-language; bh=dChT9mInGD32S8kkDlaGO/jlD0cO5koPuFgkfXxgYrc=; b=Fk9hM6rjfdireFkSHZaewXlyZF0OTbUHwKuiz7Pgbiwjy8vHyF9M87iDdWb8PdVNhm YGO04v/dRrDRFea2TYtnSFkZ0zgok76/3e3B6WIdq4O2kHPkyOr0Ns2WJRdmqd+G5HIO P4WeLWbyGOznNI+dx1fkgVSqQq8xUQOe9GWF/iA3KrADRhYBVa5QczTYHuv0o6Jr+mVG WiZLTxoToWbx8jl6ky7K6u+yc8y3roPCDnV9oNAmerdb/6p++ANewhOnJqFQu0tD559x FTPtPKgHUyyyl0RhnM8awbBwZ+6B3QVBrA12P6fz5loF0UEqDsItTQqVNexZimQ5vk4Z ewdQ== X-Gm-Message-State: AOAM531qZ9lV5JKLaNAFRNrBd8iXLqV9/7yf9PdZZJFwIMtILwoP/mJN 26uSSF8LG8wee+rh22vO5f7XaZoYFOxtVQ== X-Google-Smtp-Source: ABdhPJzb+fDwkivT7oP27nKB1tvyrTuuAExCvrT/JCreMerwTB6XQ5Whg5PGDL3iG10ciLX7wfKqbA== X-Received: by 2002:a63:1346:: with SMTP id 6mr556048pgt.330.1606258664418; Tue, 24 Nov 2020 14:57:44 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id 21sm86242pfw.105.2020.11.24.14.57.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 14:57:43 -0800 (PST) To: John R Levine Cc: Seth Blank , "dmarc@ietf.org" References: <20201124020453.AFDC027CE5C8@ary.qy> <948761a-f116-48cc-e5e3-bf2c6f462b@taugh.com> From: Michael Thomas Message-ID: <91049852-6e97-2bfb-2d0a-067c839db28a@mtcc.com> Date: Tue, 24 Nov 2020 14:57:42 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <948761a-f116-48cc-e5e3-bf2c6f462b@taugh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 22:57:48 -0000 You'd be wrong. The only ad hominem was yours from yesterday and it was I think where *you* dismissed the very question I raised: "Two or more levels of forward are quite common, particularly in large mail systems.  Look at mail coming out of Google and Microsoft's hosted mail and you'll see a lot of ARC headers. Considering that the ARC RFC was published over a year ago, and it is implemented all over the place, could you explain what the point of this discussion is?  The people who designed ARC are not idiots.  If we could have fixed the mailing list problem with existing DKIM signatures, we would have." And as I've said repeatedly, do not contact me in private. Mike On 11/24/20 2:53 PM, John R Levine wrote: > This appears to me to be an ad-hominem attack on the people who > designed ARC, so I think we're done. > > On Tue, 24 Nov 2020, Michael Thomas wrote: > >> >> On 11/23/20 6:04 PM, John Levine wrote: >>> In article you write: >>>> What I'm struggling to understand is what having authenticated >>>> auth-res >>> >from a previous hop helps. this is what i found: >>> >>> See some of the previous messages. My usual example is a mailing list >>> message that fails DMARC at the final recipient but passed DMARC (as >>> recorded in AAR) when it arrived at the list. This lets the final >>> recipient distinguish between real messages from subscribers and mail >>> from spambots that happened to scrape both the list address and some >>> subscribers' address and sends mail to one pretending to be from the >>> other. (That definitely happens, I've seen it on lists I'm on.) >>> >>> I agree that the ARC document does not do a great job of explaining >>> that. >>> >>>> It would be kind of nice to understand what gap ARC actually plugs and >>>> why it's important if you ask me. Also: there seem to be a lot of ways >>>> to achieve this, but this one is probably the most complicated one >>>> that >>>> I can envision. >>> If you want to pass the A-R results through multiple rounds of >>> forwarding, you can't do much less. >> >> >> Sorry, changing the auth-res to old-auth-res and dkim signing the >> message would be completely sufficient, and far easier to understand >> with a lot less bloat. All of this hand wringing about dozens of >> message manglers in the path before it get to the destination and not >> be able to figure out which auth-res was which seems wildly out of >> proportion for what the normal case is: 1 message mangler in the path >> before it arrives at the receiver's domain. Just like this message >> right here. That's why I asked how common that was, which was >> dismissed, but not answered. >> >> Mike >> >> > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Nov 24 15:02:55 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6603A0E7C for ; Tue, 24 Nov 2020 15:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piycSmJgDD8C for ; Tue, 24 Nov 2020 15:02:50 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EDA3A0E83 for ; Tue, 24 Nov 2020 15:02:50 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id y26so114423uan.5 for ; Tue, 24 Nov 2020 15:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sRqQhrqkwOeghAvUNhn86GusgtFYk5rxEaDIm2mrdfw=; b=HrwF8DKueybpoxID648hDiwxf+3jmFKrk1lG7xmL+DQhqeGlfFklWBANJLRqdZcCne X8YKyVAc9AGc9+BmYBuinyvfVcl9Xy6FamBhtg0BHzv81IdCTo82B7YIokyTyVyzW7Uh dXfrdUpxTh2OLUn1Xtj4lMawgJ80kKIbJKEOkUYXavwch3IwxIDm4ynO9psiUC2oaCw6 iGMneuQe1lg0d7zcPGzlMaJapnzvOY28K2NQCYu+vxdjejDvfPUvqoj7N9xqR5ycVBV3 VlZ1cdpAmY2qJ5Ifq+XYQtn4jSPrsCXctqmeuZr574WlUic55PvsY04RdOVyhicjhaCK ktIg== 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=sRqQhrqkwOeghAvUNhn86GusgtFYk5rxEaDIm2mrdfw=; b=WS4ZH6oKEP+tiwt+WOXGFEo2W/aMraSYasFECYRmjnyQBat28guV8Wb0HIN4lkwFai 6DgW6mZiqKpxB1hF+M+PJ7GP4IKwH8jMMRpwQfyghiR+meK4Z6rhy2DLIXPklxXsE+Y5 MdR+L8O0ZaGyb0lcu6Vb/G+bObeefTZsTBL5Gb+qymNhMUbOjgPg2UZpU/LTZJv4JfBH 1f/Q9HeQhJLwhPI+ziumk9VMqqRP0Nyt/+ZD3Tm0fSMcr4W1SeCmXhkuWgxuSZMNveqz YnCyH4+XngHfGqN/kBNl7CqcosexIY6Sl+fngPWhXKKYVbPtIWwyhzcABob/ad26Dhlb phgQ== X-Gm-Message-State: AOAM530/D1IuaFsI0gB5WGxGK/zaBNGxgZyAXyLGyDwH2635eWIRRl8J 5ywIu4/FAhdjAE6gAMP552TtEyme4yfjbAPNGO45Jbevxmo= X-Google-Smtp-Source: ABdhPJzaeKEjaFiVCfxWpASO0GNR5S6MdrjiBMX1dUcqC1+gihyyLvga2FzU9Gux7rLANjIyRual3TauO5SOMHcuak0= X-Received: by 2002:ab0:3901:: with SMTP id b1mr458348uaw.34.1606258969057; Tue, 24 Nov 2020 15:02:49 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> <948761a-f116-48cc-e5e3-bf2c6f462b@taugh.com> <91049852-6e97-2bfb-2d0a-067c839db28a@mtcc.com> In-Reply-To: <91049852-6e97-2bfb-2d0a-067c839db28a@mtcc.com> From: Seth Blank Date: Tue, 24 Nov 2020 15:02:37 -0800 Message-ID: To: IETF DMARC WG Cc: Michael Thomas , John R Levine Content-Type: multipart/alternative; boundary="00000000000044af7505b4e24f46" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 23:02:53 -0000 --00000000000044af7505b4e24f46 Content-Type: text/plain; charset="UTF-8" As Chair- This thread is quickly becoming unproductive and veering to personal attacks, which will not be tolerated. Please engage productively and on the merits, take the conversation elsewhere, or disengage. Seth On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas wrote: > You'd be wrong. The only ad hominem was yours from yesterday and it was > I think where *you* dismissed the very question I raised: > > "Two or more levels of forward are quite common, particularly in large > mail systems. Look at mail coming out of Google and Microsoft's hosted > mail and you'll see a lot of ARC headers. > > Considering that the ARC RFC was published over a year ago, and it is > implemented all over the place, could you explain what the point of this > discussion is? The people who designed ARC are not idiots. If we could > have fixed the mailing list problem with existing DKIM signatures, we > would have." > > And as I've said repeatedly, do not contact me in private. > > Mike > > On 11/24/20 2:53 PM, John R Levine wrote: > > This appears to me to be an ad-hominem attack on the people who > > designed ARC, so I think we're done. > > > > On Tue, 24 Nov 2020, Michael Thomas wrote: > > > >> > >> On 11/23/20 6:04 PM, John Levine wrote: > >>> In article you write: > >>>> What I'm struggling to understand is what having authenticated > >>>> auth-res > >>> >from a previous hop helps. this is what i found: > >>> > >>> See some of the previous messages. My usual example is a mailing list > >>> message that fails DMARC at the final recipient but passed DMARC (as > >>> recorded in AAR) when it arrived at the list. This lets the final > >>> recipient distinguish between real messages from subscribers and mail > >>> from spambots that happened to scrape both the list address and some > >>> subscribers' address and sends mail to one pretending to be from the > >>> other. (That definitely happens, I've seen it on lists I'm on.) > >>> > >>> I agree that the ARC document does not do a great job of explaining > >>> that. > >>> > >>>> It would be kind of nice to understand what gap ARC actually plugs and > >>>> why it's important if you ask me. Also: there seem to be a lot of ways > >>>> to achieve this, but this one is probably the most complicated one > >>>> that > >>>> I can envision. > >>> If you want to pass the A-R results through multiple rounds of > >>> forwarding, you can't do much less. > >> > >> > >> Sorry, changing the auth-res to old-auth-res and dkim signing the > >> message would be completely sufficient, and far easier to understand > >> with a lot less bloat. All of this hand wringing about dozens of > >> message manglers in the path before it get to the destination and not > >> be able to figure out which auth-res was which seems wildly out of > >> proportion for what the normal case is: 1 message mangler in the path > >> before it arrives at the receiver's domain. Just like this message > >> right here. That's why I asked how common that was, which was > >> dismissed, but not answered. > >> > >> Mike > >> > >> > > > > Regards, > > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > > Please consider the environment before reading this e-mail. > https://jl.ly > -- *Seth Blank* | VP, Standards and New Technologies *e:* seth@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --00000000000044af7505b4e24f46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As Chair-

This thread is quickly becomi= ng unproductive and veering to personal attacks, which will not be tolerate= d.

Please engage productively and on the merits, t= ake the conversation elsewhere, or disengage.

Seth=

On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas <mike@mtcc.com> wrote:
You'd be wrong. The only ad hominem was you= rs from yesterday and it was
I think where *you* dismissed the very question I raised:

"Two or more levels of forward are quite common, particularly in large=
mail systems.=C2=A0 Look at mail coming out of Google and Microsoft's h= osted
mail and you'll see a lot of ARC headers.

Considering that the ARC RFC was published over a year ago, and it is
implemented all over the place, could you explain what the point of this discussion is?=C2=A0 The people who designed ARC are not idiots.=C2=A0 If w= e could
have fixed the mailing list problem with existing DKIM signatures, we
would have."

And as I've said repeatedly, do not contact me in private.

Mike

On 11/24/20 2:53 PM, John R Levine wrote:
> This appears to me to be an ad-hominem attack on the people who
> designed ARC, so I think we're done.
>
> On Tue, 24 Nov 2020, Michael Thomas wrote:
>
>>
>> On 11/23/20 6:04 PM, John Levine wrote:
>>> In article <e8e1d300-fbe7-6d10-c15f-30c29ab74237@mt= cc.com> you write:
>>>> What I'm struggling to understand is what having authe= nticated
>>>> auth-res
>>> >from a previous hop helps. this is what i found:
>>>
>>> See some of the previous messages. My usual example is a maili= ng list
>>> message that fails DMARC at the final recipient but passed DMA= RC (as
>>> recorded in AAR) when it arrived at the list. This lets the fi= nal
>>> recipient distinguish between real messages from subscribers a= nd mail
>>> from spambots that happened to scrape both the list address an= d some
>>> subscribers' address and sends mail to one pretending to b= e from the
>>> other. (That definitely happens, I've seen it on lists I&#= 39;m on.)
>>>
>>> I agree that the ARC document does not do a great job of expla= ining
>>> that.
>>>
>>>> It would be kind of nice to understand what gap ARC actual= ly plugs and
>>>> why it's important if you ask me. Also: there seem to = be a lot of ways
>>>> to achieve this, but this one is probably the most complic= ated one
>>>> that
>>>> I can envision.
>>> If you want to pass the A-R results through multiple rounds of=
>>> forwarding, you can't do much less.
>>
>>
>> Sorry, changing the auth-res to old-auth-res and dkim signing the =
>> message would be completely sufficient, and far easier to understa= nd
>> with a lot less bloat. All of this hand wringing about dozens of <= br> >> message manglers in the path before it get to the destination and = not
>> be able to figure out which auth-res was which seems wildly out of=
>> proportion for what the normal case is: 1 message mangler in the p= ath
>> before it arrives at the receiver's domain. Just like this mes= sage
>> right here. That's why I asked how common that was, which was =
>> dismissed, but not answered.
>>
>> Mike
>>
>>
>
> Regards,
> John Levine, john= l@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly


--

Seth Blank | VP, Standards = and New Technologies
p:= 415.273.8818


= This email and all= data transmitted with it contains confidential and/or proprietary informat= ion intended solely for the use of individual(s) authorized to receive it. = If you are not an intended and authorized recipient you are hereby notified= of any use, disclosure, copying or distribution of the information include= d in this transmission is prohibited and may be unlawful. Please immediatel= y notify the sender by replying to this email and then delete it from your = system.

--00000000000044af7505b4e24f46-- From nobody Tue Nov 24 15:23:46 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358F3A03EF for ; Tue, 24 Nov 2020 15:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 z-zJ8X9mOsAL for ; Tue, 24 Nov 2020 15:23:43 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6E33A03EE for ; Tue, 24 Nov 2020 15:23:43 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id w187so547008pfd.5 for ; Tue, 24 Nov 2020 15:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=iHaJDu4n7HFeQpyU17wZlrU/mxtmhjwSCX18kHaPWYk=; b=o5BZ+3pq7Fwx6ApgIbHc+nMLXUyL+a3S0kcKQMVHoKwrxp/5RlpvAfU4+h1xlgjmdl v8Pz/al2G32DCDC/df138BFEyXYK+99oBYlAXFoMIc5AlVBUgYXZ4U+hREWOdHLlyx3U IKQ+nbUF3KKADJD5rcz/KFS9AzK/zhwS+ysdcEJhE4eXz/EbudIqviYSqAua+Qk+PAqv 9Urpe+bEKjlPr6f/RivfCMvjHevvrM4MYUiH2+IkeggkQkrxCf23ZsJDXpPKnG/cGTQF poYDhb8wAoCECLeM0v9mrBy7j31wj2qVAlWFsNAYTrchXV4GsRQsa8BTcUgMSfctlTGa Lhfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=iHaJDu4n7HFeQpyU17wZlrU/mxtmhjwSCX18kHaPWYk=; b=b3Ju/+iUpOKxnJq/CDTskZV68LvoMPEGwlVxxB3m6ue5rxPXwVLgKVXIktUgFdbGDA f4Opp0mIbXUzYTTvjvZZinKjPQtWPYoMumKpTxWAvaXetUZT0DokDrCp864mVdWkqls1 vx6d3jtLQlmx5b/JmYIMe1Kbrz+CpwknIRRJPw+A0pqc62/PZSOP7TOqIu1lYBADu7qs TSi4HFrkbG2vwX+jABzccmxgmNEpPuRgUoQ/6SaEI13hUtPMLRZ+bgDwYnkdLTzUdkXb UJRCn+QFEwqPHzullr/aCLlB1nUZ2oGs6u4ZMKXx/mfukdcMH/1fGT6ch7Oq2YFSnZu1 WYZA== X-Gm-Message-State: AOAM531z5gBpCT6UJDn38r9ou/Ug21Hjyl5t4M723XsSiShkHGKjWRGk gcPB2FKnaEkeKmP71gqHCOLyqfm841pGlw== X-Google-Smtp-Source: ABdhPJzoMMJLvz5VoGVKuwS6dF6MLNokhtD8oOWTZUUliP9IpLyaMDkjz/IKJJgnP7h5vpIDPrkJUw== X-Received: by 2002:a17:90b:3844:: with SMTP id nl4mr625027pjb.93.1606260222166; Tue, 24 Nov 2020 15:23:42 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id a81sm104458pfd.178.2020.11.24.15.23.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 15:23:41 -0800 (PST) To: "dmarc@ietf.org" From: Michael Thomas Message-ID: Date: Tue, 24 Nov 2020 15:23:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [dmarc-ietf] Messages passing more than one modifying intermediary? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 23:23:44 -0000 Does anybody know what percentage of traffic that passes through more than one modifying intermediary in different administrative domains? I know that modifying intermediaries like mailing lists are relatively rare, so I'd think that messages that go through more than one would be extremely rare. I'm not looking for anecdotes, just hard data. Mike From nobody Tue Nov 24 15:25:10 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0982A3A03EE for ; Tue, 24 Nov 2020 15:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nOsTsD06mgu for ; Tue, 24 Nov 2020 15:25:07 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 0C2E53A02DC for ; Tue, 24 Nov 2020 15:25:07 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id m16so223707vsl.8 for ; Tue, 24 Nov 2020 15:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vtsP6+5wY3foiFxCRzGKxe/cBPmQNHkHkrOa+vfUSGc=; b=FlHxPQOEDUlgDzcE/meXD/0Gw3wF3boUaB80vaI3+pGlTsbKtDJPFvYxmXVDZ/kSQy eFCwMAqS3k6MMg1S9hnBzTmKZL2XOwUOyRhitlwtt9cIEtpqjZNkxxcA05dAXxLbC7tC 3chQfgYqKfiuQC/HmopduTxuLmO9o0L7bM3A3EtEVAOlC+WL9N7v7/6rwnpz695Cr2j0 KkM4U/6PwkWmlutzC3pVO2cv9LpMorSDTvTXjuwpQ3AGiMphB/B13gueDnq4sXYzNj9P 77DGo8eLaDYms5J+Maj+EWXjCGPzr2OgVcdAdm9+qV+ik1qfEI4B02eeLayDbo4RVjHH VIpw== 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=vtsP6+5wY3foiFxCRzGKxe/cBPmQNHkHkrOa+vfUSGc=; b=J1zbhcAGvmnlr3UO9Zn7fFWtK7ZhV+Z5PUM7LIFW6V7phAThwt312NezMZhQi7/RC0 O1FU7gXYmwHrvEHXBOG+oBhkjxBXTmX3VcBhofjQhsdAaNLJLB/ua0Wrfr0OgzcsQ7qB DcVs67vrclUa1+atYnFgtzi205kxH56GIz3v27hEXjgYAZmeTfsE7S1Jh4QrAbx0U1Aw uPpJqW2iTwodJudJ3dcd+2tYiW7pgc9PUuElYP+ABQEVZgUQDv2x0ET3iHiF3teCcuv5 +iM4pPMFBScUdSt4ENfAebtyj/06m7lJwcNCOSILqMYCCQCInqhJyz4e+spGlMK7d70e K9ew== X-Gm-Message-State: AOAM5322s3Pk6ORf+zJ8mT0bJykey9OFTlE7PZYuTMoyp7Ec3PZAbGI0 QQRPzWQIMLEn+56daNJ0AACcY9zgKcDh9uuu1D/L38ymCQ== X-Google-Smtp-Source: ABdhPJx7YLTIt16LaeboQ0/T/OU+b//6o7vQ42khgGS5UaFK0Crm2mYTZdqA4ZmfVQ2Wp5/VRS42qxyTxvu4ovz6ZxE= X-Received: by 2002:a67:df8b:: with SMTP id x11mr403818vsk.37.1606260305638; Tue, 24 Nov 2020 15:25:05 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> In-Reply-To: From: Brandon Long Date: Tue, 24 Nov 2020 15:24:52 -0800 Message-ID: To: Michael Thomas Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000efbb4b05b4e29e61" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 23:25:09 -0000 --000000000000efbb4b05b4e29e61 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas wrote: > > On 11/23/20 6:04 PM, John Levine wrote: > > In article you write: > >> What I'm struggling to understand is what having authenticated auth-res > > >from a previous hop helps. this is what i found: > > > > See some of the previous messages. My usual example is a mailing list > > message that fails DMARC at the final recipient but passed DMARC (as > > recorded in AAR) when it arrived at the list. This lets the final > > recipient distinguish between real messages from subscribers and mail > > from spambots that happened to scrape both the list address and some > > subscribers' address and sends mail to one pretending to be from the > > other. (That definitely happens, I've seen it on lists I'm on.) > > > > I agree that the ARC document does not do a great job of explaining that. > > > >> It would be kind of nice to understand what gap ARC actually plugs and > >> why it's important if you ask me. Also: there seem to be a lot of ways > >> to achieve this, but this one is probably the most complicated one that > >> I can envision. > > If you want to pass the A-R results through multiple rounds of > > forwarding, you can't do much less. > > > Sorry, changing the auth-res to old-auth-res and dkim signing the > message would be completely sufficient, and far easier to understand > with a lot less bloat. All of this hand wringing about dozens of message > manglers in the path before it get to the destination and not be able to > figure out which auth-res was which seems wildly out of proportion for > what the normal case is: 1 message mangler in the path before it arrives > at the receiver's domain. Just like this message right here. That's why > I asked how common that was, which was dismissed, but not answered. > Note that this was exactly what we started with, X-Original-Authentication-Results and with Google's implementation signing that with X-Google-DKIM-Signature. Our version didn't just sign with DKIM-Signature because of the reasons already stated in this thread, that our understanding of how DKIM-Signature was being used made it a poor choice. Our experience also showed that more than one hop is quite common in enterprise deployments, and those are also the places where the most complexity arises. Others shared our experience as well. You say that your message had 1 mangler in the path, but really you don't know that. It is likely that some people on this list are on enterprise accounts who are behind mangling inbound gateways (rewriting urls to go through safety checking hops is common, for example). Or maybe they are on with University accounts using exchange but forward their mail to a personal or department gmail account. It may be that ARC is too complicated, that other, simpler, solutions would have worked for 90% of cases and would have been better than what we've got (From rewriting), and that the real pain for receivers having lots of hops should be borne by those receivers. Brandon --000000000000efbb4b05b4e29e61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 24, 2020 at 2:49 PM Micha= el Thomas <mike@mtcc.com> wrote:=

On 11/23/20 6:04 PM, John Levine wrote:
> In article <e8e1d300-fbe7-6d10-c15f-30c29ab74237@mtcc.com> you write:
>> What I'm struggling to understand is what having authenticated= auth-res
> >from a previous hop helps. this is what i found:
>
> See some of the previous messages. My usual example is a mailing list<= br> > message that fails DMARC at the final recipient but passed DMARC (as > recorded in AAR) when it arrived at the list. This lets the final
> recipient distinguish between real messages from subscribers and mail<= br> > from spambots that happened to scrape both the list address and some > subscribers' address and sends mail to one pretending to be from t= he
> other. (That definitely happens, I've seen it on lists I'm on.= )
>
> I agree that the ARC document does not do a great job of explaining th= at.
>
>> It would be kind of nice to understand what gap ARC actually plugs= and
>> why it's important if you ask me. Also: there seem to be a lot= of ways
>> to achieve this, but this one is probably the most complicated one= that
>> I can envision.
> If you want to pass the A-R results through multiple rounds of
> forwarding, you can't do much less.


Sorry, changing the auth-res to old-auth-res and dkim signing the
message would be completely sufficient, and far easier to understand
with a lot less bloat. All of this hand wringing about dozens of message manglers in the path before it get to the destination and not be able to figure out which auth-res was which seems wildly out of proportion for
what the normal case is: 1 message mangler in the path before it arrives at the receiver's domain. Just like this message right here. That's= why
I asked how common that was, which was dismissed, but not answered.

Note that this was exactly what we started wit= h, X-Original-Authentication-Results=C2=A0
and with Google's = implementation signing that with X-Google-DKIM-Signature.

Our version didn't just sign with DKIM-Signature because of the= reasons already stated in this
thread, that our understanding of= how DKIM-Signature was being used made it a poor choice.

Our experience also showed that more than one hop is quite common i= n enterprise deployments,
and those are also the places where the= most complexity arises.=C2=A0 Others shared our experience
as we= ll.

You say that your message had 1 mangler in the path, but = really you don't know that.=C2=A0 It is
likely that some peop= le on this list are on enterprise accounts who are behind mangling inbound<= /div>
gateways (rewriting urls to go through safety checking hops is co= mmon, for example).=C2=A0 Or maybe
they are on with University ac= counts using exchange but forward their mail to a personal or department
gmail account.

It may be that ARC is too c= omplicated, that other, simpler, solutions would have worked for 90% of cas= es
and would have been better than what we've got (From rewri= ting), and that the real pain for receivers having
lots of hops s= hould be borne by those receivers.

Brandon
--000000000000efbb4b05b4e29e61-- From nobody Tue Nov 24 15:57:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20B3A08EB for ; Tue, 24 Nov 2020 15:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 ilaQeM1Hf_bY for ; Tue, 24 Nov 2020 15:57:22 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D47B63A08DA for ; Tue, 24 Nov 2020 15:57:22 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id x24so607193pfn.6 for ; Tue, 24 Nov 2020 15:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=UogYqTpKNUNb+Jk+qB7u5PvZNb6a8gX8A9QCPzAr47M=; b=c8s0w6ZNEfn+2AVyy0uCDTWbWJdShHFydvELM21nIuSmEx/sQ1e2c3Gfe7cy/dKkv/ ZTzydIUZxICzyK+WHkUq7SjkceIjbcA8S+/3jzqfAhDZ7zxYQQ9fFBc/fukQ0oeR/rMu N659iVXYy6CupAUFnqxD/y282iRaj6Iq7eQtFDi9agP+X1RUQyuArDUn3Sru0GXzqEuC 5tYTdWk9k02Z3f2EcFeuU3800hm+zceuBcnKmhr+u8XwMF2BCFuM2ZjV/1PRAsQK16sw BUm1/ueMVmU//cpT6fIbp1lz2L/1jk59qYtVPosAyGjfjYvENi13YwRYzaIO26+YWt+V aN7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=UogYqTpKNUNb+Jk+qB7u5PvZNb6a8gX8A9QCPzAr47M=; b=fdXMRygx00g7TtM+3MX5AwQU+c089ytAxv1ELT3SSMp0Mml7DlTTDXAY0/0pAmll0k VImqX8MD7ez0Z2Y+Pnd1dsh7JdqZv2fmwLCDGFv3ndMjPVd2UYerMmL19zsT9UJchWTM K8JQd735c5yTCWjwHYe5au1eaIAKPPc/WUP+CLGnoWvzI3VjZCOfVM/dSCbieKKfAZt3 Y3718S4S6QUav+qJvL/pTX/G4Hq4xCgHoRnb7aAruN7kY0u0c8750vNW4tB96vb7uxtL vo1i/YIiG6LYINw3MhWecaTJ3eS3CQxX+TlekGqFwh8aTu0T8JZehz+r+lh+bOedEJwA UUKg== X-Gm-Message-State: AOAM531dHo+l8EXXmznk0Jkw4TpqpAO7fLeQ2mJrRUq+OQqSF4vX3nR0 iUbfp73yQOUmp5PDrs+syzrxHivOihcWKA== X-Google-Smtp-Source: ABdhPJx2iJBwjwM5ZOJAMSiZop0IlMhWl0/cPUHEWMK67Sc5+OSguazPHd0PTgsTM4NsNP0mtx9WUQ== X-Received: by 2002:a17:90b:234b:: with SMTP id ms11mr786435pjb.110.1606262241891; Tue, 24 Nov 2020 15:57:21 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id z7sm138762pfr.140.2020.11.24.15.57.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 15:57:21 -0800 (PST) To: Brandon Long Cc: John Levine , IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> From: Michael Thomas Message-ID: Date: Tue, 24 Nov 2020 15:57:19 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4E8397D5A8C93E9FE8464FF0" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 23:57:24 -0000 This is a multi-part message in MIME format. --------------4E8397D5A8C93E9FE8464FF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/24/20 3:24 PM, Brandon Long wrote: > > On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas > wrote: > > > > Sorry, changing the auth-res to old-auth-res and dkim signing the > message would be completely sufficient, and far easier to understand > with a lot less bloat. All of this hand wringing about dozens of > message > manglers in the path before it get to the destination and not be > able to > figure out which auth-res was which seems wildly out of proportion > for > what the normal case is: 1 message mangler in the path before it > arrives > at the receiver's domain. Just like this message right here. > That's why > I asked how common that was, which was dismissed, but not answered. > > > Note that this was exactly what we started with, > X-Original-Authentication-Results > and with Google's implementation signing that with > X-Google-DKIM-Signature. > > Our version didn't just sign with DKIM-Signature because of the > reasons already stated in this > thread, that our understanding of how DKIM-Signature was being used > made it a poor choice. Sorry, I didn't see that. Pointer? > > Our experience also showed that more than one hop is quite common in > enterprise deployments, > and those are also the places where the most complexity arises.  > Others shared our experience > as well. That's more than one modifying intermediary in *separate* administrative domains? Within your own administrative domain there shouldn't be an issue of trust since you can trust your own servers auth-res and that they are not maliciously trying to forge an auth-res for better treatment. and course it's best to stop a bad message as soon as possible in the mail pipeline if for no other reason than why waste the resources. > > You say that your message had 1 mangler in the path, but really you > don't know that.  It is > likely that some people on this list are on enterprise accounts who > are behind mangling inbound > gateways (rewriting urls to go through safety checking hops is common, > for example).  Or maybe > they are on with University accounts using exchange but forward their > mail to a personal or department > gmail account. Well sure, I'm sure it can happen but is it common enough to worry about? And I'm still not convinced that figuring out who signed what and which auth-res it belonged to is in insurmountable problem. for one, there are received headers which better not be getting out of order to help correlate with the messages' path through intermediary verifiers too. Mike --------------4E8397D5A8C93E9FE8464FF0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/24/20 3:24 PM, Brandon Long wrote:

On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas <mike@mtcc.com> wrote:


Sorry, changing the auth-res to old-auth-res and dkim signing the
message would be completely sufficient, and far easier to understand
with a lot less bloat. All of this hand wringing about dozens of message
manglers in the path before it get to the destination and not be able to
figure out which auth-res was which seems wildly out of proportion for
what the normal case is: 1 message mangler in the path before it arrives
at the receiver's domain. Just like this message right here. That's why
I asked how common that was, which was dismissed, but not answered.

Note that this was exactly what we started with, X-Original-Authentication-Results 
and with Google's implementation signing that with X-Google-DKIM-Signature.

Our version didn't just sign with DKIM-Signature because of the reasons already stated in this
thread, that our understanding of how DKIM-Signature was being used made it a poor choice.


Sorry, I didn't see that. Pointer?


Our experience also showed that more than one hop is quite common in enterprise deployments,
and those are also the places where the most complexity arises.  Others shared our experience
as well.

That's more than one modifying intermediary in *separate* administrative domains? Within your own administrative domain there shouldn't be an issue of trust since you can trust your own servers auth-res and that they are not maliciously trying to forge an auth-res for better treatment. and course it's best to stop a bad message as soon as possible in the mail pipeline if for no other reason than why waste the resources.



You say that your message had 1 mangler in the path, but really you don't know that.  It is
likely that some people on this list are on enterprise accounts who are behind mangling inbound
gateways (rewriting urls to go through safety checking hops is common, for example).  Or maybe
they are on with University accounts using exchange but forward their mail to a personal or department
gmail account.


Well sure, I'm sure it can happen but is it common enough to worry about? And I'm still not convinced that figuring out who signed what and which auth-res it belonged to is in insurmountable problem. for one, there are received headers which better not be getting out of order to help correlate with the messages' path through intermediary verifiers too. 

Mike


--------------4E8397D5A8C93E9FE8464FF0-- From nobody Tue Nov 24 16:57:05 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8A03A0CD0 for ; Tue, 24 Nov 2020 16:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqgu1unK8zdd for ; Tue, 24 Nov 2020 16:57:02 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75A63A0CD3 for ; Tue, 24 Nov 2020 16:57:01 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id f18so460119ljg.9 for ; Tue, 24 Nov 2020 16:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ml2sI0nZhR/PZEQuWY9Z79m1GQ/kFkbfbEE0wqCr59k=; b=Mhm1m8SVOZVMS+T6Q4bmW9dh+i9GTosv9x/BDPeZsVgicgwXGYRrjIY8XKvT8DrBQM ruJlU/A+iTQS0S66L+H6jQu1eW+GFs7/ngFH49b7fkoFwOCXpAxx30m8fP8FCxvnLLjM ltjX4FdB7uqICSEVlpMNtxNkywc9/caUuF2WZK2UZR1gz8qFLv8UI75P3JLJ/P9HNV1H RYXecUdGM1airvAlkRAZ6tbNEwLN2h0n533O+jbk0mrj+lvYmAGe7aD7RdCT7UC2H9a3 wzuwjV/9D+IU9srTlbbEOi1Z9FEk0UqoYS2mFgvCbUVANZ6bKsRreghhncg+Pk8swR1v uHrw== 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=Ml2sI0nZhR/PZEQuWY9Z79m1GQ/kFkbfbEE0wqCr59k=; b=HRS875L3U+j0x4FRbW1qjDXtcTJWWtlLgNFj2enJLGdd/QfOgjwFtb2eyKQhJaxaIK zmaEfm8uBMZ0ivj88rC9j268NWkgq8Hi8rWJjZE/Nl1yyC616qHusV4g+umrDFwi8mOp zoVQi7SP7EoHK5tpMjDD+DX0/u+qmkukZuT3ZJA8h9tUcTxznyYiGwGyInTxas2ZSP9p qn0iNo/KU//wwr/hCr98lyvK9AAVuoheKrNURohhXkgH/uISBqM+7VX+5o5Hiy6VkP0M IQWdbn4Y8z//FncjAgqxcKY3x7XZ4xrrh8efLz1fQ3YuxReZrmi8xNl6ZqXH89gahm2t hJKg== X-Gm-Message-State: AOAM531V1/xWlQUSO12QCgXs6JDs8oTeYqTvKUJCBE74b1iULfcVcWtE bwoeiQsoIK4tPWNhXLHBgZkm7T4FYAX60dfFow06Pt4Vnw== X-Google-Smtp-Source: ABdhPJxCDPGjDaIgjdXIPyJ85PJz9pO/yskz2JF9UuZ6XXwpZpHYSkWErSroMInCpK3eLK70JA72RErIf06jFfys2+g= X-Received: by 2002:a2e:bc1e:: with SMTP id b30mr340626ljf.241.1606265819360; Tue, 24 Nov 2020 16:56:59 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> In-Reply-To: From: Brandon Long Date: Tue, 24 Nov 2020 16:56:46 -0800 Message-ID: To: Michael Thomas Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000094951105b4e3e735" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 00:57:04 -0000 --00000000000094951105b4e3e735 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas wrote: > > On 11/24/20 3:24 PM, Brandon Long wrote: > > > On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas wrote: > >> >> >> Sorry, changing the auth-res to old-auth-res and dkim signing the >> message would be completely sufficient, and far easier to understand >> with a lot less bloat. All of this hand wringing about dozens of message >> manglers in the path before it get to the destination and not be able to >> figure out which auth-res was which seems wildly out of proportion for >> what the normal case is: 1 message mangler in the path before it arrives >> at the receiver's domain. Just like this message right here. That's why >> I asked how common that was, which was dismissed, but not answered. >> > > Note that this was exactly what we started with, > X-Original-Authentication-Results > and with Google's implementation signing that with X-Google-DKIM-Signature. > > Our version didn't just sign with DKIM-Signature because of the reasons > already stated in this > thread, that our understanding of how DKIM-Signature was being used made > it a poor choice. > > > Sorry, I didn't see that. Pointer? > > > Our experience also showed that more than one hop is quite common in > enterprise deployments, > and those are also the places where the most complexity arises. Others > shared our experience > as well. > > That's more than one modifying intermediary in *separate* administrative > domains? Within your own administrative domain there shouldn't be an issue > of trust since you can trust your own servers auth-res and that they are > not maliciously trying to forge an auth-res for better treatment. and > course it's best to stop a bad message as soon as possible in the mail > pipeline if for no other reason than why waste the resources. > The administrative domain in practice tends to be per-vendor and multi-tenant. Ie, gsuite/gmail is on google.com, various third party anti-spam gateways also different, on-premise being also separate. Passing that trust between domains is one of the things that ARC can handle. O365 does a better job than Gmail at this, since there you can set up third parties to be called from within a particular customer more specifically (like an API), you can do this with GSuite or ad-hoc MTAs, but it tends to be more manual by chaining MTAs and there isn't as much of an auth mechanism to use. As for stopping bad messages early, there tends to be strong majority in favor of that for malware, less so for spam where people want access from their mailboxes to false positives. Some products do have separate administrative quarantine areas that can be checked by admins, but that's also an extra burden for IT... some of which want that burden, and some definitely don't. Some quarantines can be self-administered by users, but that's obviously a separate thing they have to check, whether that's worse than a spam folder, *shrug*. > You say that your message had 1 mangler in the path, but really you don't > know that. It is > likely that some people on this list are on enterprise accounts who are > behind mangling inbound > gateways (rewriting urls to go through safety checking hops is common, for > example). Or maybe > they are on with University accounts using exchange but forward their mail > to a personal or department > gmail account. > > > Well sure, I'm sure it can happen but is it common enough to worry about? > And I'm still not convinced that figuring out who signed what and which > auth-res it belonged to is in insurmountable problem. for one, there are > received headers which better not be getting out of order to help correlate > with the messages' path through intermediary verifiers too. > So, we do have some Received header walking code, and allow admins to set up the list of IPs that are considered "internal" (beyond private addresses)... but O365 uses public IPs internally and has a huge and unpublished ranges of them, making it nearly impossible for admins to maintain a list. Obviously we can all add code to handle Microsoft specially... and whichever other ones come up. Brandon --00000000000094951105b4e3e735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 24, 2020 at 3:57 PM Micha= el Thomas <mike@mtcc.com> wrote:=
=20 =20 =20


On 11/24/20 3:24 PM, Brandon Long wrote:
=20

On Tue, Nov 24, 2020 at 2:4= 9 PM Michael Thomas <mike@mtcc.com> wrote:


Sorry, changing the auth-res to old-auth-res and dkim signing the
message would be completely sufficient, and far easier to understand
with a lot less bloat. All of this hand wringing about dozens of message
manglers in the path before it get to the destination and not be able to
figure out which auth-res was which seems wildly out of proportion for
what the normal case is: 1 message mangler in the path before it arrives
at the receiver's domain. Just like this message right here= . That's why
I asked how common that was, which was dismissed, but not answered.

Note that this was exactly what we started with, X-Original-Authentication-Results=C2=A0
and with Google's implementation signing that with X-Google-DKIM-Signature.

Our version didn't just sign with DKIM-Signature because of the reasons already stated in this
thread, that our understanding of how DKIM-Signature was being used made it a poor choice.


Sorry, I didn't see that. Pointer?


Our experience also showed that more than one hop is quite common in enterprise deployments,
and those are also the places where the most complexity arises.=C2=A0 Others shared our experience
as well.

That's more than one modifying intermediary in *separate* administrative domains? Within your own administrative domain there shouldn't be an issue of trust since you can trust your own servers auth-res and that they are not maliciously trying to forge an auth-res for better treatment. and course it's best to stop a bad message as soon as possible in the mail pipeline if for no other reason than why waste the resources.

The administrative domain in practice tends to be per-vendor and multi-ten= ant.=C2=A0 Ie, gsuite/gmail is on google.com<= /a>, various third party anti-spam gateways also different, on-premise bein= g also separate.=C2=A0 Passing that trust between domains is one of the thi= ngs that ARC can handle.


--00000000000094951105b4e3e735-- From nobody Tue Nov 24 17:07:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AE33A0D86 for ; Tue, 24 Nov 2020 17:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrJEFpWCieZD for ; Tue, 24 Nov 2020 17:07:03 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 30B293A0D7A for ; Tue, 24 Nov 2020 17:07:03 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id r5so336575vsp.7 for ; Tue, 24 Nov 2020 17:07:03 -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=XH1RUF986jvahEoOzml/gpi3ZAeNyDYGzquDaElcebw=; b=M7Vkbfp31wCNXLdnaKzFQIkHQD3Srf7bbtsWe6DPWn3IH7MpbDVlOX5cl7aeKiRqKT L1JGZ5KQHXERxe1KYrOJdKsfpyx0rvhxA80ENO02EjttqIGClGtTH1upn1uXg5qT44DL fbpcPS5a2S8POd0zUimO5U0u7UmjRQmciTFDd80/+CZDEyOSwZY8kKmPmWTmdSvil0Rj WGiezLa8cF11FQEUz3V+renQOqlGIPGjWynv8UgBc0zZkBfQ6550mkhSXOQsrXm2tkiu 08L7YvUTG2D1qrRX69uy4Oi6N2iUtywnLBOax/x9aAR7L3F9SK5HAbY6t9ytJ35j7Iif Z4Rw== 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=XH1RUF986jvahEoOzml/gpi3ZAeNyDYGzquDaElcebw=; b=d0Gn15NiSq7hAP9nYvIf3bMVWN//jV87I5YLnsAP+l/CB+5wi1+ze2jK+sis87Wms9 LXh+WPBY+66g7O/wK5+pfXkbOqHMhnp0mTTV8TtX+sQ+0aQ78iVfm0oPAFq5hp4CyDNr qVjgllnlk+J8ycYRRrvKPyYhGB0zYSanpHvMwzHM8TzOtXaTmSXW83GihJaiOWITAEdO p69Hh26okkYh92KFllUT11VskSpa2KXxj+xI18wlNWV2mZIwRlI5fvw5f8JUrRFe2iwL elWl8JHUcmqwm7vtKsDkE1BFqr39qePaQ8oxBSnHkGXVDIwGimYBcc4ecPpECSurdYo3 SOBQ== X-Gm-Message-State: AOAM533AVIxwEISZhZmvOTia1Vy4uXktnfVpAftetagJf4axIrtSj/XT mYWbklvUCQdQnB8k8orvupmj4XZRJFRP3kkW8g4Hso+J X-Google-Smtp-Source: ABdhPJwd1HvODvO3Fw5DDKBSS1NbO7SJkvD5YPGhV1skW/T96VfpiRx8DJ789AxL1YvbmKmA/srU5b4/jfPaMkwgcYA= X-Received: by 2002:a67:783:: with SMTP id 125mr550536vsh.15.1606266422211; Tue, 24 Nov 2020 17:07:02 -0800 (PST) MIME-Version: 1.0 References: <20201123213846.EB14127C8160@ary.qy> <7ab9e796-0385-5206-d202-97522802393b@tana.it> In-Reply-To: <7ab9e796-0385-5206-d202-97522802393b@tana.it> From: "Murray S. Kucherawy" Date: Tue, 24 Nov 2020 17:06:49 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000082c94805b4e40b75" Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 01:07:04 -0000 --00000000000082c94805b4e40b75 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely wrote: > The PSL is the result of a community-maintained effort. They do not > follow > intricate naming restrictions that ccTLDs might theorize, but actively > track > subdomains as they become visible/ noticed. It is remarkably good. > I'm curious as to whether this is the consensus opinion of the PSL. It's my impression that it is not, given the arguments that supported the creation of the DBOUND working group in the first place, for instance. The citations you made here appear to support that notion as well. -MSK --00000000000082c94805b4e40b75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The PSL is the result of a community-maintained effort.=C2=A0= They do not follow
intricate naming restrictions that ccTLDs might theorize, but actively trac= k
subdomains as they become visible/ noticed.=C2=A0 It is remarkably good.

I'm curious as to whether this is the= consensus opinion of the PSL.=C2=A0 It's my impression that it is not,= given the arguments that supported the creation of the DBOUND working grou= p in the first place, for instance.

The citations= you made here appear to support that notion as well.

<= div>-MSK
--00000000000082c94805b4e40b75-- From nobody Tue Nov 24 17:27:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA413A03EC for ; Tue, 24 Nov 2020 17:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 1l0f_H-_o87l for ; Tue, 24 Nov 2020 17:27:34 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9C83A03F1 for ; Tue, 24 Nov 2020 17:27:33 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id w187so790434pfd.5 for ; Tue, 24 Nov 2020 17:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Z5pYGJnOa5E+sGRt3i61k4TCYsbN+a4LM0bPH1nGqNU=; b=ogsckW8fv/BFAixfp76l9Rj/82YXQtDjf06/dewriR5LwARUOvbMxf1fRSUZW2J610 nyPhQXRB0w4xN/cvAke4eGD6Uq7ur6kUzrgJCBuX7mJ7M5HdLkvd9macW0v8oT50lGAg +SuepNP2gkbECib9bDasZ/jlGeQhnqQtwei3DW7uDoi07WVysC5XuajakY+l8Ou+fKcV sttgVrsXbJZGBs1Z/CCZAtpFi906PVe3XuzU63bc+5IWekFeoicUlRZ5hMvAT2WgGaKr NUG/FwjK/dQtfIvJT2mg9a3bHe3vttNb77sCWcugCnC/QTMh0YIt60rVqO2BSLRoghvy /T6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Z5pYGJnOa5E+sGRt3i61k4TCYsbN+a4LM0bPH1nGqNU=; b=b2sV4p8cXgrewXf92ISFlZvYCpnMOO//pkfBPn2jt+Hth3bJuaWs3woQ4FvOARvB9q qdzYOQSpsrld7ZKHmFq9tCJUaDfD+/vBkhO8svSfBGX6Gbz+B6N/oSsLGuz39tdD4Gv1 ZPjbCcgYaGyFCuw+hrcrWmmr4ggRC9aWzimvbcIOB8KeIJEWt12nk4GqYmR7t8WXUsYx sul5PSYxV1H7N6jaOHKEBeMBb//V2MoLzJeZViJC4GjWwGDZttR1CDwNPYvsYudDbZLV O9v8aOz7JdMgMkcN+5Z1N+u8En42NeTj5ZtUdNJC8VKPn7QFsxjiYXVxzeNc5ZTZwGE4 mW7w== X-Gm-Message-State: AOAM533ndt3GCZTWXiLT1DbDqTTFU9HABbIeF9s7dN/aSzqIxHOfVBWf CXMJJM1KRyEbQs979l0/cmNYgPYj2bt/yQ== X-Google-Smtp-Source: ABdhPJzJaygIIFFRXkWbWirePk7LlCNIDqkmgDbDb/MmjV4sj4quV6tFULQiWB9s2EiC9VJUDHkrIQ== X-Received: by 2002:a63:3d8c:: with SMTP id k134mr1019710pga.53.1606267652841; Tue, 24 Nov 2020 17:27:32 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id na6sm437304pjb.12.2020.11.24.17.27.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Nov 2020 17:27:32 -0800 (PST) To: Brandon Long Cc: John Levine , IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> From: Michael Thomas Message-ID: <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> Date: Tue, 24 Nov 2020 17:27:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B4B77474E010D665715C24D7" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 01:27:36 -0000 This is a multi-part message in MIME format. --------------B4B77474E010D665715C24D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/24/20 4:56 PM, Brandon Long wrote: > > > On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas > wrote: > > >> Our experience also showed that more than one hop is quite common >> in enterprise deployments, >> and those are also the places where the most complexity arises.  >> Others shared our experience >> as well. > > That's more than one modifying intermediary in *separate* > administrative domains? Within your own administrative domain > there shouldn't be an issue of trust since you can trust your own > servers auth-res and that they are not maliciously trying to forge > an auth-res for better treatment. and course it's best to stop a > bad message as soon as possible in the mail pipeline if for no > other reason than why waste the resources. > > The administrative domain in practice tends to be per-vendor and > multi-tenant.  Ie, gsuite/gmail is on google.com , > various third party anti-spam gateways also different, on-premise > being also separate.  Passing that trust between domains is one of the > things that ARC can handle. One of the failings of many, many ietf documents is to not tell the story of what exactly the problem is and why the protocol is needed. It's really frustrating to the reader to not have the context of endless wg list discussions distilled so that an outsider can understand the design tradeoffs. I still don't understand why a DKIM signature was a "poor choice". That's especially true when something is an experiment that assumedly has yes/no endpoint. So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it would run into problems? I haven't put up a DMARC policy, but if I did I might run into issues with false positives? Like I said, I'm trying to get my head around what the actual problems are, and this is coming from a person who stressed mightily from the very beginning about the mailing list problem. > > Well sure, I'm sure it can happen but is it common enough to worry > about? And I'm still not convinced that figuring out who signed > what and which auth-res it belonged to is in insurmountable > problem. for one, there are received headers which better not be > getting out of order to help correlate with the messages' path > through intermediary verifiers too. > > So, we do have some Received header walking code, and allow admins to > set up the list of IPs that are considered "internal" (beyond private > addresses)... but O365 uses public IPs internally and > has a huge and unpublished ranges of them, making it nearly impossible > for admins to maintain a list.  Obviously we can all add code to > handle Microsoft specially... and whichever other ones come up. > But can't you trust the received headers once you have possession of the message within your domain? I'm sorry if I'm being dense here but received headers are definitely ordered and if you loan out a message to be processed by a different domain and they aren't trustworthy, that's the least of your problems. That's part of the overall problem though: it's really hard to understand what the problem here actually is. Explain it like I'm five :) Mike --------------B4B77474E010D665715C24D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/24/20 4:56 PM, Brandon Long wrote:


On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <mike@mtcc.com> wrote:

Our experience also showed that more than one hop is quite common in enterprise deployments,
and those are also the places where the most complexity arises.  Others shared our experience
as well.

That's more than one modifying intermediary in *separate* administrative domains? Within your own administrative domain there shouldn't be an issue of trust since you can trust your own servers auth-res and that they are not maliciously trying to forge an auth-res for better treatment. and course it's best to stop a bad message as soon as possible in the mail pipeline if for no other reason than why waste the resources.

The administrative domain in practice tends to be per-vendor and multi-tenant.  Ie, gsuite/gmail is on google.com, various third party anti-spam gateways also different, on-premise being also separate.  Passing that trust between domains is one of the things that ARC can handle.

One of the failings of many, many ietf documents is to not tell the story of what exactly the problem is and why the protocol is needed. It's really frustrating to the reader to not have the context of endless wg list discussions distilled so that an outsider can understand the design tradeoffs. I still don't understand why a DKIM signature was a "poor choice". That's especially true when something is an experiment that assumedly has yes/no endpoint.

So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it would run into problems? I haven't put up a DMARC policy, but if I did I might run into issues with false positives? Like I said, I'm trying to get my head around what the actual problems are, and this is coming from a person who stressed mightily from the very beginning about the mailing list problem.



Well sure, I'm sure it can happen but is it common enough to worry about? And I'm still not convinced that figuring out who signed what and which auth-res it belonged to is in insurmountable problem. for one, there are received headers which better not be getting out of order to help correlate with the messages' path through intermediary verifiers too. 

So, we do have some Received header walking code, and allow admins to set up the list of IPs that are considered "internal" (beyond private addresses)... but O365 uses public IPs internally and
has a huge and unpublished ranges of them, making it nearly impossible for admins to maintain a list.  Obviously we can all add code to handle Microsoft specially... and whichever other ones come up.


But can't you trust the received headers once you have possession of the message within your domain? I'm sorry if I'm being dense here but received headers are definitely ordered and if you loan out a message to be processed by a different domain and they aren't trustworthy, that's the least of your problems. That's part of the overall problem though: it's really hard to understand what the problem here actually is. Explain it like I'm five :)

Mike

--------------B4B77474E010D665715C24D7-- From nobody Tue Nov 24 17:52:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779E33A0B5D for ; Tue, 24 Nov 2020 17:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=MYRUgMTz; dkim=pass (2048-bit key) header.d=taugh.com header.b=hbeCbixL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk-NAvB9s6fK for ; Tue, 24 Nov 2020 17:52:47 -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 B8B173A0B5B for ; Tue, 24 Nov 2020 17:52:46 -0800 (PST) Received: (qmail 29876 invoked from network); 25 Nov 2020 01:52:42 -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:original-authentication-results; s=74b1.5fbdb8ea.k2011; i=johnl-iecc.com@submit.iecc.com; bh=1alijATxsZwODJqZQ6PXUr/HSr+94xPseIDBmnv/70I=; b=MYRUgMTz2cdIFjKpS0UIk1JpGwHRV+Ko2FTeR0UI6Zv38NtbcwvdPOmpmGQcRYQKR/9BMFLHHwiCMyHFUbqDoW4pOJIH4cK/24BH1/F+2hv2EPWfQHWB+gd/wzAIuONtbgaAjjmJs1SrQPYxqcsn+UPDhoW7kgnJa/CHlop1ERuhGefJr+fvE534Zi+qMd0vyetkltPHv1rX7LXHUGBLj3/hrV15tAGMKQw6o8r1FKOtjWvX3b+z2f9QsRPDzGWGOipIjiiS+zZVQnqcQrX+8GAnh5EFdmcpzQx825K6XpiQW8Fg6qQt0RmJZim7IcHKJbt7kPFORzfZU5IHqCDxDQ== 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:original-authentication-results; s=74b1.5fbdb8ea.k2011; olt=johnl-iecc.com@submit.iecc.com; bh=1alijATxsZwODJqZQ6PXUr/HSr+94xPseIDBmnv/70I=; b=hbeCbixLuDQztZgldEPUuMhxqkZ5tLE5RbmH8TJpUPzUGGel5vTFqnekxqJV6F7SqniUNsO8ipCZaYTCq152b81PsWJcctTBlKnD1wRniVRI8WF2ovC1+4+RzHpipjXIDTyiX+j4yssXfN55SzX68Nyq7DY6Xik7P9QXmPipeh2itiblRw+s885Cc86KgaTzkpGosxgDJtcJ2LLKecN+uwE3pnk/n6W5Zx226OKWCw5CgEkYCmsmDb9VsBDz+pI1xW2zKM2RFMC2xUKbCCDTY7RMEQZUObtytAyCufVdyWVm5zcYyNk6etMBsHqVfvB0rEGtGvZZi7tcgLj+YO0bxg== Original-Authentication-Results: iecc.com; spf=pass spf.mailfrom=no-reply@sharepointonline.com spf.helo=APC01-SG2-obe.outbound.protection.outlook.com smtp.remote-ip="40.107.131.117"; dkim=pass header.d=spoapaceop.onmicrosoft.com header.s=selector1-spoapaceop-onmicrosoft-com header.a=rsa-sha256 header.b="wrH3TGY5"; dkim=pass header.d=sharepointonline.com header.s=selector1 header.a=rsa-sha256 header.b="nk5sNj5U"; dmarc=pass header.from=sharepointonline.com (p=reject, pct=100) Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 25 Nov 2020 01:52:41 -0000 Date: 24 Nov 2020 20:52:41 -0500 Message-ID: <1bd5da1d-ce8-d0b-9e49-67c3b7df8db@taugh.com> From: "John R Levine" To: "Michael Thomas" Cc: "IETF DMARC WG" In-Reply-To: References: <20201124020453.AFDC027CE5C8@ary.qy> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1063395498-1606269161=:35191" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 01:52:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1063395498-1606269161=:35191 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 24 Nov 2020, Michael Thomas wrote: >> Our experience also showed that more than one hop is quite common in >> enterprise deployments, and those are also the places where the most >> complexity arises. Others shared our experience as well. > > That's more than one modifying intermediary in *separate* administrative > domains? Microsoft currently appears to add an ARC seal for everything that transits their hosted mail system, no mailing lists or whatever involved. I think I may have seen stuff from them with two seals. Here's the headers of something from MS that I picked out of the spamtrap. It's a fake Sharepoint message, and all of the SPF and DMARC checks failed, which of course makes one wonder why they sent it to me at all, but there's plenty of ARC-age there in case I want to do the filtering they didn't. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ================================================================ Return-Path: Received: (qmail 53861 invoked from network); 24 Nov 2020 23:04:40 -0000 Authentication-Results: iecc.com; spf=pass spf.mailfrom=no-reply@sharepointonline.com spf.helo=APC01-SG2-obe.outbound.protection.outlook.com smtp.remote-ip="40.107.131.117"; dkim=pass header.d=spoapaceop.onmicrosoft.com header.s=selector1-spoapaceop-onmicrosoft-com header.a=rsa-sha256 header.b="wrH3TGY5"; dkim=pass header.d=sharepointonline.com header.s=selector1 header.a=rsa-sha256 header.b="nk5sNj5U"; dmarc=pass header.from=sharepointonline.com (p=reject, pct=100) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O1UbAqs382laXh6I4AhWTigOPfRFerozKTibyzMawpdnyHHn4iHRW4u6+HZ1KlqNZHfhco5U9KgrgsCzP1VvHaD686U2omsloPRlsuR8+8UQPucSS/qtgYrv+5vDfF8cNqvnyfRvS/kOy3bAzr4vVPfhtgPbQ2sn+L5wMjo+w8kV+AZ6O6KedBqZSrX6Mt6OpsqFT1l3sTybAuOHlrmjo++cp2Dn0atKYnqDAAu1OIOSW6/dnc0u6fwbVoURavwPtWVhnK2/1MjHnlJO6XZTQeQtvvU82RSaaEikGgrQhsAO41Uz2HJPMt3S6e4RAWYS1n995BOeosRNjLcKxFNx2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=; b=WpRrZ43L7klrMFI7e2Xg+LjrKHEocOU52J2YWHSirU4EX4J1yqrqMWT1MqGQze8tEbPEtTSa8r2ZM6ff235Mch1QlpbmQt2HtmGClJGe+ZYkRTf5zTmGyLxSokIrNfFaAHtztaqnct0XlLgMCm3Uu5zxqzaIfh9Wi2vMlLpX/mHRx+W6XOw1+Frb1msMbyf4LbjtjFWCv1+KBpACSaxC9vWIc70+P7stlVkuGyxM9rE+oO7jodaUCAHvkBQtASZ+PVeGe/gxxP3Pv26WnM31HDxVKGkn6mVsCkhkqW6L/4O2/SBCjtyM0gUoatMprsAOTian7sDbnQYtzTzTP2f0wA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender ip is 13.75.93.237) smtp.rcpttodomain=repmark.com smtp.mailfrom=sharepointonline.com; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=sharepointonline.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spoapaceop.onmicrosoft.com; s=selector1-spoapaceop-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=; b=wrH3TGY50Qitk5Kc82kUaGKKbBcgore8XTTR+QrqeSmGIEyalPhCQ+HoQXN6Euuhzc0EM9GOEYvMk2I5wYiZZ9eihJ4UuBARo1EHK7zYDlda2EAql0V+/5oWR0jHFvYBmH+QUCQ5SJ+R2IxO5x9yK0fXUJtpTPmZgYpvwH+AIA4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharepointonline.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=; b=nk5sNj5UH1ZrUT387iGCYgiYCAZspugCdueY19ZRfrz+hs1F/ltpSFIUvvB/PZ8QRP1H4qGujpRuLnD3PlNLPn1Qak0pFp13mwip2g5eV8ObJxBw1d11zLM7PM090Z6Ri2NrKK241iAgmOl5gZrcrLgur7F2ckhtMYJsSkCKiUEDOfHSns3JN/AHVXm7C46BOMrQbJbhWqwTojkasOgVEGnAZbEcUbVT13mAmKvB1t7BL3wCk56q37jYm09vuSzvhja3+oegQ/iaLsurvCDzJkW2WvmRt2+Y+LYaG4HYboUQ7W/P6pDJCPpMDZzHp9aRwrHGamKgpdi/0lrXwz9G4w== X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 13.75.93.237) smtp.mailfrom=sharepointonline.com; repmark.com; dkim=none (message not signed) header.d=none;repmark.com; dmarc=fail action=oreject header.from=sharepointonline.com; Date: Tue, 24 Nov 2020 23:04:25 +0000 Subject: Ashley Barker shared "I'M 28 Years Horny & Sexy" with you. Message-Id: Sender: Ashley Barker To: jamaicadiscountvacationpackages@repmark.com, wevmaster@marshfieldtravel.com, tcwall@hiwaay.net, rrbrown@ptdprolog.net, members@onlinecityguide.com, david_burnstein@lecg.com, aimee_smith@dell.com, mturne@tivoli.com, bassman7@earthlink.net, alfacors@nectar.com, tisom@gcm.com, tmano@ais.net, tamara@tamarasmith.com, uu-reques@iecc.com, nar@net.com, transc@worldaccess.com, randihanki@yahoo.com, jc_smith@dell.com, kstephens@supnet.com, tamerasmith@sprintmail.com, sawye@sovam.com, tempest@storm.net, smithep@hotmail.com, smithg2@hotmail.com, ssmithley@docsolinc.com, mistersmith@free-online.co.uk, brettataylor@comcast.net, wbatterton@steptoe.com, jlup-lupini123@gmx.com, princehopkins@yahoo.com, fiorentini@aweddinginitaly.com, waynenewton@mailcity.com, cdwcdw321@gmail.com, bforbes@accessenter.com, chickmagnets2000@yahoo.com, mhusak@jup.com, waldmanb@cooley.com, krsmith@rocketmail.com, emcsquare86@gmail.com, iggy@wvadventures.net, smithdw@hotmail.com, wmesar@tofu.boston.sgi.com, garysmith@adelphia.net, theheart@tampabay.rr.com, kp7673@icloud.com, smusterm@bellsouth.net, wrweichel@ccgate.dp.beckman.com, mjsmith98@hotmail.com, ric@evil.com, smithbro@earthlink.net Reply-To: 16k4051097@hce.edu.vn X-Crid: =?us-ascii?q?cdea909f-803b-0000-6144-77c91ea01270-83b10cce-60d1-47f3-896c-?= =?us-ascii?q?5458d1ec51d2-7365a940-ab77-4afa-ae95-7cfbc27db0a7?= X-Tnid: 4da64f37-4e7a-43e8-b13d-018f28080f20 X-Usid: 73a83b38-1250-4360-859a-54b192a55f6a Return-Path: no-reply@sharepointonline.com Cc: Ashley Barker <16k4051097@hce.edu.vn> From: Ashley Barker MIME-Version: 1.0 Content-Type: multipart/related; boundary="=-wIBw8BF64FqYMCUfyfbuzQ=="; type="text/html" X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 823ab865-eff7-42d9-14cf-08d890cd4a4b X-MS-TrafficTypeDiagnostic: KL1PR03MB4837: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:353; X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zuiAupEkmAdpxoBPZ4hiKqXGasyOmchAbttQ6nMViz+86m0Ro4qh1NSjGRNRCfXo1yq8vINCCfSw0+0XDgf/LrZE4oQJqxNvSAnjlxRM0mV20srf4ezVt9j2ChmLZIuAF3vDkFcm+23zDqFXjk1vib+XBGebYmuHqab/0UOChGurgcxtXgJx1zX1Ui/ycGUvTiZt6UYItmU/+wwdmlRytXCHMBDox1xBLUxdjaRA4bzX7cvVkV6PK41AgeQZIgU7Ex4ObLQjNvKHDpbWuwgiQuRtt1r5LqKOoJS03fhgtgc7rn5o3J19RmFkmNl96IlcQIs4wZr+hU0ANcZ/vMMz7BMKO0ExIx5f/Ke4jnEih9mrd1FCc3bDsY4MuwD/yi/lfgbV1ugvGvkEC+GJ22etdTaEHWhBd0BNf+bOlJ5DC4kd+QUvZDPOXJLog2A+9ipyZrQA7smlEKhk1m7jhlPAvCsT48FVYWwfxxAJo2lF+knl+8u8+/hlcJEZ7EZf99IdWD0iBTWTpjJ0r8WU+OB6gWB0gIpJW0LD3e3C/Ih5cIuYmMwxL7dy1dwJ+weh6omoPU5Mdfj445iBx84fO78eoA== X-Forefront-Antispam-Report: CIP:13.75.93.237;CTRY:HK;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:[10.218.0.17];PTR:InfoDomainNonexistent;CAT:NONE;SFS:(6049001)(7916004)(346002)(39830400003)(136003)(396003)(376002)(7846003)(166002)(19627405001)(2906002)(356005)(921005)(6486002)(4326008)(33716001)(81166007)(76236003)(4186021)(33964004)(26005)(82310400003)(336012)(7406005)(8936002)(32650700002)(8676002)(70206006)(966005)(498600001)(11855715004)(7416002)(7366002)(55885007)(9686003)(70586007)(66576008)(36736006)(316002)(5660300002)(16576012)(956004)(86362001)(9833003)(9813001)(44636011)(32350700004);DIR:OUT;SFP:1102; X-OriginatorOrg: spoapaceop.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2020 23:04:26.1465 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 823ab865-eff7-42d9-14cf-08d890cd4a4b X-MS-Exchange-CrossTenant-Id: 3c412e91-e450-440a-8d6a-3245b726f1e3 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3c412e91-e450-440a-8d6a-3245b726f1e3;Ip=[13.75.93.237];Helo=[[10.218.0.17]] X-MS-Exchange-CrossTenant-AuthSource: HK2APC01FT007.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR03MB4837 --0-1063395498-1606269161=:35191-- From nobody Tue Nov 24 18:03:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13D53A0BBC for ; Tue, 24 Nov 2020 18:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=TnmoadZw; dkim=pass (2048-bit key) header.d=taugh.com header.b=jZdU/6fc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qzr4JitREujW for ; Tue, 24 Nov 2020 18:03:50 -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 9E2B83A0BB8 for ; Tue, 24 Nov 2020 18:03:50 -0800 (PST) Received: (qmail 31873 invoked from network); 25 Nov 2020 02:03:48 -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:cleverness; s=7c7c.5fbdbb84.k2011; bh=heVKr3rES7tAw1D67oyZw4/kwOHLFDE0qcNnajaEU08=; b=TnmoadZwO6EWzoHlF5j+hb5WIBUfKLd7GV8XW4Nw32im0gSI2TM6i9QRW79K6/CM6hgxDufVskleRHhc8vb3ubi0om/aoAKnY7URNkINyr2weO3qEYA6Boz2I5mW5fVFilGaTNHdA/vwafjAlbA0IbUQ1o1hckhxDSmmXSP+hoaGychCoWiHmLH0HJ7zrsXFEUEW3S3Nu1agfceV+yFEKTRHGSj5syAPhMgE8luYlLMjmXM46rdEOAEG7ZP0GgwnlnGKXBp5bwhj+IFRdASuTfU46elv+iSmYjQLRPvkGRIy2MGm9+buZt15yGRex77eindQrwIHqB35Ziwh9nJyMQ== 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:cleverness; s=7c7c.5fbdbb84.k2011; bh=heVKr3rES7tAw1D67oyZw4/kwOHLFDE0qcNnajaEU08=; b=jZdU/6fcvFbWsUkZQc/FwDJjup3b5NdHBC2ts+EpO0Wr6jZBTxs+F1WjTrClHLbL/RxFtPonWWmJGZxtjNSswP9L7fbg5HW3Xe22Jm9lmU0dYNFPmtB8FISLtnTrSArU866thLPhlw94IWyjA2ESdvvpqN01Z75Moox85X7RFVs09BRCWpdVUKv8k/bZQldkAV15NFS6bThtfh7RQnIWhZiz0AMKI8R3HTGe+xfzHdD8DuegjDMr06oR5rlmdQd4TnIvymNWC23ebArykxNzhEoT1sKXYZ2DtVN+c4fylysYS0dfXFZFNZoWz5HZHAOOtuZhja0yP0VcUR+4ayY/NA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Nov 2020 02:03:47 -0000 Received: by ary.qy (Postfix, from userid 501) id 3835A27EBBBC; Tue, 24 Nov 2020 21:03:47 -0500 (EST) Date: 24 Nov 2020 21:03:47 -0500 Message-Id: <20201125020347.3835A27EBBBC@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 02:03:53 -0000 In article you write: >-=-=-=-=-=- > >On Tue, Nov 24, 2020 at 10:47 AM Alessandro Vesely wrote: > >> The PSL is the result of a community-maintained effort. ... >I'm curious as to whether this is the consensus opinion of the PSL. It's >my impression that it is not, given the arguments that supported the >creation of the DBOUND working group in the first place, for instance. The PSL lives at github and has three committers. https://github.com/publicsuffix Anyone can send in a pull request and they have a process to decide what to accept. I agree they do a pretty good job but it is a tiny project run by a few volunteers. They do not go looking for changes beyond tracking what's in the root. Keep in mind that the purpose of the PSL is to manage cross-site cookies in web browsers. If it works for anything else, it's a coincidence. From nobody Tue Nov 24 18:48:48 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8B3A0DD5 for ; Tue, 24 Nov 2020 18:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 5tj0MxnK9bmx for ; Tue, 24 Nov 2020 18:48:45 -0800 (PST) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 5DF583A0DD4 for ; Tue, 24 Nov 2020 18:48:45 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RSEEL45X7K00D6TO@mauve.mrochek.com> for dmarc@ietf.org; Tue, 24 Nov 2020 18:45:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1606272302; bh=heiy1l7U/EBDbCe10XyV2iEOqOYdmZKYaR7mSsD1GsI=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=N0et3/GUEUNmLBiG1NqWm6hxbaNW9vHoeVTBUNa/WANmrh2iQOhNH7v5wZ2I/f+PS Y66KQDYYvfLZJXlFJF1kD8Gc/uEu/Qg1sdKHn0BwzfFm82i518IlAgo2vDkRdK4WwQ TY7Fe8xEvqYvX0x6q9edZfAbzJUE6oz7ZLxROHT0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RSDRSDRS8G0055SH@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Tue, 24 Nov 2020 18:44:59 -0800 (PST) From: ned+dmarc@mrochek.com Cc: dmarc@ietf.org, vesely@tana.it Message-id: <01RSEEL1VCRS0055SH@mauve.mrochek.com> Date: Tue, 24 Nov 2020 18:23:11 -0800 (PST) In-reply-to: "Your message dated Tue, 24 Nov 2020 12:03:51 -0500" <20201124170351.C430227DFEBF@ary.qy> References: <20201124170351.C430227DFEBF@ary.qy> To: John Levine Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 02:48:47 -0000 > In article you write: > >> One of the points of the tree walk is to get rid of the PSL processing. > > > > The PSL processing is a local lookup on an in-memory suffix tree. How is it a > > progress to replace it with a tree walk? A PSL search is lightning faster than > > even a single DNS lookup, isn't it? We added PSL support for other reasons some time back. FWIW, there were some intricacies I didn't like in the suffix tree approach. And since memory use really isn't a consideration for something this small, I opted for multiple lookups in a hash table instead. We have our own hash table code and loadable format, but there are compile-to-loadable-format tools out there if you don't want to roll your own. > You have to download a copy of the PSL, Hopefully you're doing that in the background... > read it into your program, and > parse it into some internal form. The PSL is over 200K of text and > 13,000 lines, so while it's not a large file, it's not zero either. Our implementation processes a bunch of text files from various sources, of which the PSL is less than 5% of the total size, into our loadable format. I just checked, and it takes a litle over 2 CPU seconds to run the program. On an 333Mhz Alpha. I really don't think this is a concern. > If you're lucky you can amortize your PSL parsing across multiple > DMARC checks, but your DNS cache amortizes DNS lookups across mutiple > checke, too. Parse only happens when one of the input files changes. Why would you implement it any other way? > The DNS approach has the advantage that you don't have to depend on a > third party's text file updated at unknown intervals, and also makes > it easier to deal with what I've called the Holy Roman Empire problem. So you download and check every week or whatever. Still not seeing a problem. Finally, there's the HRE issue. Which I guess could be a problem. But so can DNS usage, which is subject to what I'll now call the fiefdom problem, where you're required to use a DNS service operated by someone else in your org and they are ... problematic. Of course DNS use is unavoidable. Even so, the fiefdom problem has led to requests to minimize DNS usage by any means possible. The HRE problem remains theoretical for us at least. Ned From nobody Tue Nov 24 19:27:16 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5F93A0E6B for ; Tue, 24 Nov 2020 19:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEk9xJJ0MaFQ for ; Tue, 24 Nov 2020 19:27:12 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 9CBAD3A0E54 for ; Tue, 24 Nov 2020 19:27:12 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id l22so481005vsa.4 for ; Tue, 24 Nov 2020 19:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qbXXO2FDgwjPLBdufR4wIswDdXsONQZapWfb+CvxZV4=; b=a8Ypo6L+lOVM9HIef/Vs6J3IdKaFS47AeSm1aDQFf3KtsP4NH0vXgUz82ffMi/+EgL IxL/VrnCu68ZQSpW5J13058K/73DGRKEs5NHdxSLOYsy+EYHrDzSi2wFpVHQ7xspvDWM LllGxw5Kbqb7WL5hH3YITnXSk3SlzsoQVoBDKqvVebcAFdeIhgw5eidzSIymCy9wWJ4v 9aCNowPq968ksbNlYFgf8TehGf3RZFx0ImJ8MpAAiQg3lKvB1esaPbuR0jSiBb5JEBr/ kxwKMAiD9/9Pz5D+whbZMEJ9dUAS32nf7lhaB8okEuJZ95T0KqdIYHJ5Y1/qzWfmb6o7 mgAg== 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=qbXXO2FDgwjPLBdufR4wIswDdXsONQZapWfb+CvxZV4=; b=Bzjn/HNbT2csGrtBlo00K+3s1JBzhflDmcVv6BPfRs+AeNqzGlrVHsUhx4ZQeX1Ey+ Sd1ZkDFUCtMnO5ZgCfDzXZ4HCEkSNQoI96VbzJ//WKS/i7Sd8Z5m1AhIP/XAVmpEj5To S61Vz3dFjvg0aI10S3tDrYSD7nrvd6G+eeiCKtOPWiSEMkECluf2YYsCrUeeIJZlZTLn dCsGZFbtxiL79xVVQ6a5ZRyWM+P9cIepOubOjEF4tch1ce1u94QI5M6EgBBwgv9IDHiR EPTbDJAVjgKSowstBwwuCMfEidpZBd+x5fGSEGGR9V7YwmDSHSxZtSfEl64frxWTh6Pu nZXQ== X-Gm-Message-State: AOAM5313GqjnrRRFknD3ilvpWyxTqug2DWal/Fb12kluFc9Xog40FRJ4 09A/gRgc1cb4QHu3EOoZ0V7W+KUTRUPZhjjIotw= X-Google-Smtp-Source: ABdhPJxliinAWmudK71OW2hq4T+lxHgDLRnIJavnKG6/feGqO9VdAZDT/N6l8qwefWhZD2CelkYMO5Swsj97VKcteqM= X-Received: by 2002:a67:2084:: with SMTP id g126mr805785vsg.42.1606274830747; Tue, 24 Nov 2020 19:27:10 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> In-Reply-To: From: Douglas Foster Date: Tue, 24 Nov 2020 22:27:00 -0500 Message-ID: To: Michael Thomas , dmarc@ietf.org Content-Type: multipart/alternative; boundary="000000000000b2ccd805b4e600a8" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 03:27:15 -0000 --000000000000b2ccd805b4e600a8 Content-Type: text/plain; charset="UTF-8" Michael, I think the purpose is stated well enough: Mailing lists want to keep adding their content to messages, without being blocked by recipients. This means that they have to provide recipients with enough information for them to accept the forwarded content. Google and Microsoft seem to be on-board with this project, so it seems pretty successful already. This train is not easily stopped. As to the technical pieces: - Unvalidated data, which includes the entire Received header chain, is only useful for blacklisting. A spammer will fabricate any header content that he thinks will get his garbage through your spam filter. - The recipient filter needs to be convinced that the submitting MTA is not lying and that the submitting MTA has not been duped. Digital signatures are the only tool we have for validating forwarded content. Since the goal is favorable treatment, digital signatures are necessary. - Interlocking signatures are needed to get around the problem of DKIM signatures being damaged by mid-stream content changes. As John said early on, this all works in conjunction with private knowledge that decides who you believe is not lying. Google and Microsoft have that kind of data. In my opinion, ARC does leave a lot of unanswered questions about how you use the data that ARC provides. Again, the big organizations have the brain power at their disposal to figure that out for themselves, later. It seems like a lot of software logic to create an ARC set, even more code to parse it, and even more code to use it intelligently. This is a big problem if you are trying to write the code yourself, but a small problem if you have a big programming organization. The email market is moving to a few large organizations that provide hosting for most everyone, a few other large cloud services that provide filtering for much of the remainder, and then everybody else. Smaller organizations are stuck with lousy vendor options or custom development, neither of which is entirely satisfactory. ARC may not be the right solution for smaller organizations with fewer development resources, but 80% of the world needs the big organizations to be successful, and the mailing lists need the big organizations to be accepting of their product. ARC seems to meet those important goals. Doug Foster On Tue, Nov 24, 2020 at 6:57 PM Michael Thomas wrote: > > On 11/24/20 3:24 PM, Brandon Long wrote: > > > On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas wrote: > >> >> >> Sorry, changing the auth-res to old-auth-res and dkim signing the >> message would be completely sufficient, and far easier to understand >> with a lot less bloat. All of this hand wringing about dozens of message >> manglers in the path before it get to the destination and not be able to >> figure out which auth-res was which seems wildly out of proportion for >> what the normal case is: 1 message mangler in the path before it arrives >> at the receiver's domain. Just like this message right here. That's why >> I asked how common that was, which was dismissed, but not answered. >> > > Note that this was exactly what we started with, > X-Original-Authentication-Results > and with Google's implementation signing that with X-Google-DKIM-Signature. > > Our version didn't just sign with DKIM-Signature because of the reasons > already stated in this > thread, that our understanding of how DKIM-Signature was being used made > it a poor choice. > > > Sorry, I didn't see that. Pointer? > > > Our experience also showed that more than one hop is quite common in > enterprise deployments, > and those are also the places where the most complexity arises. Others > shared our experience > as well. > > That's more than one modifying intermediary in *separate* administrative > domains? Within your own administrative domain there shouldn't be an issue > of trust since you can trust your own servers auth-res and that they are > not maliciously trying to forge an auth-res for better treatment. and > course it's best to stop a bad message as soon as possible in the mail > pipeline if for no other reason than why waste the resources. > > > > You say that your message had 1 mangler in the path, but really you don't > know that. It is > likely that some people on this list are on enterprise accounts who are > behind mangling inbound > gateways (rewriting urls to go through safety checking hops is common, for > example). Or maybe > they are on with University accounts using exchange but forward their mail > to a personal or department > gmail account. > > > Well sure, I'm sure it can happen but is it common enough to worry about? > And I'm still not convinced that figuring out who signed what and which > auth-res it belonged to is in insurmountable problem. for one, there are > received headers which better not be getting out of order to help correlate > with the messages' path through intermediary verifiers too. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000b2ccd805b4e600a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael, I think the purpose is stated well enough:=C2=A0 = =C2=A0Mailing lists want to keep adding their content to messages, without = being blocked by recipients.=C2=A0 =C2=A0This means that they have to provi= de recipients with enough information for them to accept the forwarded cont= ent.=C2=A0 =C2=A0Google and Microsoft seem to be on-board with this project= , so it seems pretty successful=C2=A0already.=C2=A0 =C2=A0This train is not= easily=C2=A0stopped.

As to the technical pieces:
<= div>- Unvalidated data, which includes the entire Received header chain, is= only useful for blacklisting.=C2=A0 =C2=A0A spammer will fabricate any hea= der content that he thinks will get his garbage through your spam filter.

- The recipient filter needs to be convinced that t= he submitting MTA is not lying and that the submitting MTA has not been dup= ed.=C2=A0=C2=A0 Digital signatures are the only tool we have for validating forwarded conte= nt.=C2=A0 =C2=A0Since the goal is favorable treatment, digital signatures a= re necessary.=C2=A0 =C2=A0

- Interlocking signatures are needed to get aroun= d the problem of DKIM signatures being damaged by mid-stream content change= s.

As John said early on, this all works in conjun= ction with private knowledge that decides who you=C2=A0believe is not lying= .=C2=A0 =C2=A0Google and Microsoft have that kind of data.
In my opinion, ARC does leave a lot of unanswered questions ab= out how you use the data that ARC provides.=C2=A0 =C2=A0Again, the big orga= nizations have the brain power at their disposal to figure that out for the= mselves,=C2=A0later.

It seems like a lot of softwa= re logic to create an ARC set, even more code to parse it, and even more co= de to use it intelligently.=C2=A0 =C2=A0This is a big problem if you are tr= ying to write the code yourself, but a small problem if you have a big prog= ramming organization.

The email market is moving t= o a few large organizations that provide hosting for most everyone, a few o= ther large cloud services that provide filtering for much of the remainder,= and then everybody else.=C2=A0 =C2=A0Smaller organizations are stuck with = lousy vendor options or custom development, neither of which is entirely sa= tisfactory.=C2=A0 =C2=A0ARC may not be the right solution for smaller organ= izations with fewer development resources, but 80% of the world needs the b= ig organizations to be successful,=C2=A0and the mailing lists need the big = organizations to be accepting of their=C2=A0product.=C2=A0 =C2=A0ARC seems = to meet those important goals.

Doug Foster


On Tue, Nov 24, 2020 at 6:57 PM Michael Thomas <mike@mtcc.com> wrote:
=20 =20 =20


On 11/24/20 3:24 PM, Brandon Long wrote:
=20

On Tue, Nov 24, 2020 at 2:4= 9 PM Michael Thomas <mike@mtcc.com> wrote:


Sorry, changing the auth-res to old-auth-res and dkim signing the
message would be completely sufficient, and far easier to understand
with a lot less bloat. All of this hand wringing about dozens of message
manglers in the path before it get to the destination and not be able to
figure out which auth-res was which seems wildly out of proportion for
what the normal case is: 1 message mangler in the path before it arrives
at the receiver's domain. Just like this message right here= . That's why
I asked how common that was, which was dismissed, but not answered.

Note that this was exactly what we started with, X-Original-Authentication-Results=C2=A0
and with Google's implementation signing that with X-Google-DKIM-Signature.

Our version didn't just sign with DKIM-Signature because of the reasons already stated in this
thread, that our understanding of how DKIM-Signature was being used made it a poor choice.


Sorry, I didn't see that. Pointer?


Our experience also showed that more than one hop is quite common in enterprise deployments,
and those are also the places where the most complexity arises.=C2=A0 Others shared our experience
as well.

That's more than one modifying intermediary in *separate* administrative domains? Within your own administrative domain there shouldn't be an issue of trust since you can trust your own servers auth-res and that they are not maliciously trying to forge an auth-res for better treatment. and course it's best to stop a bad message as soon as possible in the mail pipeline if for no other reason than why waste the resources.



You say that your message had 1 mangler in the path, but really you don't know that.=C2=A0 It is
likely that some people on this list are on enterprise accounts who are behind mangling inbound
gateways (rewriting urls to go through safety checking hops is common, for example).=C2=A0 Or maybe
they are on with University accounts using exchange but forward their mail to a personal or department
gmail account.


Well sure, I'm sure it can happen but is it common enough to worry about? And I'm still not convinced that figuring out who signed what and which auth-res it belonged to is in insurmountable problem. for one, there are received headers which better not be getting out of order to help correlate with the messages' path through intermediary verifiers too.=C2=A0

Mike


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000b2ccd805b4e600a8-- From nobody Tue Nov 24 20:19:25 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8D23A0EAA for ; Tue, 24 Nov 2020 20:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEFlivB2vQQ1 for ; Tue, 24 Nov 2020 20:19:22 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 AC6F33A0EA7 for ; Tue, 24 Nov 2020 20:19:22 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id a186so200974vkh.9 for ; Tue, 24 Nov 2020 20:19: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=qGg97YOFinO14irRxey1WnGpVdP7cqEfd/nS0adFXoY=; b=aXBsxojmLQ5PdKFpTflh+TZaMrWm1NEGYaioMoErFvieiGXn0tKuWX7mAMu2C3FiWG XqTPBTwBscI3zSEF/TrpSumDCjFB629g/Oz+Va7DgUWJZXd0W0qxQcecwcYJBf0QvDUS bMAqgnDY75uFYKm+WtCCl0PPE0BlmgEXZlQfv1l8EB1qUmLyTuFoPYIP91R70bufUQ17 MdK0SG98WvNPSWg+tPfiT4VEpEdJQmurYplovxuylu8JKGZ8PsvQJ5e2gnb/dQoL6q+P 5UhfFlyNMQcCFtUQhOzxOXl5hYeDizO2zvcoClOjNihF0q5ymh9Gm53COugy40670Ve1 pZIA== 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=qGg97YOFinO14irRxey1WnGpVdP7cqEfd/nS0adFXoY=; b=lzRVFbib/Ka1l6m4T+OkMY8YIRLvV28bV/CQOew3zRT7kQc4Ml64ivJSWyuejPrlFc M/CsuZdiCRK/3xtDXifAWcOogt5OidRFSeYqzG2NZm/CKXYFKhWWh28dQHVA3u0nsgC7 /3uxP7o0HNwM/saQ73NdRmMN0C5pweu7FtVcJdg/NexbF09AFDMZzbjh0ZCLXUo/nkf8 bQENT94NrZR7aFT46LNKmDFTRQ+jCtQY/+OghgsdS77DZlHsGd+Avp18Mma/2g0rFZou mnfGZmpNtlIbBT0Bzhjy2T7/6NWmFdh30qmTt9gIi/1A4LUYLgq4JYvttSuZI+cFjbGh 3+Cw== X-Gm-Message-State: AOAM531i9L5nwn/7mT90kMKvK0jfgNAfC5vLeofGgNdDHuJmmc2y5PaZ osDFBZ2debCXKEF0UUi6NmOiG0j2ryJ9AsUaOag= X-Google-Smtp-Source: ABdhPJxEhqX72RQdLY48RTImi4fGN0eC6tAXke5w2wGIgUSZGvdamR+jEznv2r6KVndVIppH0/OCxaAgVT5oTtbNz7M= X-Received: by 2002:a1f:36c1:: with SMTP id d184mr957524vka.13.1606277961488; Tue, 24 Nov 2020 20:19:21 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 24 Nov 2020 20:19:08 -0800 Message-ID: To: Douglas Foster Cc: Michael Thomas , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000004e1b7d05b4e6bb94" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 04:19:24 -0000 --0000000000004e1b7d05b4e6bb94 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > Michael, I think the purpose is stated well enough: Mailing lists want > to keep adding their content to messages, without being blocked by > recipients. This means that they have to provide recipients with enough > information for them to accept the forwarded content. Google and > Microsoft seem to be on-board with this project, so it seems pretty > successful already. This train is not easily stopped. > That sounds about right. Put another way: DMARC's success is at least in part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to carry forward from the MLM, in a credible way, an indication of what the MLM saw in terms of DKIM results when the message got to the MLM. So then, although an author signature will fail post-MLM, the MLM signature will pass, and the ARC data will tell you that the author signature was good when the MLM got it. If you trust the chain, then that can be an alternative to the DKIM input when the final recipient performs a DMARC evaluation. Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps not as concretely as one might like. In my opinion, ARC does leave a lot of unanswered questions about how you > use the data that ARC provides. Again, the big organizations have the > brain power at their disposal to figure that out for themselves, later. > This is why it was published as Experimental. Its efficacy is not (yet) known, nor are any side effects. Although, now that you have me thinking about it: It's been a year; have we any meaningful data about this yet? It seems like a lot of software logic to create an ARC set, even more code > to parse it, and even more code to use it intelligently. This is a big > problem if you are trying to write the code yourself, but a small problem > if you have a big programming organization. > When I implemented it, there was a great deal of processing logic that was recycled from DKIM. That was advantageous. But I agree, someone implementing ARC with no context at all could easily find it a challenge to get it to interoperate. -MSK --0000000000004e1b7d05b4e6bb94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2020 at 7:27 PM Douglas F= oster <dougfoster= .emailstandards@gmail.com> wrote:
Michae= l, I think the purpose is stated well enough:=C2=A0 =C2=A0Mailing lists wan= t to keep adding their content to messages, without being blocked by recipi= ents.=C2=A0 =C2=A0This means that they have to provide recipients with enou= gh information for them to accept the forwarded content.=C2=A0 =C2=A0Google= and Microsoft seem to be on-board with this project, so it seems pretty su= ccessful=C2=A0already.=C2=A0 =C2=A0This train is not easily=C2=A0stopped.

That sounds about right.=C2=A0 Put ano= ther way: DMARC's success is at least in part stymied by what MLMs do t= hat invalidates DKIM; ARC is an attempt to carry forward from the MLM, in a= credible way, an indication of what the MLM saw in terms of DKIM results w= hen the message got to the MLM.=C2=A0 So then, although an author signature= will fail post-MLM, the MLM signature will pass, and the ARC data will tel= l you that the author signature was good when the MLM got it.=C2=A0 If you = trust the chain, then that can be an alternative to the DKIM input when the= final recipient performs a DMARC evaluation.

Sect= ions 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps not as conc= retely as one might like.

In my opinion, ARC does leave a l= ot of unanswered questions about how you use the data that ARC provides.=C2= =A0 =C2=A0Again, the big organizations have the brain power at their dispos= al to figure that out for themselves,=C2=A0later.
This is why it was published as Experimental.=C2=A0 Its effica= cy is not (yet) known, nor are any side effects.=C2=A0 Although, now that y= ou have me thinking about it: It's been a year; have we any meaningful = data about this yet?

It seems like a lot of software l= ogic to create an ARC set, even more code to parse it, and even more code t= o use it intelligently.=C2=A0 =C2=A0This is a big problem if you are trying= to write the code yourself, but a small problem if you have a big programm= ing organization.

When I implem= ented it, there was a great deal of processing logic that was recycled from= DKIM.=C2=A0 That was advantageous.=C2=A0 But I agree, someone implementing= ARC with no context at all could easily find it a challenge to get it to i= nteroperate.

-MSK
--0000000000004e1b7d05b4e6bb94-- From nobody Wed Nov 25 00:08:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5C43A11FA for ; Wed, 25 Nov 2020 00:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 8ZVbgOulAvsl for ; Wed, 25 Nov 2020 00:08:40 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CDF3A11F8 for ; Wed, 25 Nov 2020 00:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606291716; bh=mb4vtFHr88aikGFotHAVuvKfPErrd3yf36Ztdr/bZUA=; l=926; h=To:References:From:Date:In-Reply-To; b=BplDGpdDW7Sb4BNVIAw4JmERsS+Jf7y7kOhsQctSTo/1ml1+T39usV+s7RdZ9mQCY fWL49UQTG88zI9x7nBg6nSV69WfELtnGIfca95bggolLAz56DZLxRc351sbjhqRDZO M5Ey6RPdB3fCpFT+V8dlA5z69n5vzqhaK4lblFiX2hh0nwpkcotiJEFbwZte8 Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07E.000000005FBE1104.00001678; Wed, 25 Nov 2020 09:08:36 +0100 To: John R Levine , dmarc@ietf.org References: <20201124170351.C430227DFEBF@ary.qy> <36f4f840-0911-56f5-185b-3f60166eab47@tana.it> From: Alessandro Vesely Message-ID: <12b892a9-372a-3627-3183-cd318a368a78@tana.it> Date: Wed, 25 Nov 2020 09:08:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Doing a tree walk rather than PSL lookup X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 08:08:43 -0000 On Tue 24/Nov/2020 20:29:11 +0100 John R Levine wrote: > >> "Holy Roman Empire" > > Organizations, typically universities, where the nominal organization tree and > the actual control are different.  The PSL isn't useful because the party that > controls their Org domain often doesn't control lower parts of the DNS tree. The PSL takes care of particular cases, listing suffixes like cloudfront.net or various flavors of amazonaws.com, which officially look like any other 2nd level domain, but actually host independent organizations. Those entries are commented with the names and email addresses of the principal who submitted them. In their own words: In addition, owners of privately-registered domains who themselves issue subdomains to mutually-untrusting parties may wish to be added to the PRIVATE section of the list. https://github.com/publicsuffix/list/wiki/Guidelines Best Ale -- From nobody Wed Nov 25 03:28:22 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6B3A0E78 for ; Wed, 25 Nov 2020 03:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BnmivwVm61xb for ; Wed, 25 Nov 2020 03:28:17 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE303A0E77 for ; Wed, 25 Nov 2020 03:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606303693; bh=azR4BrNrfeBnOr9vqoZIgJEyuPCEe1AkBCniQCtzQlU=; l=1288; h=To:From:Date; b=BQaWGbv7KS1j0ObINWttTkezoHcExYtj/9WcRv+iwVKZ565TWkZZvvxagQUXrE7ai xGq1xFKW4YLT/g9SPDnPhWwqsMRns3ig9uKUWdwZ4tRevnuVtl15swm96GkVxBOqTC QH42q4xNmqcFdXvy1fmecVruMlMd+0cgv+mkJe3wIJTmK+g1Syb2kcNJR3s7y Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0C4.000000005FBE3FCD.00002EFF; Wed, 25 Nov 2020 12:28:13 +0100 To: dmarc-ietf From: Alessandro Vesely Message-ID: <5f8cc7aa-79b2-dbed-23f5-7dfc45e4df1b@tana.it> Date: Wed, 25 Nov 2020 12:28:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 11:28:21 -0000 On Mon 23/Nov/2020 22:27:41 +0100 John Levine wrote: > ARC deals with the problem that most list software forwards everything > with a subscriber's address on the From: line and does a lousy job of > spam filtering. The question is if the entity sending the message to > the list was who it purported to be. > > For example, if a message from a list fails DMARC alignment, but ARC > says it was aligned on the way in, it's likely a real message from a > subscriber. If it was unaligned on the way in, it's likely spam. I publish p=none in order to avoid spurious rejections due to casual message modifications that happen in transit. However, I'm quite confident that SPF or DKIM verify, since users submit messages through the right mail server. Couldn't I address direct flows only? Doing so would prevent a casual spammer from abusing mailing lists I'm subscribed to by simply faking From:. A direct flow is one were SPF credentials (helo name or return address) are aligned with From:. That includes some simple forwarding, but not mailing list traffic. Direct policy could be expressed as dp=. Authenticate as usual, either SPF or DKIM. On failure, discard only if direct flow. For example: v=DMARC1; p=none; dp=reject; Makes sense? Best Ale -- From nobody Wed Nov 25 04:57:54 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565E23A10C4 for ; Wed, 25 Nov 2020 04:57:53 -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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8RqwwOMZ-V7 for ; Wed, 25 Nov 2020 04:57:51 -0800 (PST) Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767183A0D7D for ; Wed, 25 Nov 2020 04:57:51 -0800 (PST) X-ASG-Debug-ID: 1606309067-11fa313c0156ca0001-K2EkT1 Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id u76QPjdRYNMkXzGZ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Wed, 25 Nov 2020 07:57:48 -0500 (EST) X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49 X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=from:message-id:subject:to; bh=ofakgPkwbTEccEYPUYXEp/2yebU+kpObIsRzigZtqN0=; b=ax6Pbh1HiI/GYDAb8mD/XBH5ljDvsRChU+7OXOs0QNWX0iAt8KgRwIMRWUGqckyMX 36A7v7eZuUyfG+45CBxl8v20SiMES8ieFrFKWoxe7C7/EL3dZv47bEhGPU8ZEyM2N RbVycLcbiLTaTjrkApj/bdL1av46I4salfaLrSKOU= Received: by webmail.bayviewphysicians.com via HTTP; Wed, 25 Nov 2020 07:57:41 -0500 To: Alessandro Vesely , dmarc-ietf Date: Wed, 25 Nov 2020 07:57:38 -0500 X-ASG-Orig-Subj: RE: [dmarc-ietf] A policy for direct mail flows only, was ARC questions Message-ID: MIME-Version: 1.0 Content-Type: multipart/multipart; boundary=6aa9872577674169a8494850d32443d7 SavedFromEmail: fosterd@bayviewphysicians.com Importance: normal From: "Douglas E. Foster" X-Exim-Id: e9166148b9564102a652b4764b4f61ff X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49] X-Barracuda-Start-Time: 1606309068 X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384 X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at bayviewphysicians.com X-Barracuda-Scan-Msg-Size: 5243 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.81 X-Barracuda-Spam-Status: No, SCORE=0.81 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE, HTML_TAG_BALANCE_BODY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.86114 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.81 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 12:57:53 -0000 This is a multipart message in MIME format. --6aa9872577674169a8494850d32443d7 Content-Type: multipart/alternative; boundary=a36225a875fc4f48a7070521e34dd240 --a36225a875fc4f48a7070521e34dd240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indirect mail flows are difficult to detect.=A0 =A0SMTP address rewrite is = already common practice for forwarding.More to the point, John's interest i= s finding ways to increase the trust level for forwarded mail, while your i= dea says that direct mail is more trusted than indirect maill, which is the= problem he is trying to overcome.We need to be able to evaluate indirect m= ail based on both the submitter MTA. and the originator MTA.=A0 =A0ARC gets= us started in that direction.=A0 =A0I think more filtering data is needed = and am working on a proposal to that effect.Doug
-------- Original message --------
=
From: Alessandro Vesely
Date: 11/25/20 6:= 28 AM (GMT-05:00)
To: dmarc-ietf
Su= bject: [dmarc-ietf] A policy for direct mail flows only, was ARC questions =
On Mon 23/Nov/2020 22:27:41 +0100 John Levine wrote: > ARC deals with the problem that most list software forwards everything > with a subscriber's address on the From: line and does a lousy job of > spam filtering. The question is if the entity sending the message to > the list was who it purported to be. > > For example, if a message from a list fails DMARC alignment, but ARC > says it was aligned on the way in, it's likely a real message from a > subscriber. If it was unaligned on the way in, it's likely spam. I publish p=3Dnone in order to avoid spurious rejections due to casual mess= age modifications that happen in transit. However, I'm quite confident that SP= F or DKIM verify, since users submit messages through the right mail server. Couldn't I address direct flows only=3F Doing so would prevent a casual sp= ammer from abusing mailing lists I'm subscribed to by simply faking From:. A direct flow is one were SPF credentials (helo name or return address) are= aligned with From:. That includes some simple forwarding, but not mailing = list traffic. Direct policy could be expressed as dp=3D. Authenticate as usual= , either SPF or DKIM. On failure, discard only if direct flow. For example: v=3DDMARC1; p=3Dnone; dp=3Dreject; Makes sense=3F Best Ale -- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --a36225a875fc4f48a7070521e34dd240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indirect mail flows are difficult to de= tect.   SMTP address rewrite is already common practice for forwa= rding.

More to the point, John= 's interest is finding ways to increase the trust level for forwarded mail,= while your idea says that direct mail is more trusted than indirect maill,= which is the problem he is trying to overcome.

=
We need to be able to evaluate indirect mail based = on both the submitter MTA. and the originator MTA.   ARC gets us = started in that direction.   I think more filtering data is neede= d and am working on a proposal to that effect.

<= /div>
Doug


-------- Original message --------
From: Alessan= dro Vesely <vesely@tana.it>
Date: 11/25/20 6:28 AM (GMT-= 05:00)
To: dmarc-ietf <dmarc@ietf.org>
Subject:= [dmarc-ietf] A policy for direct mail flows only, was ARC questions
=

On Mon 23/Nov/2020 22:27:41 +0100 John Levine wrote:
> = ARC deals with the problem that most list software forwards everything
&= gt with a subscriber's address on the From: line and does a lousy job of> spam filtering. The question is if the entity sending the message to> the list was who it purported to be.
>
> For example, if = a message from a list fails DMARC alignment, but ARC
> says it was ali= gned on the way in, it's likely a real message from a
> subscriber. If= it was unaligned on the way in, it's likely spam.


I publish p= =3Dnone in order to avoid spurious rejections due to casual message
mod= ifications that happen in transit. However, I'm quite confident that SPF o= r
DKIM verify, since users submit messages through the right mail serve= r.

Couldn't I address direct flows only=3F Doing so would prevent a= casual spammer
from abusing mailing lists I'm subscribed to by simply = faking From:.

A direct flow is one were SPF credentials (helo name o= r return address) are
aligned with From:. That includes some simple fo= rwarding, but not mailing list
traffic. Direct policy could be express= ed as dp=3D. Authenticate as usual,
either SPF or DKIM. On failure, d= iscard only if direct flow. For example:

v=3DDMARC1; p=3Dnone; = dp=3Dreject;

Makes sense=3F

Best
Ale
--




















=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dm= arc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo= /dmarc

--a36225a875fc4f48a7070521e34dd240-- --6aa9872577674169a8494850d32443d7-- From nobody Wed Nov 25 09:30:29 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFEA3A1AD3 for ; Wed, 25 Nov 2020 09:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1152-bit key) reason="fail (message has been altered)" 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 g6VesrJ1DIqd for ; Wed, 25 Nov 2020 09:30:26 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F093A1AD1 for ; Wed, 25 Nov 2020 09:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606325422; bh=iKLTaEaC5JrQJ2PKAvdwlDOp3w6YZj3ug6V5camTEh4=; l=1627; h=To:References:From:Date:In-Reply-To; b=BD/8bUs2vFCcYmXeSn+dbO1cMomMHXW6WhvlrOYlhPIaczOeXHty4h8c9bRhOceTh iAxDTtpQ26plHDxU38tKCBnakeERpRHgZgYOIpiID7xHfU7XiQtG9Rz7ji6UaIQf1n VqQgweVwAPUi9xQBub79Tf98+l+tPNBoSBp5wshgJWCbNK+a1xLnsS9loykLw Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07C.000000005FBE94AE.00006ECB; Wed, 25 Nov 2020 18:30:22 +0100 To: "Douglas E. Foster" , dmarc-ietf References: From: Alessandro Vesely Message-ID: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> Date: Wed, 25 Nov 2020 18:30:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 17:30:27 -0000 Hi, On 25/11/2020 13:57, Douglas E. Foster wrote: > Indirect mail flows are difficult to detect.   SMTP address rewrite is already > common practice for forwarding. Return address rewriting is a Good Thing™, unlike From: rewriting. I'd welcome forwarding my email, even if modified (I'm not a bank). At the same time, I'd stop spam pretending to be coming directly from my server. SPF -all yields such possibility, except that it sometimes stops internal forwarding at uncoordinated admds. My proposed dp=reject would ameliorate spf-all while still being more permissive than p=reject. A midway policy, which tackles the "mailing list problem" from the other side. > More to the point, John's interest is finding ways to increase the trust level > for forwarded mail, while your idea says that direct mail is more trusted than > indirect mail, which is the problem he is trying to overcome. Yes, they are two different problems. > We need to be able to evaluate indirect mail based on both the submitter MTA. > and the originator MTA.   ARC gets us started in that direction.   I think more > filtering data is needed and am working on a proposal to that effect. Without resorting to ARC, it is still possible to validate author domain's signatures directly if the MLM just adds a subject tag and a footer, like, for example, this list does. While ARC solves "deep" forwarding problems, which may arise in the context of email address portability, MLM transformation reversion solves the simpler mailing list problem, including reverting munged From:'s. Best Ale -- From nobody Wed Nov 25 10:24:11 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B63A1535 for ; Wed, 25 Nov 2020 10:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wisc.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGwxhoP3liio for ; Wed, 25 Nov 2020 10:24:08 -0800 (PST) Received: from wmauth2.doit.wisc.edu (wmauth2.doit.wisc.edu [144.92.197.222]) (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 201213A1530 for ; Wed, 25 Nov 2020 10:24:07 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2055.outbound.protection.outlook.com [104.47.38.55]) by smtpauth2.wiscmail.wisc.edu (Oracle Communications Messaging Server 8.0.2.4.20190812 64bit (built Aug 12 2019)) with ESMTPS id <0QKD00JFU746PI30@smtpauth2.wiscmail.wisc.edu> for dmarc@ietf.org; Wed, 25 Nov 2020 12:24:06 -0600 (CST) X-Wisc-Env-From-B64: amVzc2UudGhvbXBzb25Ad2lzYy5lZHU= X-Spam-PmxInfo: Server=avs-2, Version=6.4.7.2805085, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2020.11.25.181519, AntiVirus-Engine: 5.79.0, AntiVirus-Data: 2020.11.17.5790001, SenderIP=[104.47.38.55] ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ePnhL+fb7s22VvoHC/0EAkVMbI6QaxbQTlLNsKxHdVrkW+j228LvnxdRcZ/rIQrT+ugzX4itmfowRMCibaonZqeUhD2wxmOCyZXIhiliBp9AnVUd5VptNaXTfg/YFZdP7bbNJqpOdggg9VKETVfvE/4JW/w5S7/jAADDzxtnocJpjE73UEKg7fdrIRDpmuhnvk4mte+2A3EPRCT15Lu7lkjMJROx4rGBzctJA9eYoDtLw579k3ePaBxf+zj82vL7ZeFFwbFC5uBx5pbG6WjQ17k3pLH/ZUtRVtzTKS48zRs7jFN3p+Re+p9CqpUF3D3SVsx4+b5jnZCbkMtRo579+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oPzmsRVFy6zxqCrA73Lnaiyp5Brm3FEjPEMbnihbHv8=; b=mWEVlU9adNmNKd9MNTPiSh0QpUk4LFefMfY1V83XsS1ILtUSfVmawJntYBmgplYUcuntR/53CxQuQq4kN+cQ8IwQRb7x9PkLBDP0XPu0xcdtiIGuiGlkRSg+WmBM9OBjiqzcsBA3gMqonb/Ig6NLQJ0gXUsaOgxyIQwY4npyoq7/CUUx1gJpbQKWgCf60yqLm86sXIjsJfld76j9+pdqaxNRO4E9svtOxTT1iu6aB9eksU9h1P1VD4BKFXQ5aIz7OkXgUZC+o40OaBHf/3oIUfZVeShvwqj6pSt3ZU9AfeSWgRNK5BKaTJwY/unguXHu7dB3U/8vkWKEE7SHcGLHqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wisc.edu; dmarc=pass action=none header.from=wisc.edu; dkim=pass header.d=wisc.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisc.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oPzmsRVFy6zxqCrA73Lnaiyp5Brm3FEjPEMbnihbHv8=; b=eixz5jtiJmDVuQWN1YqYGmdBeFQj4P8MskX3pRWGl3NH3JHzkEQ0yAtbCb/H49wcmdzatclOUN57GDuI/9YJmJ2jNcugDN15pWmPnt1Wog0h7LC+9HUR9tg4F7S9GaIdodt+YImm/a1YCwZu0lBrPlATy1XofKbQ3wlLEqjwmvg= Received: from CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) by MWHPR06MB3021.namprd06.prod.outlook.com (2603:10b6:300:4a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Wed, 25 Nov 2020 18:24:05 +0000 Received: from CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5]) by CO6PR06MB7059.namprd06.prod.outlook.com ([fe80::39b8:8441:c452:a4b5%7]) with mapi id 15.20.3589.022; Wed, 25 Nov 2020 18:24:05 +0000 To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> From: Jesse Thompson Message-id: <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> Date: Wed, 25 Nov 2020 12:24:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-reply-to: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 8bit X-Originating-IP: [146.151.213.183] X-ClientProxiedBy: CH2PR18CA0051.namprd18.prod.outlook.com (2603:10b6:610:55::31) To CO6PR06MB7059.namprd06.prod.outlook.com (2603:10b6:5:342::18) MIME-version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [146.151.213.183] (146.151.213.183) by CH2PR18CA0051.namprd18.prod.outlook.com (2603:10b6:610:55::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20 via Frontend Transport; Wed, 25 Nov 2020 18:24:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 41485d5e-93d1-4d6c-d7c1-08d8916f4a84 X-MS-TrafficTypeDiagnostic: MWHPR06MB3021: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AsbrMuKkJVKhsbRchNXz+OYDfWssKAeIeH0bkqXvmqyEPQ8dU+Qb8HjwKGNOGeZdsB/oztgJ4jExL3MSsPaYzPvN79tpKiq4CCh6qqI+sY/0ftVv1Jqna5uTKgNRrKHb1giU4rdh9NaHy3feCKdfCLO4L0Ykq32AsNd0FnQMX4re/6S7ijP4c/rByNJQYSyAoeRxcQ4jZ/Mqd0Otg3P/fnktpXVxSUj1SBI/vjU/zGH9J/0KPvdUipMTRdYoaPpJiIscCfoUyHFrgJIjw5j9TlzNCDAeHm1kVJHmkz3i2qbtmiHL/fdER0JXhbqK9EwLjazn8WtHjvl4OUc4J4Ok8q0nJokOubKVYqthlld6Zdvw1BNMkPRYjB5Tu5BxHbOHpZu4v4o1KR7pJzJTaRfDZg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR06MB7059.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(346002)(366004)(376002)(31686004)(186003)(75432002)(2616005)(83380400001)(16526019)(86362001)(16576012)(786003)(316002)(31696002)(956004)(53546011)(26005)(6706004)(6916009)(2906002)(8676002)(36756003)(478600001)(6486002)(66556008)(5660300002)(8936002)(66946007)(44832011)(66476007)(3940600001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ei9GRHd1ZjlCWlgxNU5Cczh2RDc1Q1B0NUZVbExZUFhzL0NUVDIzT3pXU1Zs?= =?utf-8?B?aWE5YmF5V0xJL1ZQQTZwaXhJTDRWTHRLVHF2MVpveHE5SFU2cjI2b0kwQ25E?= =?utf-8?B?VFNIeXNLdG9CNmJ3VnFUa0t0dlZxS3dvWkxETkI1bnh6cXkzRTJjalI0WVIx?= =?utf-8?B?VUlkT2YvQkt4R0hzcXJOUWh2YWs2UGt5YXV2OVBscU5CdFVDTVNKYXgrY240?= =?utf-8?B?U1pUazhINWFwbW9mZFR0WW82VHNTYjBHNG5YZjhMbXV4OEpEZXlrZkdXK2Rq?= =?utf-8?B?OStvbmJXb0x6NElHUXJDUDNZN1IyQXBUd2tKMENlZDc0c0syMEtWNlNrdlVN?= =?utf-8?B?U0NyN1FkcnAvV3JFUU00OFdPdUF0RW9vR1BqR1Y0UjZVbm56MzZ1M0lTK2dR?= =?utf-8?B?SHdCdU9ORjl6QWZyZ2wwekFqU2FheHdRTFVMbFFpMk5vc1J5SkluTEtqTmxa?= =?utf-8?B?OVlnRUNraGNSOW90TUs3eFFXRTJPazRwR1VJRGFBYmJNYjFKcGIvRXFnWnZ3?= =?utf-8?B?bEJKNEYrZ0ZreDBQSVVzbi8weWpGeW5pTWFFc2RiYWtGSnJrTjhSZGk4TmdT?= =?utf-8?B?YUhGVFR6ZXBlYkVZOHNpcTVsejNZRjRNSndhTm5YTVRtYUVKS2JRdSsyYVlL?= =?utf-8?B?OXFiZEJWMFJwTWZldFU1YUkyZkZrUUpsa1FOR0drQlorRFZheWc5b3FMY1ll?= =?utf-8?B?NlRaNzhyTVpSVituYkxmUnhhd0JvdDdzczV2TUFScXNiZHA2Y283V0tRMFlB?= =?utf-8?B?aW1yV0VDUFFFWmx6ei9tTG5GTU1JRWFob0ZKeUMyd0xZYytwSTZYaGZVZ01U?= =?utf-8?B?aVI2eEw0aXhzUjFBd1RmVk5DNmVFcXlQUTFvMlp1Z0lCS2J4Wkh0ODAzRGY3?= =?utf-8?B?ME80WGIzbFRrYTFnRXA2NVpSUHZpbk9HOTl5MGRDNjdOdSt6eWNsS0tTeEFM?= =?utf-8?B?MHZ5Yjk2VFcwQW9pbmpuRmpYSmhsVnk3Ylk4N1U2VlBUZDJEMHVwM25Lb2s4?= =?utf-8?B?WlBZNWhnUEFGa1pxdnV6L21JQUhZY2xVa0xKWCs0V3hReDRzZGRHZWZkQVAz?= =?utf-8?B?cmloZFNmMWZ1NmI0R3IwcTRBdTEvUDZsVU8rZzZpWUd5d2xwZUkySUNWOGJn?= =?utf-8?B?ajRNRE54U25TbFovaGJvSE5TaUF3OGNFSEhJeHhia1B4MEhIazBDeDkwdWVE?= =?utf-8?B?Y2d6a05MdGFLckt5TzFTTWlYMHZyMkk1cXFSNjZKRmdCSkx0TXc1ZXBUcWxu?= =?utf-8?B?YUF1Vk4wTkFVRmlJazVGdFllZ1FSVGE1cVZEeDV1ZklMSm1pOHhPQmpicDNF?= =?utf-8?Q?s8owavqUnyH4Q2fTqvWIo1bvpv598UYech?= X-OriginatorOrg: wisc.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 41485d5e-93d1-4d6c-d7c1-08d8916f4a84 X-MS-Exchange-CrossTenant-AuthSource: CO6PR06MB7059.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2020 18:24:05.1936 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 2ca68321-0eda-4908-88b2-424a8cb4b0f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1qu44Y4Hz5QYHTk0cSXCX64PqvhS4y3JpkthGJCS29iXKkXDvz2n114lnROeFqvLGciwIpQ4GFOC3PTaVDSulA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB3021 Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 18:24:10 -0000 On 11/25/20 11:30 AM, Alessandro Vesely wrote: > Without resorting to ARC, it is still possible to validate author domain's signatures directly if the MLM just adds a subject tag and a footer, like, for example, this list does.   While ARC solves "deep" forwarding problems, which may arise in the context of email address portability, MLM transformation reversion solves the simpler mailing list problem, including reverting munged From:'s. I agree that ARC isn't really needed to do this (trust the last hop from the MLM and determine the original authenticity from the MLM's perspective), although I think that ARC somewhat standardizes what headers/value to look for (I may be wrong). Plus, if it eventually solves the "deep" forwarding issue, then ARC is certainly better than trying to follow received header chains, etc. Anecdotally, after much debate, our team is leaning more towards *not* reverting munged From:'s from our own MLM 1. Until ARC has a reputation model that is commonly adopted, header munging isn't going to subside. I still find MLM operators who are just now realizing that they have to munge messages. We need to tell users that this is the new, growing, reality. 2. If we only unmunge for our own domains' users' authoring messages to our own MLM, it has limited overall effect, and it distorts the user-reality story from point #1. We would have to unmunge for all domains' authors sending to all "trusted" MLMs in order to give the users what they expect from their prior reality. 3. Since we can only unmunge for our own recipients, it just creates an inconsistent experience on top of the already inconsistent experience of the conditional munging most MLMs do based on the authors' DMARC policies. We would rather see: 3a) MLMs that munge for all messages regardless of the author's domain's DMARC policy 3b) MLMs that allow operators to configure recipient destinations that they know are going to trust non-munged messages (via ARC or whatever) Jesse P.S. If anyone knows how to trick Google Groups into doing 3a and/or 3b, please ping me (off list is OK) From nobody Wed Nov 25 11:03:44 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF643A15D6 for ; Wed, 25 Nov 2020 11:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 V94-fA1awwa6 for ; Wed, 25 Nov 2020 11:03:41 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 026673A15D4 for ; Wed, 25 Nov 2020 11:03:40 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id t18so1586520plo.0 for ; Wed, 25 Nov 2020 11:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=NWFEklCqrB6b/pmPp5BLuLth9RSW5uYfNCa+1tjhh48=; b=TdNhgenGRHGDW0FpXbC3xkOF5I17vCy22j/oiVXUh02LenrXJup3muKonKdFaZ61m2 iUxflgsimNjATd7UhDWOzoHl+alNQyXcf0cp9gdzmjzKblv1x7YYRKEYshUwyqEQWRSn DnN9L1///nXBwRhawsbC/atgp/A4+ZxoLST0+rVae7Eynbwv9C5JYSceS8lqi6v9GQt9 6+jPTv9vmtnGncOBYmKpS0/1kfVuVA2Ama29KRNjaiSnK7+i81Q7Cb6oP5WyVI8mQJVH 7tP2/e8Jzu2ClWV1HbapWQWLHOwhyIp2+oZox0eQbkbK+4lEB6/yXfmU96DuUBFxJlY8 zm0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=NWFEklCqrB6b/pmPp5BLuLth9RSW5uYfNCa+1tjhh48=; b=Bu+mKJmpAEuKa4CQmNTopNCBlp8/arJANrR6BF75RCCQQyUcRqbw/WMW3S7zoRZ5jK XQH9yZVFIO3CAfreclVeOUfQ87aOihe+NxjxZZkWsK3DlMKXwGIN0MMCr4dNblsf2Aj3 +NtfgTGVF0X3FC6c7MmVfVLrlvzrDoxSRBtqb6WGEUn7Wosj8jt5CxcMWT6gVA7htOuT nNuA+g/xP9aXVSzc8oPxQz5vjBVH61fqC/2q7C5GQODhsI4aRovCGvApvolCAczRN2cr kokLx+SF0E/uF+/AQyvQC7XdDcmfj2t01e0bdcPkRUHS+Dd3Y3YrxO9+Mow7Vc9YNiUy lmgg== X-Gm-Message-State: AOAM530QJ4+TP7VdiG6LoJXeyRrG0jzeFsbYWDmQSF4U6OgF30UDX40F 21X2f8MtWvheNoS2XfNUxX5rVuM7QJSovw== X-Google-Smtp-Source: ABdhPJxuyxFWewU1Tmzy5RR3p17B+r5SZeuAzWfGFwQMT82rVfywLopGQ7nIthtTjjcjzU+e1goukQ== X-Received: by 2002:a17:902:b192:b029:d7:ca4a:4ec1 with SMTP id s18-20020a170902b192b02900d7ca4a4ec1mr4181072plr.76.1606331019720; Wed, 25 Nov 2020 11:03:39 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id y24sm2515934pfn.176.2020.11.25.11.03.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 11:03:38 -0800 (PST) To: "Murray S. Kucherawy" , Douglas Foster Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> From: Michael Thomas Message-ID: Date: Wed, 25 Nov 2020 11:03:37 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6811A00D5C25A237C051A44A" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:03:43 -0000 This is a multi-part message in MIME format. --------------6811A00D5C25A237C051A44A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/24/20 8:19 PM, Murray S. Kucherawy wrote: > On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster > > wrote: > > Michael, I think the purpose is stated well enough:   Mailing > lists want to keep adding their content to messages, without being > blocked by recipients.   This means that they have to provide > recipients with enough information for them to accept the > forwarded content.  Google and Microsoft seem to be on-board with > this project, so it seems pretty successful already.   This train > is not easily stopped. > > > That sounds about right.  Put another way: DMARC's success is at least > in part stymied by what MLMs do that invalidates DKIM; ARC is an > attempt to carry forward from the MLM, in a credible way, an > indication of what the MLM saw in terms of DKIM results when the > message got to the MLM.  So then, although an author signature will > fail post-MLM, the MLM signature will pass, and the ARC data will tell > you that the author signature was good when the MLM got it.  If you > trust the chain, then that can be an alternative to the DKIM input > when the final recipient performs a DMARC evaluation. That's been known for over 15 years. I'm still trying to understand the assertion that DKIM signatures are a "bad fit". I just looked at a random message off of this thread and they look identical except for the i= field. another field could trivially be added to DKIM and auth-res -- since unknown fields are supposed to be ignored -- if this binding property is absolutely needed, which I remain unconvinced by as well. > > Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps > not as concretely as one might like. > > In my opinion, ARC does leave a lot of unanswered questions about > how you use the data that ARC provides.   Again, the big > organizations have the brain power at their disposal to figure > that out for themselves, later. > > > This is why it was published as Experimental.  Its efficacy is not > (yet) known, nor are any side effects. Although, now that you have me > thinking about it: It's been a year; have we any meaningful data about > this yet? If you ask me, part of the experiment should be able to show use cases that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address that ARC can, and most especially what percentage of email traffic we're actually talking here. As far as I can see ARC doesn't bring anything especially new for the mailing list kind of use cases since it really easy to see who the intermediary was that broke the signature. I have been told there are some vague other kinds of use cases but is unclear whether those use cases actually happen before or after the message arrives at the front door of the final receiving domain. Yes, i read section 7, but it doesn't tell me why this can't be handled with current technology. It seems to me that the lynchpin is whether I trust the domain that broke the signature and resigned. That's either a previously solved or unsolved problem depending on your perspective. If I trust the intermediary domain to not send me spam via reputation, I forward it along to be delivered and ignore the DMARC record. Why do I care whether it originally validated from the sending domain or not? If you ask me, that's the intermediary domain's problem since they have an incentive to keep their reputation and not send spam through. Mike --------------6811A00D5C25A237C051A44A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
Michael, I think the purpose is stated well enough:   Mailing lists want to keep adding their content to messages, without being blocked by recipients.   This means that they have to provide recipients with enough information for them to accept the forwarded content.   Google and Microsoft seem to be on-board with this project, so it seems pretty successful already.   This train is not easily stopped.

That sounds about right.  Put another way: DMARC's success is at least in part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to carry forward from the MLM, in a credible way, an indication of what the MLM saw in terms of DKIM results when the message got to the MLM.  So then, although an author signature will fail post-MLM, the MLM signature will pass, and the ARC data will tell you that the author signature was good when the MLM got it.  If you trust the chain, then that can be an alternative to the DKIM input when the final recipient performs a DMARC evaluation.

That's been known for over 15 years. I'm still trying to understand the assertion that DKIM signatures are a "bad fit". I just looked at a random message off of this thread and they look identical except for the i= field. another field could trivially be added to DKIM and auth-res -- since unknown fields are supposed to be ignored -- if this binding property is absolutely needed, which I remain unconvinced by as well.



Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps not as concretely as one might like.

In my opinion, ARC does leave a lot of unanswered questions about how you use the data that ARC provides.   Again, the big organizations have the brain power at their disposal to figure that out for themselves, later.

This is why it was published as Experimental.  Its efficacy is not (yet) known, nor are any side effects.  Although, now that you have me thinking about it: It's been a year; have we any meaningful data about this yet?

If you ask me, part of the experiment should be able to show use cases that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address that ARC can, and most especially what percentage of email traffic we're actually talking here. As far as I can see ARC doesn't bring anything especially new for the mailing list kind of use cases since it really easy to see who the intermediary was that broke the signature. I have been told there are some vague other kinds of use cases but is unclear whether those use cases actually happen before or after the message arrives at the front door of the final receiving domain. Yes, i read section 7, but it doesn't tell me why this can't be handled with current technology.

It seems to me that the lynchpin is whether I trust the domain that broke the signature and resigned. That's either a previously solved or unsolved problem depending on your perspective. If I trust the intermediary domain to not send me spam via reputation, I forward it along to be delivered and ignore the DMARC record. Why do I care whether it originally validated from the sending domain or not? If you ask me, that's the intermediary domain's problem since they have an incentive to keep their reputation and not send spam through.

Mike

--------------6811A00D5C25A237C051A44A-- From nobody Wed Nov 25 11:07:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8453A1610 for ; Wed, 25 Nov 2020 11:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 q4R4GJtK5hDh for ; Wed, 25 Nov 2020 11:07:43 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1713A15ED for ; Wed, 25 Nov 2020 11:07:43 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id 18so1556683pli.13 for ; Wed, 25 Nov 2020 11:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=YlALgN9iz0fH/0JhFwGmBm1alFxx2ErY0cUmxLmeN8M=; b=Yidi41PidUEFDzQ0mOAQbntWjHnzn0lmaHnMi1Xk4c+bl+qG14eKz8JwtRUxAcN073 nxfInOjBSWDxnmOn5oHkmY1Hyy9If7mwB6wOeVK7XgNNt5y8BLNosQqHFwhjQ18jMw+L h4EjGzD3DQe7sBpyG69NVCXKvTVF8Eya1Y9eHRFRg9z3vZqYKoD/A6tvX7oiyAse7e4I UHc4tp3aOw9KLnceKpx3oPUfnbqMkB2m6SU6ye8qYBkImhD7sluSxhY/wOrxPNx7ffCK CFdXfjvhIII8euVmTC811OkoXoXTQ3kkc/RrYKfN3JCsvg2z4sDwWe1fVJRYZBVneBuE tjgA== 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-transfer-encoding :content-language; bh=YlALgN9iz0fH/0JhFwGmBm1alFxx2ErY0cUmxLmeN8M=; b=Tr9IUI2BK+26GzlDQDRI7BOCbIi3bdFDQ0EY7tYQIQx6kLOv5JJmSM5Hdyv3rp+gaU gu2TY9Lngy2Xf4uVHEbP98E6lej5q09/NdGlG5mSNH0FLuFAcG3da5kM7UItN8FWcaSA mBuxfwwRPk7Aup6OySlquTXulKees1yMbbemwf9UZKkwHuuqY/KBkuX9pebRt2KUxFWn t1pmYmdJaMiO6m0rgUSoLTNXRysIcBg7JwM8WLC/yWdOUVsKDcy3DszmbfxHLlQ6YGuR NCnmApTXM4TQasgRVnuzsZr8MSqKo0Kot70SJHZBw/PNoprW8YaBrT+vKIkV5xSyXIi7 R1uQ== X-Gm-Message-State: AOAM531dizfLwAnn70Qrrsd+yTqhZLLNMw30Sc7w1kxfsVAbFs08cZi6 FMnm9IOVQuv51ilyQBPoOwh+7Ki8AOkHkw== X-Google-Smtp-Source: ABdhPJw2OQrfA1S2I1Ar2as6eBpbNRPqMPPzt5nkolK4U3+OWpoJEealmhTYwc3YOqLQf4LOFEhY+g== X-Received: by 2002:a17:902:b7c2:b029:d9:c8f:e06b with SMTP id v2-20020a170902b7c2b02900d90c8fe06bmr4313821plz.29.1606331262378; Wed, 25 Nov 2020 11:07:42 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id fh22sm4000806pjb.45.2020.11.25.11.07.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 11:07:41 -0800 (PST) To: Douglas Foster , dmarc@ietf.org References: <20201124020453.AFDC027CE5C8@ary.qy> From: Michael Thomas Message-ID: <045b64e2-cd61-06a1-07bc-5b8cfd231553@mtcc.com> Date: Wed, 25 Nov 2020 11:07:40 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:07:49 -0000 On 11/24/20 7:27 PM, Douglas Foster wrote: > > > In my opinion, ARC does leave a lot of unanswered questions about how > you use the data that ARC provides.   Again, the big organizations > have the brain power at their disposal to figure that out for > themselves, later. > They've had that data for over a decade from what I can tell. The exact same data that ARC provides, but perhaps a little hard to tease apart in some edge cases. Mike From nobody Wed Nov 25 11:11:32 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6255E3A15F1 for ; Wed, 25 Nov 2020 11:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FfEcYTOfOeU0 for ; Wed, 25 Nov 2020 11:11:28 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B823A3A15F0 for ; Wed, 25 Nov 2020 11:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606331486; bh=ekWM7hV/pVzjxu5VpZxk5GF9EVZFZQp9IZf20/BDQKo=; l=2496; h=To:References:From:Date:In-Reply-To; b=BIh2wGgKdbyZL9jNWI/7yZehbKm7L0cvIcgcLNTsSHZnVvGjm5ouS1LHkn9Q7ko/z Kb9IASxNKdggroDJPUwdy7QjmFJ4TsTnSla3VpZBIQ8Lhsyv6HJdz4Ghl3lbLukOty IRbXc78nmu7drW7pTOMs4ZP0qlabs83eU/zNtvh3jGzSZVOlYe7loMgdUCY1+ Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0CE.000000005FBEAC5E.00007971; Wed, 25 Nov 2020 20:11:26 +0100 To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> From: Alessandro Vesely Message-ID: <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> Date: Wed, 25 Nov 2020 20:11:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:11:30 -0000 Hi, On 25/11/2020 19:24, Jesse Thompson wrote: > On 11/25/20 11:30 AM, Alessandro Vesely wrote: >> Without resorting to ARC, it is still possible to validate author domain's signatures directly if the MLM just adds a subject tag and a footer, like, for example, this list does.   While ARC solves "deep" forwarding problems, which may arise in the context of email address portability, MLM transformation reversion solves the simpler mailing list problem, including reverting munged From:'s. > > I agree that ARC isn't really needed to do this (trust the last hop from the MLM and determine the original authenticity from the MLM's perspective) I didn't mean to trust the MLM. I meant remove the subject tag and the footer, then the original DKIM signature verifies. See: https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ > Plus, if it eventually solves the "deep" forwarding issue, then ARC is certainly better than trying to follow received header chains, etc. IMHO, that's where the real value or ARC lies. Large mailbox providers forward lots of messages to one another, as set up by users, and they seem to prefer to forward messages anyway rather than filter before forwarding. That's what John reported in: https://mailarchive.ietf.org/arch/msg/dmarc/OmTzwzP9GuE1oF5m1TvUZVA799c > Anecdotally, after much debate, our team is leaning more towards *not* reverting munged From:'s from our own MLM > > 1. Until ARC has a reputation model that is commonly adopted, header munging isn't going to subside. I still find MLM operators who are just now realizing that they have to munge messages. We need to tell users that this is the new, growing, reality. Yup. > 2. If we only unmunge for our own domains' users' authoring messages to our own MLM, it has limited overall effect, and it distorts the user-reality story from point #1. We would have to unmunge for all domains' authors sending to all "trusted" MLMs in order to give the users what they expect from their prior reality. > > 3. Since we can only unmunge for our own recipients, it just creates an inconsistent experience on top of the already inconsistent experience of the conditional munging most MLMs do based on the authors' DMARC policies. If the original signature verifies, each MDA can restore the unmunged From: right before committing to local storage. That way, the rewritten From: becomes a transfer artifact, not seen by users. Best Ale -- From nobody Wed Nov 25 11:16:40 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254C3A1610 for ; Wed, 25 Nov 2020 11:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 YxH-ovW8qBHn for ; Wed, 25 Nov 2020 11:16:37 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CE73A160F for ; Wed, 25 Nov 2020 11:16:37 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id w187so3253695pfd.5 for ; Wed, 25 Nov 2020 11:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GM5NcBr60rHlp90ShYKruHQaSY9828NSzHze1Q6RgkU=; b=q7l9OWO0ERU5rdFEWf0cWLea5XHgGcDyejM+nvTJ230194go2NeBWVMm1BmeVsX6xH 5ouk7RUrgeyQJeBnWYz/r/Y7eigmzCbGQ42cgT8+R++tar7BZJxqxwWQlTPSxf5vZzVD hrs1EWlHwdJB3anpgAUIjP/Y5EKfTeH82dZks+pFUcVGEDJ4hmhfl/tYBngA2W0BpoyP dHRmjIA6v1FtAGK5QbWzc0l78lhlQbWxq92d71yQjETckYjtHjCUlMudW5/AAqmyp31V /znwVSfb5aYBMagZpyzKjDasXH7kmqqQGc2Jby+5hrFaDt/3mvmDlULn2j+SD8D2C6ip 6Bsw== 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-transfer-encoding :content-language; bh=GM5NcBr60rHlp90ShYKruHQaSY9828NSzHze1Q6RgkU=; b=J2eCjHQucFhTAlVJXhYkAMKRVRu68toNnjKxg0SoUx4aNIDGuB6kcFQM/8r+B+7EqV 3/cbT5C6kVW+XtJH61sObVwovN63NYm8+T8z23vHiKbG2FFYqfxEGJxtFcZHkGmNhXsT fUNdAQp6gExPP36mshv+WT8N/1suklWdwUFN/TjJrgalXyB59dmOByVFmh4c7m4p38Fk nGP+kucdl5WdXwJBKT2pN49a6BXpAcS18hGfxzarqaUVyM3CHAjPafaC6simZDzgDepG Q+CkEAJHPQK1qTp9sh9OAYeR5xF+9i2HJrvNe1lISYoe82h7+vWt+I1wJKTjDK2Ika4O 0I1A== X-Gm-Message-State: AOAM533b1l5oD6jOCs8CEiwsYViaoFqqsMDNZ3TyA71qKrk9f5r0NONg ENSmxat3ppiF8ybRlxuSpS0Z1xXX9xmQWA== X-Google-Smtp-Source: ABdhPJweBzGwRj2o62ZMw0qtw3f9LQpqXbPKOuUj56lK5i7Y26CvqruMD7Oge65WqjIpkdQVFXkVsQ== X-Received: by 2002:a17:90b:4906:: with SMTP id kr6mr6052778pjb.85.1606331796348; Wed, 25 Nov 2020 11:16:36 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id c2sm2691299pfi.21.2020.11.25.11.16.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 11:16:35 -0800 (PST) To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> From: Michael Thomas Message-ID: Date: Wed, 25 Nov 2020 11:16:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 19:16:39 -0000 On 11/25/20 11:11 AM, Alessandro Vesely wrote: > Hi, > > On 25/11/2020 19:24, Jesse Thompson wrote: >> On 11/25/20 11:30 AM, Alessandro Vesely wrote: >>> Without resorting to ARC, it is still possible to validate author >>> domain's signatures directly if the MLM just adds a subject tag and >>> a footer, like, for example, this list does.   While ARC solves >>> "deep" forwarding problems, which may arise in the context of email >>> address portability, MLM transformation reversion solves the simpler >>> mailing list problem, including reverting munged From:'s. >> >> I agree that ARC isn't really needed to do this (trust the last hop >> from the MLM and determine the original authenticity from the MLM's >> perspective) > > > I didn't mean to trust the MLM.  I meant remove the subject tag and > the footer, then the original DKIM signature verifies.  See: > https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ When I was at Cisco, with l= and some subject line heuristics I could get probably like 90+% verification rate across the entire company, a company that uses external mailing lists a lot. Definitely not 100% though. Mike From nobody Wed Nov 25 12:31:45 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9F03A047D for ; Wed, 25 Nov 2020 12:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=F2/PJ6jG; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=dNFPom3J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2cMRjjV5d4V for ; Wed, 25 Nov 2020 12:31:41 -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 81F7A3A0475 for ; Wed, 25 Nov 2020 12:31:40 -0800 (PST) Received: (qmail 37750 invoked by uid 100); 25 Nov 2020 20:31:38 -0000 Date: 25 Nov 2020 20:31:38 -0000 Message-ID: From: "John Levine" To: dmarc@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=936d.5fbebf2a.k2011; i=news@user.iecc.com; bh=JkLB0z8UNQZdkZs/f4b7aiddYrJ+f+XjHeUb9Pi0YRU=; b=F2/PJ6jGPhY02t3MJ9SM/4jMjAMlW2FtDpg+u7rzPQc9JEyyenPYsVGbAC1/mLy1WHTs9gMWeZvqw2SOe9ceLOZpo63IBd86Wxy1B8n1GiyEx/mQ7LG7FnLllUkBNHZ2QhinoroGVPk0B2/hCGxJPST7bCAxPlV+agcOhJLUsPMg7NJKwP7Ck0mJ6S5mqRAuhuEn2sMc5dPGqpNgBxRI0pLOdMZJ9CYHggVKJlSUl7dwMdJRHkNcSsFEc33rZmGVjpcgBDc6NE6ldeN4XlWL7uOt6oJ5ej82kg3fJjQ0dr5PHp9ItiXmG1SkJy/7sziHDybZcT0uE3jIefjsiR7mOA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=936d.5fbebf2a.k2011; olt=news@user.iecc.com; bh=JkLB0z8UNQZdkZs/f4b7aiddYrJ+f+XjHeUb9Pi0YRU=; b=dNFPom3J+5uRx7zq6pOiPxc1tTDqw9wjxUEY+GET2sC799waksIthP/lt/puxKhEwOCORtiI+QhufLT+RD2rYX/en0+XgaM1caFPvdV4ZeQrPfGskIj7ao5HqSxjUMXhfcqyJznHpAatexp7iVGopeU8HTcQGfLeRbcsdP2EpRZrasiG/YAjdUsdOz8fp8S4yI6wsKJdlA+9yCgo3gse3/OOEdS7CO3AlLS6yTBUAZcCIKdYi65HJp9A4ylLzJ7UyksewFv+iBSR2yKwH+dEvD5otKDiBoT/vMhii7NDxS/da6SG88hynXn5clF0eH8zkmRGk95FKhy85+0k/sZ9fA== Organization: Taughannock Networks References: <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> In-Reply-To: <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 20:31:44 -0000 In article , Michael Thomas wrote: >When I was at Cisco, with l= and some subject line heuristics I could >get probably like 90+% verification rate across the entire company, a >company that uses external mailing lists a lot. Definitely not 100% though. I think you will find that at very large mail systems like gmail and Microsoft and Yahoo, 90% might as well be 0%. The volume of errors is just too high and the number of complaints would be impossible. While I almost never see the sort of spam leakage through mailing lists that Brandon reports, I believe him when he says it's enough of a problem that Gmail can't just whitelist traffic from mailing lists. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Nov 25 12:37:43 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AFC3A1CA9 for ; Wed, 25 Nov 2020 12:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 WbwjveOI6T_t for ; Wed, 25 Nov 2020 12:37:40 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 C84843A1CB1 for ; Wed, 25 Nov 2020 12:37:38 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id t21so3447112pgl.3 for ; Wed, 25 Nov 2020 12:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=9DmZ9DgQwgVOcJzyl4hBlH5T/HdZntglJg9UNZWdebg=; b=o2luRFrsvN1WS9HPh3m86tJQ1dM0tAtf8DslnqaulULfEuNzYUv8a6AaTn44OgSMwn VI7zk+8X/LkLYH9mm8jife+TXiSjKnoDok0WnuZVSjw+Qaghs+sIZdXRTH1XPavUq8vw jqjgktG1u09dtifYkQG4u8xpft2Jyo0rp+PFUfYHvbJgC5J43xal4js1/osVie+VHOYq dmdJ8L5RABl6dQtehHaaVXSuZj2ztKyXfqHUak9kd4fRDr7lu132n7Ja9IotVH2v0NXq fxp2+bPjVhWCPX6ZRza0IK+5KJSugSB73bEdgV7IoHTMuBOtTg7IA/Som/Qly0XRwq3s Jclg== 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-transfer-encoding :content-language; bh=9DmZ9DgQwgVOcJzyl4hBlH5T/HdZntglJg9UNZWdebg=; b=muRyw3P2fzGMI7rjmdZ1kFI+wSGTET24ZNzGV8r1229C7KhcDej6nxWmlAVVF2jlfk +GV3QZ95njDpbowDJmxmbj9PMakRlVt1J5DUeJJDa5nGa2vt0Z0dqsJ6+rQCTdROMNfw /FiezQQK1A+O3Z9gDbl9ydDlNZmsDFGZ/AbxGr7afQWqH7n7c98hk7Dt96adJAMeDW7S q1qCv49mQwzygkkk0FixILXjS75kayYP+LZJ1qP3DcbmnoDex6cmPHsn+06Jbhn62dIs iakPz6Fesb/3sUYeKXzVcoiHLf7Azz6rEZTEU2S0o54JOtTZj103fLqA/MPJGeAjZerg J2Aw== X-Gm-Message-State: AOAM530Ep/Izg1Kk2l5cy87guOR/bDnwstZHV9IbDWgFnh7DIMP8orE6 mOW4UXu5JBo9lTJtIfPXMD8Sazs/R5WCJA== X-Google-Smtp-Source: ABdhPJwiCRpqiCIShRXmCpiOcCEZaKU6VNUCKzd6cxuK3UJcmpw+PP/bQrA9o0N0AWER0uwhWf15Vw== X-Received: by 2002:a65:56c8:: with SMTP id w8mr4401869pgs.383.1606336657845; Wed, 25 Nov 2020 12:37:37 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id k23sm2682496pfk.50.2020.11.25.12.37.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 12:37:36 -0800 (PST) To: dmarc@ietf.org References: <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> From: Michael Thomas Message-ID: <695b8714-b174-e3d6-d6c0-1a1d535fb08c@mtcc.com> Date: Wed, 25 Nov 2020 12:37:35 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 20:37:42 -0000 On 11/25/20 12:31 PM, John Levine wrote: > In article , > Michael Thomas wrote: >> When I was at Cisco, with l= and some subject line heuristics I could >> get probably like 90+% verification rate across the entire company, a >> company that uses external mailing lists a lot. Definitely not 100% though. > I think you will find that at very large mail systems like gmail and > Microsoft and Yahoo, 90% might as well be 0%. The volume of errors is > just too high and the number of complaints would be impossible. > > While I almost never see the sort of spam leakage through mailing lists > that Brandon reports, I believe him when he says it's enough of a problem > that Gmail can't just whitelist traffic from mailing lists. > Not everything is service provider. We were investigating this from an enterprise standpoint. And if you can't trust mailing traffic from providers what is the point of ARC? Mike From nobody Wed Nov 25 12:55:57 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1CD3A1D3B for ; Wed, 25 Nov 2020 12:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=kEuO6AQu; dkim=pass (2048-bit key) header.d=taugh.com header.b=djzomvIi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJWxJnhlNjsv for ; Wed, 25 Nov 2020 12:55:55 -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 D16303A1D3A for ; Wed, 25 Nov 2020 12:55:54 -0800 (PST) Received: (qmail 45095 invoked from network); 25 Nov 2020 20:55:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=b025.5fbec4d9.k2011; bh=XpyGIYFAqwIxOjDtRbYi2g/VXVIG9IJWaIemS0Y9ozM=; b=kEuO6AQuO2E8nME3IbcH5WHExLJ/17C/uLhtmG7toeaQeNNOLQJrPn3cD024Bp8w4b7vKwkKOfzhDkGcBVG3l2LYv2knwKRUpymF3cCMzsnLYUOWbaUx8HUcPMm+MEgT+EdGxN/tzHGd61Kl7bstG63kjssDSj4bt9fkt0mYVjaaYy4DBaXbwoqKDPiqCuv3qLCi/cQKInZHybYDnvvElkBPyWJ4xb6SMLXGTbSZhIi5JJ0380tcTmvnNvXG2RvwVNEokQfOeVWoMOHRQHG6nkhcScSpS73h3Pz71Yuwz4nJ0JhnwEMsPlPszaLZtP05S1BfdVXxi2uKZKbv2xJkUA== 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:cleverness; s=b025.5fbec4d9.k2011; bh=XpyGIYFAqwIxOjDtRbYi2g/VXVIG9IJWaIemS0Y9ozM=; b=djzomvIi5GpsQBH+btHmmmCnW97Os59ksmMrXwr83o+KUFTv1odLzq+eGMktttz+vi7NCnaLJPmqj8mkJeofdOqR47LwePNj4s2p0DO6vbBbwlum0m+EU/gfxk3JXRojZNv5PGhNFQ4eLdH37QvHkIgjRjViSJrribMTK9GrDDJ01pv7U+2XvP4IuRdU2N9qVMokeXfeHiS88/6opov0Ze5IrxQv0If4J5/ueRfWX1jywseE+1n5ohbsZQfDBCWpwa+N20NB2Vy4ro3e/41yPYn6fYRWx2iYTVC2DiELltZJUEsSL+uyO6EpOd31DOaftDZPY3KuLFWyAVdleUYLVQ== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Nov 2020 20:55:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 3539128030B9; Wed, 25 Nov 2020 15:55:52 -0500 (EST) Date: 25 Nov 2020 15:55:52 -0500 Message-Id: <20201125205553.3539128030B9@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: <695b8714-b174-e3d6-d6c0-1a1d535fb08c@mtcc.com> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 20:55:56 -0000 In article <695b8714-b174-e3d6-d6c0-1a1d535fb08c@mtcc.com> you write: >Not everything is service provider. We were investigating this from an >enterprise standpoint. > >And if you can't trust mailing traffic from providers what is the point >of ARC? Um, please see the previous umpteen messages describing how ARC works and how it addresses this particular problem. R's, John From nobody Wed Nov 25 16:14:51 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112CB3A0DCF for ; Wed, 25 Nov 2020 16:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGA08m7VId-A for ; Wed, 25 Nov 2020 16:14:40 -0800 (PST) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 AE8533A0DEA for ; Wed, 25 Nov 2020 16:14:40 -0800 (PST) Received: by mail-ua1-x932.google.com with SMTP id q68so19650uaq.3 for ; Wed, 25 Nov 2020 16:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FUE/5SxgVjFskiyhriZkOZMiFNvooubVh/siTf/zorg=; b=nPW2etGPpdjhjorGgY+ahl2Cni2TIoNdUnUx+lWOdQQgABLvPha5iWfAm6R3uvTsL/ INDKpfgMSEJzpYgKtqTY1tC5/6W0RroEWy/0l+RJDoBdI61vpj6AAj8OLLEj19KMKyM5 x4hyKhT6QPWC1Fbnb3f+OQjo6Aux60bxF0oRtFoROyxUT7MjcwZAL5YpHlMhIcmG3BY2 0/l0UYUQRM1jFQKZu0OQvu95vH5oKe1HdZ9rSLoLPTk/B+ocdnJt3vvTuRnKDstY0X1A C8YVsI/tATfEjFHk2+odrVbD4hTINjJvWLUsb72cKyURbJLVeZxPEpgDBzA+3leNaSIu XLYw== 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=FUE/5SxgVjFskiyhriZkOZMiFNvooubVh/siTf/zorg=; b=HvQE1T01F6E7bB9ivFrfejfmCe6Oe8nnfnM48b2mMDlCexjYag/xoqcvGmufs9pUtA ShdmteEsIB8sMqKHo4RtWiZdsOGhJTlp9vk6AJwFtczE9y00SOjXWT8LwsAKJLdxvtJh 6d3/+8YxIo5e5jIR0X111JvkSF/zvolAeLv4mdZXblGaJCfrEBboRyvJkJMhmjbZE3oo i9mvaUpNFFDT3okWTpD7gIFGN0hnjOC5W2+tredvy7rJyYm5HxmbIRXxqKfNlZkfZeNJ YpRXjhM7jciHuQbuOlpe/IFWsYnNJVCL/tJrOuwo2kmEZe4ZCZ7CO1jrd2p1UT9gr6P1 XWPw== X-Gm-Message-State: AOAM530HJcDYBqxik2WHqek6sOVHD81YZs1C+rx6hKdF1uUyxzqdRLhS hDm2xLgwP+4kjK2M7gSMPxpROH9Dr4Ac8BIL60U= X-Google-Smtp-Source: ABdhPJwZJHC7Qj60rOa4XQmUDUzbDnAVsblqL02+eioRi5GR/lW5COviS8PeQnRMh2BrZPgAzzjFIdAvSDiJeP8SwIA= X-Received: by 2002:ab0:2109:: with SMTP id d9mr339033ual.76.1606349679505; Wed, 25 Nov 2020 16:14:39 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 25 Nov 2020 16:14:27 -0800 Message-ID: To: Michael Thomas Cc: Douglas Foster , IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000008339f05b4f76ea7" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 00:14:50 -0000 --00000000000008339f05b4f76ea7 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas wrote: > On 11/24/20 8:19 PM, Murray S. Kucherawy wrote: > > On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster < > dougfoster.emailstandards@gmail.com> wrote: > >> Michael, I think the purpose is stated well enough: Mailing lists want >> to keep adding their content to messages, without being blocked by >> recipients. This means that they have to provide recipients with enough >> information for them to accept the forwarded content. Google and >> Microsoft seem to be on-board with this project, so it seems pretty >> successful already. This train is not easily stopped. >> > > That sounds about right. Put another way: DMARC's success is at least in > part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to > carry forward from the MLM, in a credible way, an indication of what the > MLM saw in terms of DKIM results when the message got to the MLM. So then, > although an author signature will fail post-MLM, the MLM signature will > pass, and the ARC data will tell you that the author signature was good > when the MLM got it. If you trust the chain, then that can be an > alternative to the DKIM input when the final recipient performs a DMARC > evaluation. > > That's been known for over 15 years. I'm still trying to understand the > assertion that DKIM signatures are a "bad fit". I just looked at a random > message off of this thread and they look identical except for the i= field. > another field could trivially be added to DKIM and auth-res -- since > unknown fields are supposed to be ignored -- if this binding property is > absolutely needed, which I remain unconvinced by as well. > I'm not sure about "bad fit". The original plan was to have an Authentication-Results (AR) clone called Original-Authentication-Results (OAR) which was specifically the AR content generated at the first non-submission MTA. There was some friction (mostly from me, as I recall) about having two header fields with identical syntax and nearly identical semantics. There was further complication in the fact that one ADMD could apply multiple ARs on a single message (for multiple methods, or multiple instances of the same method, or a combination of those), or they could be reordered, etc. To make it more resilient, things like instance numbers were added. The work was eventually generalized to be a "chain of custody" sort of model, and in doing that I think the decision was made to make a new name to ensure ARC and DKIM would be processed differently. I imagine it could've been done as an Applicability Statement over DKIM and AR, but I'm not sure now whether that would've been simpler. > If you ask me, part of the experiment should be able to show use cases > that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address that > ARC can, and most especially what percentage of email traffic we're > actually talking here. As far as I can see ARC doesn't bring anything > especially new for the mailing list kind of use cases since it really easy > to see who the intermediary was that broke the signature. I have been told > there are some vague other kinds of use cases but is unclear whether those > use cases actually happen before or after the message arrives at the front > door of the final receiving domain. Yes, i read section 7, but it doesn't > tell me why this can't be handled with current technology. > > Obviously it's too late to include this in RFC 8617, but those would indeed be interesting data to have. When you say "easy to see", do you mean for software or for humans? > It seems to me that the lynchpin is whether I trust the domain that broke > the signature and resigned. That's either a previously solved or unsolved > problem depending on your perspective. If I trust the intermediary domain > to not send me spam via reputation, I forward it along to be delivered and > ignore the DMARC record. Why do I care whether it originally validated from > the sending domain or not? If you ask me, that's the intermediary domain's > problem since they have an incentive to keep their reputation and not send > spam through. > Suppose you're sending to a list that I'm on, I enforce DMARC, I trust that MLM not to send spam via reputation, you have a good reputation, and you publish a DMARC "reject" policy. That means if a bad actor sends a message to the list as you but doesn't sign it at all, I'll still accept it because I trust that MLM even though according to your policy request, I should bounce it. ARC provides the missing data I need to enforce your request. If the MLM enforces DMARC, that's slightly better, but I think ARC was meant to be an incremental drop-in for MLM operators that don't (or won't) do DMARC. -MSK --00000000000008339f05b4f76ea7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 25, 2020 at 11:03 AM Michael = Thomas <mike@mtcc.com> wrote:
=20 =20 =20

On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
=20

=20
On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster <dougfoster.emailstandards@gmail.com> wrote:
Michael, I think the purpose is stated well enough:=C2=A0 =C2=A0Mailing lists want to keep adding their c= ontent to messages, without being blocked by recipients.=C2=A0 =C2= =A0This means that they have to provide recipients with enough information for them to accept the forwarded content.=C2=A0 =C2=A0Google and Microsoft seem to be on-board with this project, so it seems pretty successful=C2=A0already.=C2=A0 = =C2=A0This train is not easily=C2=A0stopped.

That sounds about right.=C2=A0 Put another way: DMARC's success is at least in part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to carry forward from the MLM, in a credible way, an indication of what the MLM saw in terms of DKIM results when the message got to the MLM.=C2=A0 So then, although an author signature will fail post-MLM, the MLM signature will pass, and the ARC data will tell you that the author signature was good when the MLM got it.=C2=A0 If you trust the chain, then that can be an alternati= ve to the DKIM input when the final recipient performs a DMARC evaluation.

That's been known for over 15 years. I'm still trying to understand the assertion that DKIM signatures are a "bad fit&quo= t;. I just looked at a random message off of this thread and they look identical except for the i=3D field. another field could trivially be added to DKIM and auth-res -- since unknown fields are supposed to be ignored -- if this binding property is absolutely needed, which I remain unconvinced by as well.

I'm not sure about "bad fit".=C2=A0 The original plan was to= have an Authentication-Results (AR) clone called Original-Authentication-R= esults (OAR) which was specifically the AR content generated at the first n= on-submission MTA.=C2=A0 There was some friction (mostly from me, as I reca= ll) about having two header fields with identical syntax and nearly identic= al semantics.=C2=A0 There was further complication in the fact that one ADM= D could apply multiple ARs on a single message (for multiple methods, or mu= ltiple instances of the same method, or a combination of those), or they co= uld be reordered, etc.=C2=A0 To make it more resilient, things like instanc= e numbers were added.=C2=A0 The work was eventually generalized to be a &qu= ot;chain of custody" sort of model, and in doing that I think the deci= sion was made to make a new name to ensure ARC and DKIM would be processed = differently.

I imagine it could've been done a= s an Applicability Statement over DKIM and AR, but I'm not sure now whe= ther that would've been simpler.
If you ask me, part of the experiment should be a= ble to show use cases that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address that ARC can, and most especially what percentage of email traffic we're actually talking here. As far as I can see ARC doesn't bring anything especially new for the mailing list kind of use cases since it really easy to see who the intermediary was that broke the signature. I have been told there are some vague other kinds of use cases but is unclear whether those use cases actually happen before or after the message arrives at the front door of the final receiving domain. Yes, i read section 7, but it doesn't tell me why this can't be handled with current technology.
Obviously it's too late to include this in RFC 8617, but those would = indeed be interesting data to have.

When you say &= quot;easy to see", do you mean for software or for humans?

It seems to me that the lynchpin is whether I trust the domain that broke the signature and resigned. That's either a previously solved or unsolved problem depending on your perspective. If I trust the intermediary domain to not send me spam via reputation, I forward it along to be delivered and ignore the DMARC record. Why do I care whether it originally validated from the sending domain or not? If you ask me, that's the intermediary domain'= s problem since they have an incentive to keep their reputation and not send spam through.

Suppose you're = sending to a list that I'm on, I enforce DMARC, I trust that MLM not to= send spam via reputation, you have a good reputation, and you publish a DM= ARC "reject" policy.=C2=A0 That means if a bad actor sends a mess= age to the list as you but doesn't sign it at all, I'll still accep= t it because I trust that MLM even though according to your policy request,= I should bounce it.=C2=A0 ARC provides the missing data I need to enforce = your request.

If the MLM enforces DMARC, that's slightly b= etter, but I think ARC was meant to be an incremental drop-in for MLM opera= tors that don't (or won't) do DMARC.

-MSK
--00000000000008339f05b4f76ea7-- From nobody Wed Nov 25 16:52:37 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DDE3A0E49 for ; Wed, 25 Nov 2020 16:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 BDel_ml9l2X7 for ; Wed, 25 Nov 2020 16:52:34 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 020193A0DE0 for ; Wed, 25 Nov 2020 16:52:33 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id r2so286422pls.3 for ; Wed, 25 Nov 2020 16:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=j5+eOemBCuD4uNdQ9bS2v2DmwQX6DGtB9IAFI/Q2xbk=; b=XaR0VL44CXcohbBoDfBsHqBt3Rn77O6k9Dt5DXAQyxpkwBLTw1HtlPQ/Fq0KGhD4Vp ceQBNi+txYvksdUJSnFrVOmS1XrFjPBMxw0SlojekHzS1POiUYyQATFGLFAGKpeNNUv4 w5MfjUOHCOj2jHVtN5VDRcUHyglYY+3mlJfK6yS87jr8Kcvh6f+c9zwr/4s23m8Zi+FH 1O1yYMp0vyjiJOj2TTC8EDlGILIqJPqHIUo3RJM1WydiP7nzpFWt1yAmWtGYrp7eSb2f wzr/WdGWgOPd6/OYaalRz5C9jOwaQ/unOK8FIwKTYvHjno1IdOdgyPdugAUZro7nOy4S Mafg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=j5+eOemBCuD4uNdQ9bS2v2DmwQX6DGtB9IAFI/Q2xbk=; b=Dj0km2xJ55MoPv/HvQiCoOYVUb+AOswYLlqZeGRHYIpUBcc1JQ2s2mi17fxbfY5aeG WaFcZJK+JFZ7HxUf8RIWplbZV1HOEuwGTPLB05msG38EYMPsWuw5Mo96acJIw+D7x68j hycDdhc4NSRhDRIzPxlP+Qp0xkXhKYEYftOangzhLdn8ksMXCN/AYe2w/3H7FIDRnhT9 KtYS9531vuzpFJxB7nFSjtcbo9LZE/YWzHbNgSiQGTQWX4qg/adYzt6UB5P9WPDdxdYE t3UoD04kSLpEgsCdr1eHLZjTR0HPd8n/kqVr7TTvjk6w8nxVA7RoWQEO+dwYNWqsUmgL KOxA== X-Gm-Message-State: AOAM532hOTZItRw0vuVELDlIO87iCR+57poH8Ujl9aFbtOANzzS3/gLL u/ttdqf6IMvCkw4fEqsSXO1NXBz3UsMczA== X-Google-Smtp-Source: ABdhPJym2buVXTiahURVz4Jmz90Hp0KzjTO2CCGcB0SfnOPdjkeIAYM2JxKSmgpHvVGjZQih1DDxHw== X-Received: by 2002:a17:902:b90a:b029:da:655:4208 with SMTP id bf10-20020a170902b90ab02900da06554208mr555804plb.30.1606351952927; Wed, 25 Nov 2020 16:52:32 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id y5sm4153018pjt.42.2020.11.25.16.52.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Nov 2020 16:52:32 -0800 (PST) To: "Murray S. Kucherawy" Cc: Douglas Foster , IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> From: Michael Thomas Message-ID: <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com> Date: Wed, 25 Nov 2020 16:52:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AE311FBA35222659A57C80E4" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 00:52:36 -0000 This is a multi-part message in MIME format. --------------AE311FBA35222659A57C80E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/25/20 4:14 PM, Murray S. Kucherawy wrote: > On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas > wrote: > > > That's been known for over 15 years. I'm still trying to > understand the assertion that DKIM signatures are a "bad fit". I > just looked at a random message off of this thread and they look > identical except for the i= field. another field could trivially > be added to DKIM and auth-res -- since unknown fields are supposed > to be ignored -- if this binding property is absolutely needed, > which I remain unconvinced by as well. > > I'm not sure about "bad fit".  The original plan was to have an > Authentication-Results (AR) clone called > Original-Authentication-Results (OAR) which was specifically the AR > content generated at the first non-submission MTA. There was some > friction (mostly from me, as I recall) about having two header fields > with identical syntax and nearly identical semantics.  There was > further complication in the fact that one ADMD could apply multiple > ARs on a single message (for multiple methods, or multiple instances > of the same method, or a combination of those), or they could be > reordered, etc.  To make it more resilient, things like instance > numbers were added.  The work was eventually generalized to be a > "chain of custody" sort of model, and in doing that I think the > decision was made to make a new name to ensure ARC and DKIM would be > processed differently. But what about DKIM? And why do they need to be processed differently? When I first saw this, I looked at the ARC-Signature which looks identical to a DKIM signature (i didn't notice the i= at the time), and am like what is this? The i= counter could be trivially be grafted onto DKIM if it were needed, which I'm still sort of dubious (though it is a nice to have feature, I admit). That way you only need a single DKIM signature with the OAR's signed. As far as I can tell, that would fall back gracefully for non-implementing DKIM verifiers. Do you disagree? > >> If you ask me, part of the experiment should be able to show use >> cases that DKIM + auth-res (or maybe old-auth-res if needed) >> CANNOT address that ARC can, and most especially what percentage >> of email traffic we're actually talking here. As far as I can see >> ARC doesn't bring anything especially new for the mailing list >> kind of use cases since it really easy to see who the >> intermediary was that broke the signature. I have been told there >> are some vague other kinds of use cases but is unclear whether >> those use cases actually happen before or after the message >> arrives at the front door of the final receiving domain. Yes, i >> read section 7, but it doesn't tell me why this can't be handled >> with current technology. > > Obviously it's too late to include this in RFC 8617, but those would > indeed be interesting data to have. Yeah, quantifying the problems kinda seems like the first order of business if you ask me. I mean, how many of these scenarios are in reality goofy self-inflicted wounds? I can't say but there seems to be a lot more "this can happen" than "this is how often this happens" from what I've see thus far on this thread. > > When you say "easy to see", do you mean for software or for humans? Software. Only software can pry apart that ball of header spaghetti. But I think with the simple a mailing list it is pretty easy to determine, which now that I think about it I actually did back in the day when I was experimenting with recovering mailing list modifications. It didn't occur to me that that was supposed to be hard. > It seems to me that the lynchpin is whether I trust the domain > that broke the signature and resigned. That's either a previously > solved or unsolved problem depending on your perspective. If I > trust the intermediary domain to not send me spam via reputation, > I forward it along to be delivered and ignore the DMARC record. > Why do I care whether it originally validated from the sending > domain or not? If you ask me, that's the intermediary domain's > problem since they have an incentive to keep their reputation and > not send spam through. > > Suppose you're sending to a list that I'm on, I enforce DMARC, I trust > that MLM not to send spam via reputation, you have a good reputation, > and you publish a DMARC "reject" policy.  That means if a bad actor > sends a message to the list as you but doesn't sign it at all, I'll > still accept it because I trust that MLM even though according to your > policy request, I should bounce it.  ARC provides the missing data I > need to enforce your request. Sure, but the easier answer: to use my mailing list, you must have either DKIM, SPF or both. Sounds like a good way to not be essentially an open relay. Don't mailing lists have those sorts of policies these days? I would say that ones that don't probably shouldn't have good reputations since they are, in effect... open relays. Mike PS: it's been, what, 15 years since our interop, partner? :) --------------AE311FBA35222659A57C80E4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/25/20 4:14 PM, Murray S. Kucherawy wrote:
On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas <mike@mtcc.com> wrote:

That's been known for over 15 years. I'm still trying to understand the assertion that DKIM signatures are a "bad fit". I just looked at a random message off of this thread and they look identical except for the i= field. another field could trivially be added to DKIM and auth-res -- since unknown fields are supposed to be ignored -- if this binding property is absolutely needed, which I remain unconvinced by as well.

I'm not sure about "bad fit".  The original plan was to have an Authentication-Results (AR) clone called Original-Authentication-Results (OAR) which was specifically the AR content generated at the first non-submission MTA.  There was some friction (mostly from me, as I recall) about having two header fields with identical syntax and nearly identical semantics.  There was further complication in the fact that one ADMD could apply multiple ARs on a single message (for multiple methods, or multiple instances of the same method, or a combination of those), or they could be reordered, etc.  To make it more resilient, things like instance numbers were added.  The work was eventually generalized to be a "chain of custody" sort of model, and in doing that I think the decision was made to make a new name to ensure ARC and DKIM would be processed differently.


But what about DKIM? And why do they need to be processed differently? When I first saw this, I looked at the ARC-Signature which looks identical to a DKIM signature (i didn't notice the i= at the time), and am like what is this? The i= counter could be trivially be grafted onto DKIM if it were needed, which I'm still sort of dubious (though it is a nice to have feature, I admit). That way you only need a single DKIM signature with the OAR's signed. As far as I can tell, that would fall back gracefully for non-implementing DKIM verifiers. Do you disagree?


If you ask me, part of the experiment should be able to show use cases that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address that ARC can, and most especially what percentage of email traffic we're actually talking here. As far as I can see ARC doesn't bring anything especially new for the mailing list kind of use cases since it really easy to see who the intermediary was that broke the signature. I have been told there are some vague other kinds of use cases but is unclear whether those use cases actually happen before or after the message arrives at the front door of the final receiving domain. Yes, i read section 7, but it doesn't tell me why this can't be handled with current technology.
Obviously it's too late to include this in RFC 8617, but those would indeed be interesting data to have.


Yeah, quantifying the problems kinda seems like the first order of business if you ask me. I mean, how many of these scenarios are in reality goofy self-inflicted wounds? I can't say but there seems to be a lot more "this can happen" than "this is how often this happens" from what I've see thus far on this thread.


When you say "easy to see", do you mean for software or for humans?


Software. Only software can pry apart that ball of header spaghetti. But I think with the simple a mailing list it is pretty easy to determine, which now that I think about it I actually did back in the day when I was experimenting with recovering mailing list modifications. It didn't occur to me that that was supposed to be hard.


It seems to me that the lynchpin is whether I trust the domain that broke the signature and resigned. That's either a previously solved or unsolved problem depending on your perspective. If I trust the intermediary domain to not send me spam via reputation, I forward it along to be delivered and ignore the DMARC record. Why do I care whether it originally validated from the sending domain or not? If you ask me, that's the intermediary domain's problem since they have an incentive to keep their reputation and not send spam through.

Suppose you're sending to a list that I'm on, I enforce DMARC, I trust that MLM not to send spam via reputation, you have a good reputation, and you publish a DMARC "reject" policy.  That means if a bad actor sends a message to the list as you but doesn't sign it at all, I'll still accept it because I trust that MLM even though according to your policy request, I should bounce it.  ARC provides the missing data I need to enforce your request.

Sure, but the easier answer: to use my mailing list, you must have either DKIM, SPF or both. Sounds like a good way to not be essentially an open relay. Don't mailing lists have those sorts of policies these days? I would say that ones that don't probably shouldn't have good reputations since they are, in effect... open relays.

Mike

PS: it's been, what, 15 years since our interop, partner? :)


--------------AE311FBA35222659A57C80E4-- From nobody Thu Nov 26 00:59:06 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4864C3A08B0 for ; Thu, 26 Nov 2020 00:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sMeSlyyTdHe7 for ; Thu, 26 Nov 2020 00:59:03 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657A73A08AE for ; Thu, 26 Nov 2020 00:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606381140; bh=2EriUi+7OJGJ5mO+e8pXorD+QdAloI1PWd2h3+ZV5hE=; l=1568; h=To:References:From:Date:In-Reply-To; b=DhEJuzZIgMuoNqASPWK2YF40tMD+BYm3oHAG1mPG1mpPbEhuN+vGlA2MHLXlSw8tY mCxZ2DLyjRPBLFCqWxLax9hdEpU+CfEe5OIlUC9i8SY84mg7pEANw498imXhWJ+ff0 PPpQoH1HlSdW9hBZSrnv2JWal/FnyheMJQa3B2RY6143udBBw3xy9EXBxruCq Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005FBF6E54.00000702; Thu, 26 Nov 2020 09:59:00 +0100 To: dmarc@ietf.org References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> From: Alessandro Vesely Message-ID: <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> Date: Thu, 26 Nov 2020 09:59:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 08:59:05 -0000 On 25/11/2020 20:16, Michael Thomas wrote: > On 11/25/20 11:11 AM, Alessandro Vesely wrote: >> On 25/11/2020 19:24, Jesse Thompson wrote: >>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: >>>> Without resorting to ARC, it is still possible to validate author domain's >>>> signatures directly if the MLM just adds a subject tag and a footer, like, >>>> for example, this list does.   While ARC solves "deep" forwarding problems, >>>> which may arise in the context of email address portability, MLM >>>> transformation reversion solves the simpler mailing list problem, including >>>> reverting munged From:'s. >>> >>> I agree that ARC isn't really needed to do this (trust the last hop from the >>> MLM and determine the original authenticity from the MLM's perspective) >> >> I didn't mean to trust the MLM.  I meant remove the subject tag and the >> footer, then the original DKIM signature verifies.  See: >> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ > > When I was at Cisco, with l= and some subject line heuristics I could get > probably like 90+% verification rate across the entire company, a company that > uses external mailing lists a lot. Definitely not 100% though. DKIM itself is not 100%. You always have lines beginning with "From " or occasional autoconversions. l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: base64. In addition, the DKIM spec discourages its usage and suggests that "Assessors might wish to ignore signatures that use the tag." Best Ale -- From nobody Thu Nov 26 01:56:47 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E35D3A0FFD for ; Thu, 26 Nov 2020 01:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12SrTGfDAY_r for ; Thu, 26 Nov 2020 01:56:44 -0800 (PST) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 BB5C13A0FFA for ; Thu, 26 Nov 2020 01:56:44 -0800 (PST) Received: by mail-vk1-xa2e.google.com with SMTP id b190so347155vka.0 for ; Thu, 26 Nov 2020 01:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3IHNin2SqjRcKVYR5kjZam/+TtdMzP8N5/rtgMPpE+Q=; b=otE8lpaMlJqBoqxe2MbJZnw4SuiEfH2t4Tb2k9TidJJ8CY8mSSvAGTEbBypZxhP09C pVR+sRJCcyE+jdDWdSi8ADCS7OvepsVtzxVqBNmENLzWEsxEwWLJfIyuAe5jEyphplIr NVgW4NuNNiJc81Y90AAl1r7UXrN6+InqiC4ls3lT1WGs0ZcSUkJ9tPMzafN9qx+wgmeW KdmfKVlgBb3MKoVKYscHFn+e1qzib1mq7iy76NsHgvGcY6mu+28yM1XPGRHpfY+3F2M3 bL/w43y4rbBwt7nrr909zeoQSPqylRgXNQLVRHVK5VpTjZRqUfZYQB+0P9o163EQOrZ6 mzbA== 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=3IHNin2SqjRcKVYR5kjZam/+TtdMzP8N5/rtgMPpE+Q=; b=S34FgKiL0ZUWbfQQfbqNglNT3qkuX+ui6iga64a7Ft2Nca0s0MzYU/n74I1Y7ddxFa rsrSINe4MsPzQVmvyVWr3mNDeIOO9uu4lV0/p9oEASxV6GoGF15fP1O5qVV1RUGXrO1y j0Jr28o++VBuiMb9K7R+HKGBIyLUrlEYhqgQvQYiztEmzVpU7w0zXz98HB9uwuUXPgnM kQmIFC5JLuMc1y4D6a0ll0zIRJ/pvmQcce79QbSIBoZKHrbKrLRM8MtHUCa9go3IwtzK pqBShV8zhWEwkWLwtYVm2B1XbcflousySa8r5+pDOQb+mcVbDmCY+qJrDuONX7BnqntQ D6iQ== X-Gm-Message-State: AOAM530iLK/IsCqufkKwIqV0TCYX4PrQ3s7lqiwIC4k8use6tKiM6ZTu mXjl8jqXJaKNN1prvaxTt7yFSHkosOeyGU8IgesV49S1 X-Google-Smtp-Source: ABdhPJycQ0lGo6sQTjur+CcvsXk+E/pkhaFNMHtXAVu6oaVHnR8aYCYeAgNB/Y8L/Sac9NurczVXtpPAoL/gamnXWpQ= X-Received: by 2002:a1f:d907:: with SMTP id q7mr1153876vkg.14.1606384603693; Thu, 26 Nov 2020 01:56:43 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com> In-Reply-To: <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com> From: "Murray S. Kucherawy" Date: Thu, 26 Nov 2020 01:56:32 -0800 Message-ID: To: Michael Thomas Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000ad052105b4ff8f15" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 09:56:47 -0000 --000000000000ad052105b4ff8f15 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas wrote: > But what about DKIM? And why do they need to be processed differently? > When I first saw this, I looked at the ARC-Signature which looks identical > to a DKIM signature (i didn't notice the i= at the time), and am like what > is this? The i= counter could be trivially be grafted onto DKIM if it were > needed, which I'm still sort of dubious (though it is a nice to have > feature, I admit). That way you only need a single DKIM signature with the > OAR's signed. As far as I can tell, that would fall back gracefully for > non-implementing DKIM verifiers. Do you disagree? > ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking. We landed at what became ARC. I suppose an appendix might've been nice enumerating everything that was considered and discarded, but that record doesn't really exist. What that means is that I couldn't tell you now why we rejected a pure DKIM/OAR solution to this specific problem, but I know it was considered. Maybe others who helped with RFC 8617 remember. > > Yeah, quantifying the problems kinda seems like the first order of > business if you ask me. I mean, how many of these scenarios are in reality > goofy self-inflicted wounds? I can't say but there seems to be a lot more > "this can happen" than "this is how often this happens" from what I've see > thus far on this thread. > Where do you suggest we go from here? > > When you say "easy to see", do you mean for software or for humans? > > Software. Only software can pry apart that ball of header spaghetti. But I > think with the simple a mailing list it is pretty easy to determine, which > now that I think about it I actually did back in the day when I was > experimenting with recovering mailing list modifications. It didn't occur > to me that that was supposed to be hard. > I haven't put hand to coding keyboard on this problem yet, but I'm trying to imagine how it would be easy to determine (a) that Subject had been modified (for example), (b) what the specific modification was, and (c) which hop did it. You could say a message failing to validate an author signature with "[...]" at the front of Subject was likely tagged by an MLM, or that everything after "--" should be ignored, or that those probably happened at non-submission hop #1, but those are heuristics, and I think we're hoping for something more deterministic. The 80/20 rule isn't sufficient. But it's late and maybe I'm missing something. What did you have in mind? > Sure, but the easier answer: to use my mailing list, you must have either > DKIM, SPF or both. Sounds like a good way to not be essentially an open > relay. Don't mailing lists have those sorts of policies these days? I would > say that ones that don't probably shouldn't have good reputations since > they are, in effect... open relays. > That requires MLMs to change their behavior, which I believe is something all of these protocols are hoping to avoid (or, at least, MLMs should decide that on their own, not because the IETF forced them to by wielding DMARC and ARC at them). > Mike > > PS: it's been, what, 15 years since our interop, partner? :) > 2007. Still got the t-shirt. -MSK --000000000000ad052105b4ff8f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 25, 2020 at 4:52 PM Michael T= homas <mike@mtcc.com> wrote:
=
=20 =20 =20
But what about DKIM? And why do they need to be processed differently? When I first saw this, I looked at the ARC-Signature which looks identical to a DKIM signature (i didn't notice the i= =3D at the time), and am like what is this? The i=3D counter could be trivially be grafted onto DKIM if it were needed, which I'm still sort of dubious (though it is a nice to have feature, I admit). That way you only need a single DKIM signature with the OAR's signed. As far as I can tell, that would fall back gracefully for non-implementing DKIM verifiers. Do you disagree?

ARC was developed over months, even before this WG start= ed, and I remember all of these conversations happening involving the quest= ions you're now asking.=C2=A0 We landed at what became ARC.=C2=A0 I sup= pose an appendix might've been nice enumerating everything that was con= sidered and discarded, but that record doesn't really exist.

What that means = is that I couldn't tell you now why we rejected a pure DKIM/OAR solutio= n to this specific problem, but I know it was considered.=C2=A0 Maybe other= s who helped with RFC 8617 remember.
= =C2=A0
Yeah, quantify= ing the problems kinda seems like the first order of business if you ask me. I mean, how many of these scenarios are in reality goofy self-inflicted wounds? I can't say but there seems to be a lot more "this can happen" than "this is= how often this happens" from what I've see thus far on this thread.

Where do you suggest we go from her= e?
=20

When you say "easy to see", do you mean for softwa= re or for humans?
=20

Software. Only software can pry apart that ball of header spaghetti. But I think with the simple a mailing list it is pretty easy to determine, which now that I think about it I actually did back in the day when I was experimenting with recovering mailing list modifications. It didn't occur to me that that was supposed to be hard.

I haven't put hand to = coding keyboard on this problem yet, but I'm trying to imagine how it w= ould be easy to determine (a) that Subject had been modified (for example),= (b) what the specific modification was, and (c) which hop did it.=C2=A0 Yo= u could say a message failing to validate an author signature with "[.= ..]" at the front of Subject was likely tagged by an MLM, or that ever= ything after "--" should be ignored, or that those probably happe= ned at non-submission hop #1, but those are heuristics, and I think we'= re hoping for something more deterministic.=C2=A0 The 80/20 rule isn't = sufficient.

But it's late and maybe I'= m missing something.=C2=A0 What did you have in mind?

Sure, but the easier answer: to use my mailing list, you must have either DKIM, SPF or both. Sounds like a good way to not be essentially an open relay. Don't mailing lists have those sorts o= f policies these days? I would say that ones that don't probably shouldn't have good reputations since they are, in effect... open relays.

That requires MLMs= to change their behavior, which I believe is something all of these protoc= ols are hoping to avoid (or, at least, MLMs should decide that on their own= , not because the IETF forced them to by wielding DMARC and ARC at them).
=20

Mike

PS: it's been, what, 15 years since our interop, partner? :)

2007.=C2=A0 Still got the t-shirt.

-MSK
--000000000000ad052105b4ff8f15-- From nobody Thu Nov 26 04:39:02 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC163A12D5 for ; Thu, 26 Nov 2020 04:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cCIO6gcUXZ7P for ; Thu, 26 Nov 2020 04:38:58 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1C43A12C0 for ; Thu, 26 Nov 2020 04:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606394335; bh=NYN4ywKpQ15Jlej2pnWZDwNJLCTTjc39e2ornSlaK58=; l=2013; h=To:Cc:References:From:Date:In-Reply-To; b=CKD/RdRM46QxyQ9O5APxkfnr8vWkTKjFgtWmqQxolSPegaBnRqQexvMaF/3uPmaPa legt4mXLkrvabfG7EwOQEq47SEPdjsLYgVvCxZy63BAGF6LGmozc9MaTqQ/bnMWqde S4qyyJne7Q4AdTfiE9hqguwu74w28q5ScyoO90rIBGJMMEx00QAEK3P1bBamE Authentication-Results: tana.it; auth=pass (details omitted) Original-From: Alessandro Vesely Original-Cc: IETF DMARC WG Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005FBFA1DF.00007361; Thu, 26 Nov 2020 13:38:55 +0100 To: "Murray S. Kucherawy" , Michael Thomas Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com> From: Alessandro Vesely Message-ID: <0889a589-0e0e-3694-69ba-31805b9b54c8@tana.it> Date: Thu, 26 Nov 2020 13:38:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 12:39:00 -0000 On 26/11/2020 10:56, Murray S. Kucherawy wrote: > On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas wrote: > >> >> Yeah, quantifying the problems kinda seems like the first order of >> business if you ask me. Quantifications will differ depending on what you count. Total number of messages versus total number of mail operators who find ARC useful. Small operators had better not forward spam, whether ARC sealed or not. >> Software. Only software can pry apart that ball of header spaghetti. But I >> think with the simple a mailing list it is pretty easy to determine, which >> now that I think about it I actually did back in the day when I was >> experimenting with recovering mailing list modifications. It didn't occur >> to me that that was supposed to be hard. >> > I haven't put hand to coding keyboard on this problem yet, but I'm trying > to imagine how it would be easy to determine (a) that Subject had been > modified (for example), (b) what the specific modification was, and (c) > which hop did it. You could say a message failing to validate an author > signature with "[...]" at the front of Subject was likely tagged by an MLM, > or that everything after "--" should be ignored, or that those probably > happened at non-submission hop #1, but those are heuristics, and I think > we're hoping for something more deterministic. The 80/20 rule isn't > sufficient. Again, you cannot get 100% lists. For example, anonymizing lists will never let you recover an author domain's signature. MLM has to comply. On a compliant list like this one, you cannot get 100% users. For example, those who sign a Content-Type: multipart/alternative without giving the original value, or a quoted-printable body that the MLM will encode differently will never verify. Author domains have to comply. On a compliant list, you can verify 99.99% compliant author domains' signatures. (~0.01% due to cosmic rays and similar accidents.) Best Ale -- From nobody Thu Nov 26 10:28:35 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED103A00C9 for ; Thu, 26 Nov 2020 10:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-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 Jm9-E0bSL1j7 for ; Thu, 26 Nov 2020 10:28:31 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21453A005C for ; Thu, 26 Nov 2020 10:28:31 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id n137so2327244pfd.3 for ; Thu, 26 Nov 2020 10:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=8tVN2ZGUXk21i3Jy7X+JCHT2mQj0hMAtJgPK/osR9f0=; b=RCCVLAtjCjCJvXYhPrhrOsDFrI/X28aeedXfKFUOt4VR7Qa/fv87MmT26ILUf+45CX 5ZBXTohDQVlkQrVh08i0VzYYVVI6sUnVuyc01cmDkKattAKJ7qvsUH+fwGk+qknPLBp8 nNYAf9VHIarRLHh7+4UBCs8NCB4oVbaDfqO3GbxroLoYnA1FxWIPBnBHMTj7XW4UMPSO w4c8ZLBrhsPYRjUEyq7r+rZa0mjgiC6Ar2V++76OEgStCcwi2BI6YgZtlRhE2zQLgHlI ur5k0KADpfBX68K6Okth1P/GgEm3DmS/iI6VOd+ay49KQbTe48cSLAbFwIlDIPT40QDi RgkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8tVN2ZGUXk21i3Jy7X+JCHT2mQj0hMAtJgPK/osR9f0=; b=H4nj3AK2BvfOu5v7mljZrTN2l3IbUXiv9alctFHIpFDiUrs8RtWR9+G9CR9JBhisIZ aW7X1YxFIPAQV8rB5J0iPO6LoPCM3MGMd29+we5djiFxZs+vlZTB0sSCVAGDZalrisLl C908OomYBKbBWRK1AxfphNmsrGs68d9RSkukn/SWAC7qZkO3pd3sS1x38+XihJ82F3ss bZZs3TXfmCv3LmLtwxhTrHhk6mlubPX+o/IW65cfAYzV19U2TSv0X39vu1OzGVmp/Ack fNuvMJ1FTUxnRo7xCVZhfTtdN+zQB6IDaL5BfVphDIHG9b/S+IksiL5Pg3oMPsAk5N23 wThg== X-Gm-Message-State: AOAM530f2KMicHhyBSHc5JGugyzA8C68eyiU0x4Aa6fjxuoFbcTT/AO8 Hp+i3W3VIHrtMyZ7xqEQ8DeXelmmV7sv3A== X-Google-Smtp-Source: ABdhPJykTUaDoOL4/bKOY34v4SsNNEAl/blRR7rj/FfwVz5wLWomSEA1eM8vJyrg9+iKwNCI+SD0Sw== X-Received: by 2002:a63:8149:: with SMTP id t70mr3447895pgd.80.1606415310757; Thu, 26 Nov 2020 10:28:30 -0800 (PST) Received: from mike-mac.lan (107-182-37-5.volcanocom.com. [107.182.37.5]) by smtp.gmail.com with ESMTPSA id p6sm7334317pjt.13.2020.11.26.10.28.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Nov 2020 10:28:30 -0800 (PST) To: "Murray S. Kucherawy" Cc: IETF DMARC WG References: <20201124020453.AFDC027CE5C8@ary.qy> <2347b5dd-54b8-a042-a435-b64c4e54d3bb@mtcc.com> From: Michael Thomas Message-ID: Date: Thu, 26 Nov 2020 10:28:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CBA69FEBDA98C8D6A0D5D407" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 18:28:34 -0000 This is a multi-part message in MIME format. --------------CBA69FEBDA98C8D6A0D5D407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/26/20 1:56 AM, Murray S. Kucherawy wrote: > > ARC was developed over months, even before this WG started, and I > remember all of these conversations happening involving the questions > you're now asking.  We landed at what became ARC.  I suppose an > appendix might've been nice enumerating everything that was considered > and discarded, but that record doesn't really exist. Yeah, like I said that's sort of a common failing of IETF documents in general. I mean, I understand at a very low level what's going on here, but given the document I am completely clueless of the *why* of things are going on. It's very frustrating, doubly so when it's a self-labeled experiment. > > > Where do you suggest we go from here? I would think that an informational RFC might come in really handy both to answer the questions in ARC itself, and any other subsequent questions the wg deems needed since then. Leaving ARC in an experimental state ad infinitum doesn't seem optimal. Basically: 1) was it needed at all 2) did it help. 3) if it helped, how much did it help. (1) in particular is what interests me because adding two new signatures seems *really* heavy handed. That would go a long way toward answering the questions of whether it's should go standards track. > I haven't put hand to coding keyboard on this problem yet, but I'm > trying to imagine how it would be easy to determine (a) that Subject > had been modified (for example), (b) what the specific modification > was, and (c) which hop did it.  You could say a message failing to > validate an author signature with "[...]" at the front of Subject was > likely tagged by an MLM, or that everything after "--" should be > ignored, or that those probably happened at non-submission hop #1, but > those are heuristics, and I think we're hoping for something more > deterministic.  The 80/20 rule isn't sufficient. > > But it's late and maybe I'm missing something.  What did you have in mind? Our motivation at the time was one in particular: spear phishing. From an enterprise situation spear phishing is scary af, and not one that providers have much care about. That's what John gets wrong when he says that 90% pass rate is useless: for enterprise not wanting to get spear phished, a 10% false positive rate issuing warnings might be acceptable, and since we were grappling the intractable mailing list reputation (at least from our standpoint), maybe a better option. But it was a combination of the l= value in the original signature to clip off what the mailing list added, and some heuristics on the subject line to remove added text. I had quite a few of them, and they were certainly pretty dodgy, but by and large they worked. The object was not to get to 100%, but just an acceptable false positive rate. At the time I mentioned that maybe it would be good to create a DKIM-friendly mailing list BCP, but that was scoffed at by the usual suspects because there was supposedly a massive long tail of transformations that can happen that nobody would quantify as to how common or important they were. Hence my desire of this being driven at least in part by numbers. > Sure, but the easier answer: to use my mailing list, you must have > either DKIM, SPF or both. Sounds like a good way t > > o not be essentially an open relay. Don't mailing lists have those > sorts of policies these days? I would say that ones that don't > probably shouldn't have good reputations since they are, in > effect... open relays. > > > That requires MLMs to change their behavior, which I believe is > something all of these protocols are hoping to avoid (or, at least, > MLMs should decide that on their own, not because the IETF forced them > to by wielding DMARC and ARC at them). I don't see making mailing lists coerced into better behavior as a non-starter. Everybody has had to change over the years to get mail delivered, and mailing lists, etc, shouldn't be viewed as sacred cows. If they want to forward their mail, they need to play by the evolving rules so as to make for a less spammy and phishy world. Back when DKIM was the new kid on the block, that might have been a valid argument. Today, not so much. > PS: it's been, what, 15 years since our interop, partner? :) > > 2007.  Still got the t-shirt. > But we interoped the combined DK and IIM spec a couple of years earlier, right? What a great day that was... we dunn'em proud, Murray :) Mike --------------CBA69FEBDA98C8D6A0D5D407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/26/20 1:56 AM, Murray S. Kucherawy wrote:

ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking.  We landed at what became ARC.  I suppose an appendix might've been nice enumerating everything that was considered and discarded, but that record doesn't really exist.

Yeah, like I said that's sort of a common failing of IETF documents in general. I mean, I understand at a very low level what's going on here, but given the document I am completely clueless of the *why* of things are going on. It's very frustrating, doubly so when it's a self-labeled experiment.



Where do you suggest we go from here?

I would think that an informational RFC might come in really handy both to answer the questions in ARC itself, and any other subsequent questions the wg deems needed since then. Leaving ARC in an experimental state ad infinitum doesn't seem optimal. Basically: 1) was it needed at all 2) did it help. 3) if it helped, how much did it help. (1) in particular is what interests me because adding two new signatures seems *really* heavy handed. That would go a long way toward answering the questions of whether it's should go standards track.


I haven't put hand to coding keyboard on this problem yet, but I'm trying to imagine how it would be easy to determine (a) that Subject had been modified (for example), (b) what the specific modification was, and (c) which hop did it.  You could say a message failing to validate an author signature with "[...]" at the front of Subject was likely tagged by an MLM, or that everything after "--" should be ignored, or that those probably happened at non-submission hop #1, but those are heuristics, and I think we're hoping for something more deterministic.  The 80/20 rule isn't sufficient.

But it's late and maybe I'm missing something.  What did you have in mind?

Our motivation at the time was one in particular: spear phishing. From an enterprise situation spear phishing is scary af, and not one that providers have much care about. That's what John gets wrong when he says that 90% pass rate is useless: for enterprise not wanting to get spear phished, a 10% false positive rate issuing warnings might be acceptable, and since we were grappling the intractable mailing list reputation (at least from our standpoint), maybe a better option.

But it was a combination of the l= value in the original signature to clip off what the mailing list added, and some heuristics on the subject line to remove added text. I had quite a few of them, and they were certainly pretty dodgy, but by and large they worked. The object was not to get to 100%, but just an acceptable false positive rate. At the time I mentioned that maybe it would be good to create a DKIM-friendly mailing list BCP, but that was scoffed at by the usual suspects because there was supposedly a massive long tail of transformations that can happen that nobody would quantify as to how common or important they were. Hence my desire of this being driven at least in part by numbers.

Sure, but the easier answer: to use my mailing list, you must have either DKIM, SPF or both. Sounds like a good way t
o not be essentially an open relay. Don't mailing lists have those sorts of policies these days? I would say that ones that don't probably shouldn't have good reputations since they are, in effect... open relays.

That requires MLMs to change their behavior, which I believe is something all of these protocols are hoping to avoid (or, at least, MLMs should decide that on their own, not because the IETF forced them to by wielding DMARC and ARC at them).

I don't see making mailing lists coerced into better behavior as a non-starter. Everybody has had to change over the years to get mail delivered, and mailing lists, etc, shouldn't be viewed as sacred cows. If they want to forward their mail, they need to play by the evolving rules so as to make for a less spammy and phishy world. Back when DKIM was the new kid on the block, that might have been a valid argument. Today, not so much.


PS: it's been, what, 15 years since our interop, partner? :)

2007.  Still got the t-shirt.

But we interoped the combined DK and IIM spec a couple of years earlier, right? What a great day that was... we dunn'em proud, Murray :)


Mike

--------------CBA69FEBDA98C8D6A0D5D407-- From nobody Thu Nov 26 13:55:52 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452E3A10B3 for ; Thu, 26 Nov 2020 13:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=jtkNg5XH; dkim=pass (2048-bit key) header.d=taugh.com header.b=TbgGiu2A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uoGrMWUu8zf for ; Thu, 26 Nov 2020 13:55:48 -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 5801F3A10B1 for ; Thu, 26 Nov 2020 13:55:48 -0800 (PST) Received: (qmail 85661 invoked from network); 26 Nov 2020 21:55:46 -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:cleverness; s=14e9b.5fc02462.k2011; bh=9bV9owKOA20T2XcBsTcpAKlyNiopuzQhA5YlNtmGp9M=; b=jtkNg5XHGZY92iu3RnA2x6RLgJH5cZh8Ggqnvmzqy/ZkE9kN5UYpNw/11PKqeJv2cbVu0xej0NvTHmL8iCgv7tm5bExprN4y+DHBH8Fqn6cB3+39lCiBqvG6hGWJ5lDkBetpqcx3YNPMYW1+2o81h8SB6/3oqAQLdEV1ZXJXhx6RNZUZeZbmTHQMicDIibeUp8X2ZmRQuYzUgLtVnnsONyBIOZXwBJnNMA6sibO03dBrdcAMuDW9VKyLMD1lZ2ig5XGCCVuLpy9hBecfvn96AMwNaA8jHmCYNCD8kp5QXieNByWqe90O4E/DRxg7MZOyZPX82vGCfslEjvrvTbRatw== 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:cleverness; s=14e9b.5fc02462.k2011; bh=9bV9owKOA20T2XcBsTcpAKlyNiopuzQhA5YlNtmGp9M=; b=TbgGiu2AcdC4+4ERHCe6bB+CdFoJ4R5cq7RLXd1SXb/HwAlJS/heDhYvR7RK+gVkWrptXhmXgho4J9sj3a2r15JLvoivQ0wb2VKdvTV7cJ+Sg4UnERUdAiEFCsLRHDGXyMSuZBZwWg6n2ay0aXAwN+JWUccafXIpbAQMMscc5VoP1mL8lgpY2pWfNcDf7Isenv3PUo9yiEtJgTE8I3uuZElSYPa8gadY4/zLZUY640ckRtZUNJqd6WvOfFru99N/cnD89C6AAo2KdgvfiRN/09+YFjFpIhNxHDJooy/gByQNF8hDhuxHKV+C7VcW6JaZtPArGWuDGkS5j8d6ArNjtA== 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 ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 26 Nov 2020 21:55:45 -0000 Received: by ary.qy (Postfix, from userid 501) id 6D9832822E71; Thu, 26 Nov 2020 16:55:44 -0500 (EST) Date: 26 Nov 2020 16:55:44 -0500 Message-Id: <20201126215545.6D9832822E71@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: mike@mtcc.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 26 Nov 2020 21:55:50 -0000 In article you write: >questions the wg deems needed since then. Leaving ARC in an experimental >state ad infinitum doesn't seem optimal. Basically: 1) was it needed at >all 2) did it help. 3) if it helped, how much did it help. I agree that at some point we need to declare the experiment over and see if it's worked, but it's way too early for that. At this point the only widely used list software that can apply ARC seals is Sympa. (Mailman 3 may, but most mailman users including the IETF are still using mailman 2.) > (1) in >particular is what interests me because adding two new signatures seems >*really* heavy handed. That would go a long way toward answering the >questions of whether it's should go standards track. I don't get why a few extra signatures are a problem. Nearly all of my mail goes out with two added DKIM signatures, one that matches the >From domain or the list domain if it's a list, and one for my system. It's just not a big deal. >Our motivation at the time was one in particular: spear phishing. From >an enterprise situation spear phishing is scary af, and not one that >providers have much care about. That's what John gets wrong when he says >that 90% pass rate is useless: for enterprise not wanting to get spear >phished, a 10% false positive rate ... Sorry, I meant 90% the other way, catching 90% of the bad stuff and letting the other 10% through is not good enough. I agree that for spear phishing the tolerance for false positives is likely to be fairly high. R's, JOhn From nobody Sun Nov 29 03:00:26 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922A23A142B for ; Sun, 29 Nov 2020 03:00:16 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnkK0Znn1c2B for ; Sun, 29 Nov 2020 03:00: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 2C18C3A1412 for ; Sun, 29 Nov 2020 03:00:07 -0800 (PST) Received: (qmail 45938 invoked by uid 100); 29 Nov 2020 11:00:06 -0000 Date: 29 Nov 2020 10:59:42 -0000 Message-ID: <20201129105942.45927.qmail@submit.iecc.com> From: "John Levine" To: dmarc@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Nov 29 06:00:05 2020 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 11:00:24 -0000 Count | Bytes | Who ------------+----------------+------- 24 (20.7%) | 218851 (20.1%) | Michael Thomas 23 (19.8%) | 126757 (11.7%) | John Levine 14 (12.1%) | 130060 (12.0%) | Dave Crocker 11 ( 9.5%) | 57691 ( 5.3%) | Alessandro Vesely 10 ( 8.6%) | 114874 (10.6%) | Brandon Long 8 ( 6.9%) | 145772 (13.4%) | Douglas E. Foster 6 ( 5.2%) | 59390 ( 5.5%) | Murray S. Kucherawy 5 ( 4.3%) | 63507 ( 5.8%) | Jesse Thompson 4 ( 3.4%) | 56129 ( 5.2%) | Todd Herr 2 ( 1.7%) | 16347 ( 1.5%) | Joseph Brennan 2 ( 1.7%) | 7227 ( 0.7%) | Dave Crocker 1 ( 0.9%) | 17823 ( 1.6%) | Douglas Foster 1 ( 0.9%) | 15672 ( 1.4%) | Seth Blank 1 ( 0.9%) | 15356 ( 1.4%) | Chudow, Eric B CIV NSA DSAW (USA) 1 ( 0.9%) | 15262 ( 1.4%) | Laura Atkins 1 ( 0.9%) | 12058 ( 1.1%) | Brotman, Alex 1 ( 0.9%) | 8019 ( 0.7%) | Kurt Andersen (b) 1 ( 0.9%) | 5759 ( 0.5%) | From nobody Mon Nov 30 20:57:04 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146D23A091C for ; Mon, 30 Nov 2020 20:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hixXOf5MQzn2 for ; Mon, 30 Nov 2020 20:57:00 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 1703B3A0809 for ; Mon, 30 Nov 2020 20:57:00 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id z16so254024vsp.5 for ; Mon, 30 Nov 2020 20:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s39pkJeK7aU3/Zn4zXXdgnD/5v0XDvZBJRQb8UNUA1c=; b=RIsyud8Ov6AOJYUkPbZEwU+ZTu5UPnqBXMEvPmFV2XqlzoeBLrgkatZX5PM7ALbqh5 QbvsqGAbBbLW4anqRfFYRFUrGSsJCOFJHBqhLOzB2/uzVAO+8HQkt5a8ESmFX9fR74Uh Ziimu8NIbo8mTOKX2meAZNPHyRM5aqw/7k4ftbSPn7MpTiz8IWTEHGiHmSf1fmPGI2uW Dvgze4kfIhNDScFfgQd1gdYky+/+ETlokACPRkemWXn0ZYkEmtBhRzIbOl6z7z7aVS7K eP/cFqTqHh5lHLVduVAw90sc6PiJmFKUS/eyHWIbNn3f4JouJ+oCFgxGzAraxNboSqjX egtg== 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=s39pkJeK7aU3/Zn4zXXdgnD/5v0XDvZBJRQb8UNUA1c=; b=P8F6kjybv5QtMxV1MzKd4tuptPcgFF3p6OliodA72gPyfREjQeV2Q/NbRDU7xGMvw+ fqoigRpV8YGAQThi2zRCvkFA6AB6chkdaufUIqsD+8MslMNRK4cQtgeUjNYhuWpjEQbv yXvwGjumGZe/Og952u44v2PXC2Dy5aAJ5uxVWULNcQgLnHKQLjpGwLWCz68/0G8pP7Cn hUmltg/rFJHbWXoQYkCUkOeOmyAJZeRUJCkCDXZZx5lU9zFRe08Sqly650SnLSShiEIW 7Wpa/waVdhdpEqc5paHdnslh1rjIRr83D3a2XLDGuv1015Gkh6kd8m7uCd6L1+VzLDje +ElQ== X-Gm-Message-State: AOAM533JKKPYKWXSPjJ1tPYFQ3mBgg8runE9O9k6VQ1EGy42N6fFfcHQ n6CB1d85OeKGXsxkgNiJYx03zFwyogpI0bd3doJy X-Google-Smtp-Source: ABdhPJxmSFj2CeeLp21hcW/uOg2IsvxJPgIjSOapW1CHswuXuOaP/Oo27IT+F7yiGmN7KzFtn7TrvOopOg4nAgyCuuc= X-Received: by 2002:a67:df8b:: with SMTP id x11mr1008821vsk.37.1606798618719; Mon, 30 Nov 2020 20:56:58 -0800 (PST) MIME-Version: 1.0 References: <8c83fffc-077d-9ddb-db2f-b9763361c60f@tana.it> <39eafc5e-3d9c-0bea-1173-7277070195ea@wisc.edu> <081c42a3-492b-89b7-ad76-ccec48dea091@tana.it> <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> In-Reply-To: <2d1dca4f-e46a-646c-9fa3-d9ca56c72196@tana.it> From: Brandon Long Date: Mon, 30 Nov 2020 20:56:46 -0800 Message-ID: To: Alessandro Vesely Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000e559cf05b55ff435" Archived-At: Subject: Re: [dmarc-ietf] A policy for direct mail flows only, was ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 04:57:02 -0000 --000000000000e559cf05b55ff435 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 26, 2020 at 12:59 AM Alessandro Vesely wrote: > On 25/11/2020 20:16, Michael Thomas wrote: > > On 11/25/20 11:11 AM, Alessandro Vesely wrote: > >> On 25/11/2020 19:24, Jesse Thompson wrote: > >>> On 11/25/20 11:30 AM, Alessandro Vesely wrote: > >>>> Without resorting to ARC, it is still possible to validate author > domain's > >>>> signatures directly if the MLM just adds a subject tag and a footer, > like, > >>>> for example, this list does. While ARC solves "deep" forwarding > problems, > >>>> which may arise in the context of email address portability, MLM > >>>> transformation reversion solves the simpler mailing list problem, > including > >>>> reverting munged From:'s. > >>> > >>> I agree that ARC isn't really needed to do this (trust the last hop > from the > >>> MLM and determine the original authenticity from the MLM's perspective) > >> > >> I didn't mean to trust the MLM. I meant remove the subject tag and the > >> footer, then the original DKIM signature verifies. See: > >> https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/ > > > > When I was at Cisco, with l= and some subject line heuristics I could > get > > probably like 90+% verification rate across the entire company, a > company that > > uses external mailing lists a lot. Definitely not 100% though. > > > DKIM itself is not 100%. You always have lines beginning with "From " or > occasional autoconversions. > > l= doesn't cover multipart/alternative nor Content-Transfer-Encoding: > base64. > In addition, the DKIM spec discourages its usage and suggests that > "Assessors > might wish to ignore signatures that use the tag." > Right, some of the other dkim-light or diff concepts we discussed would be better than using l= We again got hung up on the 100% solution, though... something that handled subject-prefix and footer in a transport agnostic way might have worked. The fact that DKIM isn't transport agnostic is an achilles heel to even that, though, since we'd have to come up with a new canonicalization and get it to widespread adoption before the simple diff could work. Or require mailing lists to be a lot more strict in how they do their email rewriting, but I imagine that's harder work than even ARC. Brandon --000000000000e559cf05b55ff435 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 26, 2020 at 12:59 AM Ales= sandro Vesely <vesely@tana.it> = wrote:
On 25/11/= 2020 20:16, Michael Thomas wrote:
> On 11/25/20 11:11 AM, Alessandro Vesely wrote:
>> On 25/11/2020 19:24, Jesse Thompson wrote:
>>> On 11/25/20 11:30 AM, Alessandro Vesely wrote:
>>>> Without resorting to ARC, it is still possible to validate= author domain's
>>>> signatures directly if the MLM just adds a subject tag and= a footer, like,
>>>> for example, this list does.=C2=A0=C2=A0 While ARC solves = "deep" forwarding problems,
>>>> which may arise in the context of email address portabilit= y, MLM
>>>> transformation reversion solves the simpler mailing list p= roblem, including
>>>> reverting munged From:'s.
>>>
>>> I agree that ARC isn't really needed to do this (trust the= last hop from the
>>> MLM and determine the original authenticity from the MLM's= perspective)
>>
>> I didn't mean to trust the MLM.=C2=A0 I meant remove the subje= ct tag and the
>> footer, then the original DKIM signature verifies.=C2=A0 See:
>> https://datatracker.ietf.= org/doc/draft-vesely-dmarc-mlm-transform/
>
> When I was at Cisco, with l=3D and some subject line heuristics I coul= d get
> probably like 90+% verification rate across the entire company, a comp= any that
> uses external mailing lists a lot. Definitely not 100% though.


DKIM itself is not 100%.=C2=A0 You always have lines beginning with "F= rom " or
occasional autoconversions.

l=3D doesn't cover multipart/alternative nor Content-Transfer-Encoding:= base64.
In addition, the DKIM spec discourages its usage and suggests that "As= sessors
might wish to ignore signatures that use the tag."

Right, some of the other dkim-light or diff concepts we di= scussed would be better than using l=3D=C2=A0

We a= gain got hung up on the 100% solution, though... something that handled sub= ject-prefix and
footer in a transport agnostic way might have wor= ked.=C2=A0 The fact that DKIM isn't transport agnostic
is an = achilles heel to even that, though, since we'd have to come up with a n= ew canonicalization
and get it to widespread adoption before the = simple diff could work.=C2=A0 Or require mailing lists to
be a lo= t more strict in how they do their email rewriting, but I imagine that'= s harder work than
even ARC.

Brandon
--000000000000e559cf05b55ff435-- From nobody Mon Nov 30 21:43:49 2020 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49383A0A34 for ; Mon, 30 Nov 2020 21:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODE6AFRiLr91 for ; Mon, 30 Nov 2020 21:43:45 -0800 (PST) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E24E3A0A2D for ; Mon, 30 Nov 2020 21:43:45 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id y26so216701uan.5 for ; Mon, 30 Nov 2020 21:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6lu0SZFT/KkMqWKXuJuQQZ7QUJydjPBShx3SuVt88xA=; b=hQ+XbuO/XOMMCiOtFhPhMHdVSNCDKpmEjBO7dU50wGLvgKUYiSSjsEOR2UnRQ20k2U NVb8Sr+0wBgoYIYqDErdcA+y8VFjmt8Sm/lEWMpm/4tLf1ZCxj7Z5lXpNJVnmFsBncwW Kn9rEyESq8UJqCmev+qU/qEah2epLB71iJi3KriDS0PTkocn+RFzssFwwxwaMf8EaXEE 88DEPtE7fSJmRoVXrCzeSE1F0NysmnR0JjH4CmGw+FJ0hxh9fyPGVXu1FhuuNDiNXqco mSIHlmopllkETPjETm2RYOSy3H+BTV0bdW+tHK+p/SpyPS5oEttKxlvP6Xuiz+KEVzMt 0WWw== 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=6lu0SZFT/KkMqWKXuJuQQZ7QUJydjPBShx3SuVt88xA=; b=GFwIcv9EOoEj8Zynhv1E1QyY7GyphXN6AuLlODUkQmXgjmRcXEOPm3cuQ4SocWz3sH Ackw6DtM89PBsmSVGHDH0GKmUlm2It3QI53pmaMzfBazo+X2QwBbBFpE10Xt+CkULBGK MmB66kPf2G/dAc6S2rv8BoxEgpKTRbQP317t8NeVLrWStYOmvsYXtrKfEY+SDEL5ID8n fVRUDh8rr9uwwJAlQQYlMqs05CrUkmBoxgIJbmt1yEFiEPcHHjqHif2BjGh4PeHxD0wX UAhwz9XhN/Hdg0avjCCCQHQKD+kHsafwyeGDuu7J0+05ECgGHpIXeMXCQhxRDFBs35my ahIg== X-Gm-Message-State: AOAM532Oh3yRDFv/Ws8KkUx1t5N8m8ySC5dqtHdTuFTiP+medrdfOvQ6 ZQO4zZ1pXtbpdKZh9Le24hwnbqcyn+i+LlQiUbsgB/3rOqO7 X-Google-Smtp-Source: ABdhPJwPthNW7NeHiupTjs1wGJPweWdE/Ygjhq5rx5/Ct8odxx1uitZyQurUn8z1+AlUNcONLPhz68q8XmEEZGII4Vc= X-Received: by 2002:ab0:21da:: with SMTP id u26mr1148632uan.92.1606801424030; Mon, 30 Nov 2020 21:43:44 -0800 (PST) MIME-Version: 1.0 References: <20201124020453.AFDC027CE5C8@ary.qy> <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> In-Reply-To: <1eed8278-4efa-4abc-15e0-2efcf014e82e@mtcc.com> From: Brandon Long Date: Mon, 30 Nov 2020 21:43:30 -0800 Message-ID: To: Michael Thomas Cc: John Levine , IETF DMARC WG Content-Type: multipart/alternative; boundary="0000000000001b1c2c05b5609c0b" Archived-At: Subject: Re: [dmarc-ietf] ARC questions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Dec 2020 05:43:48 -0000 --0000000000001b1c2c05b5609c0b Content-Type: text/plain; charset="UTF-8" On Tue, Nov 24, 2020 at 5:27 PM Michael Thomas wrote: > > On 11/24/20 4:56 PM, Brandon Long wrote: > > > > On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas wrote: > >> >> Our experience also showed that more than one hop is quite common in >> enterprise deployments, >> and those are also the places where the most complexity arises. Others >> shared our experience >> as well. >> >> That's more than one modifying intermediary in *separate* administrative >> domains? Within your own administrative domain there shouldn't be an issue >> of trust since you can trust your own servers auth-res and that they are >> not maliciously trying to forge an auth-res for better treatment. and >> course it's best to stop a bad message as soon as possible in the mail >> pipeline if for no other reason than why waste the resources. >> > The administrative domain in practice tends to be per-vendor and > multi-tenant. Ie, gsuite/gmail is on google.com, various third party > anti-spam gateways also different, on-premise being also separate. Passing > that trust between domains is one of the things that ARC can handle. > > One of the failings of many, many ietf documents is to not tell the story > of what exactly the problem is and why the protocol is needed. It's really > frustrating to the reader to not have the context of endless wg list > discussions distilled so that an outsider can understand the design > tradeoffs. I still don't understand why a DKIM signature was a "poor > choice". That's especially true when something is an experiment that > assumedly has yes/no endpoint. > To summarize what I said already in this thread, DKIM is taken by many receivers as the responsible party for a message, in both spam and phishing classifiers, with the latter being perhaps more relevant. DMARC is the one example of that. DKIM signing a message that transits your system allows for reputation washing of the original message. The ARC chain is specified as a relay responsibility, which is a lesser burden. Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message. DKIM is not the only thing that can be reputation washed, SPF can as well. 821.FROM rewriting is more common, so there are work-arounds. OTOH, SPF doesn't survive forwarding, but with ARC you can forward it. DKIM+A-R would only work for a single hop, and lead to some complication compared to the other DKIM signatures already on the message. > So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it > would run into problems? I haven't put up a DMARC policy, but if I did I > might run into issues with false positives? Like I said, I'm trying to get > my head around what the actual problems are, and this is coming from a > person who stressed mightily from the very beginning about the mailing list > problem. > It's unlikely you have a complicated mail flow involving multiple vendors, but certainly there are plenty of configuration options alllowing folks to shoot themselves in the foot. > Well sure, I'm sure it can happen but is it common enough to worry about? >> And I'm still not convinced that figuring out who signed what and which >> auth-res it belonged to is in insurmountable problem. for one, there are >> received headers which better not be getting out of order to help correlate >> with the messages' path through intermediary verifiers too. >> > So, we do have some Received header walking code, and allow admins to set > up the list of IPs that are considered "internal" (beyond private > addresses)... but O365 uses public IPs internally and > has a huge and unpublished ranges of them, making it nearly impossible for > admins to maintain a list. Obviously we can all add code to handle > Microsoft specially... and whichever other ones come up. > > But can't you trust the received headers once you have possession of the > message within your domain? I'm sorry if I'm being dense here but received > headers are definitely ordered and if you loan out a message to be > processed by a different domain and they aren't trustworthy, that's the > least of your problems. That's part of the overall problem though: it's > really hard to understand what the problem here actually is. Explain it > like I'm five :) > For now, our received header walking code is for handling inbound gateways. If you use both O365 and GSuite, and use O365 as your MX before forwarding to Google, there are many cases where they will break all DKIM signatures (and obviously SPF) before reaching Google's MX. Our workaround is to specify your internal IPs to us, so we can walk past those received headers to the first one added by your external MX. Should these things use IP addresses for these things? Probably not. Some sort of SMTP-AUTH could potentially be used to gateway more directly between them, but we'd still need to disable most of our spam/phishing pipelines which are dependent on reputation. With ARC, we can instead say "trust this arc admd" and have the data passed directly, and also work around the DKIM breakage. As for another comment in the thread about adding two signatures per hop, there was a suggestion that it could be replaced with a single signature per hop near last call with some loss of information (maybe), but it was decided to move forward with the existing solution that already had several implementations and was experimental anyways. As for how complicated it is to implement, I think starting from a DKIM implementation it's fairly straight-forward... though obviously that depends a bit on how your DKIM implementation was composed. I think my initial changes to dkimpy to add ARC support only took a couple days. It's not really an indication of how well written (or not) the RFC is, given familiarity with the design prior to draft. Brandon --0000000000001b1c2c05b5609c0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 24, 2020 at 5:27 PM Micha= el Thomas <mike@mtcc.com> wrote:=
=20 =20 =20


On 11/24/20 4:56 PM, Brandon Long wrote:
=20


On Tue, Nov 24, 2020 at 3:5= 7 PM Michael Thomas <mike@mtcc.com> wrote:

Our experience also showed that more than one hop is quite common in enterprise deployments,
and those are also the places where the most complexity arises.=C2=A0 Others shared our experience=
as well.

That's more than one modifying intermediary in *separate* administrative domains? Within your own administrative domain there shouldn't be an issue of trust since you can trust your own servers auth-res and that they are not maliciously trying to forge an auth-res for better treatment. and course it's best to stop a bad message as soon as possible in the mail pipeline if for no other reason than why waste the resources.

The administrative domain in practice tends to be per-vendor and multi-tenant.=C2=A0 Ie, gsuite/gmail is on google.com, various third party anti-spam gateways also different, on-premise being also separate.=C2=A0 Passing that trust betwee= n domains is one of the things that ARC can handle.

One of the failings of many, many ietf documents is to not tell the story of what exactly the problem is and why the protocol is needed. It's really frustrating to the reader to not have the context of endless wg list discussions distilled so that an outsider can understand the design tradeoffs. I still don't understand why a DKIM signature was a "poor choice". That&#= 39;s especially true when something is an experiment that assumedly has yes/no endpoint.

To summarize what I said = already in this thread, DKIM is taken by many receivers as the responsible = party for a message, in both spam and phishing classifiers, with the latter= being perhaps more relevant.
DMARC is the one example of that.= =C2=A0 DKIM signing a message that transits your system allows for reputati= on washing of the original message.=C2=A0 The ARC chain is specified as a r= elay responsibility, which is a lesser burden.

Ign= oring the existing usage of DKIM, DKIM+A-R would only work for a single hop= , and lead to some complication compared to the other DKIM signatures alrea= dy on the message.

DKIM is not the only thing = that can be reputation washed, SPF can as well.=C2=A0 821.FROM rewriting is= more common, so there are work-arounds.=C2=A0 OTOH, SPF doesn't surviv= e forwarding, but with ARC you can forward it.=C2=A0 DKIM+A-R would only wo= rk for a single hop, and lead to some complication compared to the other DK= IM signatures already on the message.
=C2=A0

So mtcc.com is now= hosted by gsuite (::sigh::), so you're saying that it would run into problems? I haven't put up a DMARC policy, but if I did I might run into issues with false positives? Like I said, I'm trying to get my head around what the actual problems are, and this is coming from a person who stressed mightily from the very beginning about the mailing list problem.

It's unlikely you have a complicated mail flow involving m= ultiple vendors, but certainly there are plenty of configuration options al= llowing folks to shoot themselves in the foot.

Well sure, I'm sure it can happen but is it common enough to worry about? And I'm still not convinced that figuring out who signed what and which auth-res it belonged to is in insurmountable problem. for one, there are received headers which better not be getting out of order to help correlate with the messages' path through intermediary verifiers too.=C2=A0

So, we do have some Received header walking code, and allow admins to set up the list of IPs that are considered "internal" (beyond private addresses)... but O365 use= s public IPs internally and
has a huge and unpublished ranges of them, making it nearly impossible for admins to maintain a list.=C2=A0 Obviousl= y we can all add code to handle Microsoft specially... and whichever other ones come up.

But can't you trust the received = headers once you have possession of the message within your domain? I'm sorry if I'm being den= se here but received headers are definitely ordered and if you loan out a message to be processed by a different domain and they aren't trustworthy, that's the least of your problems. That&#= 39;s part of the overall problem though: it's really hard to understand wha= t the problem here actually is. Explain it like I'm five :)

For now, our received header walking code is for handli= ng inbound gateways.=C2=A0 If you use both O365 and GSuite, and use O365 as= your MX before forwarding to Google, there are many cases where they will = break all DKIM signatures (and obviously SPF) before reaching Google's = MX.=C2=A0 Our workaround is to specify your internal IPs to us, so we can w= alk past those received headers to the first one added by your external MX.=

Should these things use IP addresses for these th= ings?=C2=A0 Probably not.=C2=A0 Some sort of SMTP-AUTH could potentially be= used to gateway more directly between them, but we'd still need to dis= able most of our
spam/phishing pipelines which are dependent on r= eputation.

With ARC, we can instead say "trus= t this arc admd" and have the data passed directly, and also work arou= nd the DKIM breakage.

As for another comment i= n the thread about adding two signatures per hop, there was a suggestion th= at it could be replaced with a single signature per hop near last call with= some loss of information (maybe), but it was decided to move forward with = the existing solution that already had several implementations and was expe= rimental anyways.

As for how complicated it is to = implement, I think starting from a DKIM implementation it's fairly stra= ight-forward... though obviously that depends a bit on how your DKIM implem= entation was composed.=C2=A0 I think my initial changes to dkimpy to add AR= C support only took a couple days.=C2=A0 It's not really an indication = of how well written (or not) the RFC is, given familiarity with the design = prior to draft.

Brandon
=C2=A0
--0000000000001b1c2c05b5609c0b--