From nobody Wed Apr 1 00:06:56 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 AA62A3A0E55; Wed, 1 Apr 2020 00:06:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Qin Wu via Datatracker To: Cc: draft-ietf-dmarc-psd.all@ietf.org, last-call@ietf.org, dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158572481464.30894.8037097234628362447@ietfa.amsl.com> Reply-To: Qin Wu Date: Wed, 01 Apr 2020 00:06:54 -0700 Archived-At: Subject: [dmarc-ietf] Opsdir last call review of draft-ietf-dmarc-psd-08 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, 01 Apr 2020 07:06:55 -0000 Reviewer: Qin Wu Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines DMARC (Domain-based Message Authentication, Reporting, and Conformance) extension to enable DMARC functionality for Public Suffix Domains. It allows operators of Public Suffix Domains (PSDs) to express policy at the level of the PSD that covers all organizational domains that do not explicitly publish DMARC records. Major issue: Not found Minor issue: This document provide two registries, one is update of DMARC Tag Registry with one new element, requested from IANA, the other is DMARC PSD registry maintained by [psddmarc.org] and following IANA registry style, I see one is standard registry, the other is non-standard registry, it is not clear to me non-standard registry should be discussed in this document, which introduce confusion, if we keep both, I am wondering why section 6 still requests to add an element to standard registry, which functionality we add is experimental, which functionality is not. Second related question, this draft updates informational RFC7489 with additional components and rules, should the front page of this Experimental RFC reflect this or not? Nits: Section 1 Somewhere subdommains is used, somewhere sub-dommains is used, please be consistent. Section 3.5 said: "Specifically, this is not a mechanism to provide feedback addresses (RUA/RUF) when an Organizational Domain has declined to do so. " Should a reference be added to RUA/RUF, RUA/RUF needs to be expanded or add abbreviation section in the terminology section. Section 3.2 OLD TEXT: " If the 'np' tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is present) or the policy specified by the "p" tag, if the 'sp' tag is not present, MUST be applied for non-existent subdomains. " NEW TEXT: " If the 'np' tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is present) or the policy specified by the "p" tag( if the 'sp' tag is not present and ‘p’tag is present), MUST be applied for non-existent subdomains. " Section 3.2 Change section 3.2 title from "3.2. Section 6.3 General Record Format" To 3.2. Changes in Section 6.3 "General Record Format" Similar changes can be applicable to other places. From nobody Wed Apr 1 09:42: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 6B1EA3A12D6 for ; Wed, 1 Apr 2020 09:42:07 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=tjjXmFo7; dkim=pass (1536-bit key) header.d=taugh.com header.b=WANqMwZT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkZEZnjZcPaC for ; Wed, 1 Apr 2020 09:42:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4F23A12D3 for ; Wed, 1 Apr 2020 09:42:04 -0700 (PDT) Received: (qmail 8459 invoked from network); 1 Apr 2020 16:42:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2109.5e84c45b.k2004; bh=7ETEO2mJedKmKTHwyrVlsi2CSUtvp9xABuObiJ0t5rI=; b=tjjXmFo7wxDnw3aIMQ6M4heovCz01G0yEKqcxBcGZWUevxxP9QilpUlZk80ItR+QE27nyh2Hgarm1ZiWeZa5srNUzAoECnLXSFOyKQMzykSgmpey4+ggvACdfDqd37rd+oALnRIsmfdZeexWO2q7FSGQIKKl/7LMTQZmNiIudcPCctU/Zm7BmqI+V/bJG+ph17iN11zV82cxHrlTjEPNDeCLmfIQbd+zOOcyTK9No3N8V6KPocSQTNn5bM2rOpdi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2109.5e84c45b.k2004; bh=7ETEO2mJedKmKTHwyrVlsi2CSUtvp9xABuObiJ0t5rI=; b=WANqMwZTaum5nx4OLM1u2aSoUqS6EPfqG+E5da3dHeV4tBVMAXY1xziYbtFS723uwOTq8zKI8LrLlVsoABg5UyRAB5rEj2NLSWn6VQhHg/5ei2AWzupMpQpQBJW8fDgTh8Th4XuBnt9kEuEVfx059gh6RGSh/zzR6yw3/7AkKsJaJkkvBNZDSIA82gsBgBeP3mZ7/Jy3i9q+wCCgzAGmG30yCVGm5EosoFa7DU70fFlL+ykFg4EdcxlG4ekcU2ho Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Apr 2020 16:42:03 -0000 Received: by ary.qy (Postfix, from userid 501) id 70DDF16DE877; Wed, 1 Apr 2020 12:42:02 -0400 (EDT) Date: 1 Apr 2020 12:42:02 -0400 Message-Id: <20200401164203.70DDF16DE877@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 16:42:08 -0000 In article you write: >"If the authserv-id is UTF-8, then it might be UTF-8" Yes. >This seems equivalent to > >> authserv-id = sub-domain *("." sub-domain) >> ; Where sub-domain is imported from 6531 for >> ; any mail No, it's 6531 for EAI messages, and 5321 for ASCII messages. EAI and ASCII mail are separate mail streams. The component that is parsing the A-R header had better know ahead of time whether your system is treating them separately. Since 6531 is a strict superset of 5321, if your system handles EAI messages (many still don't) then you can treat them all as EAI, give or take issues with forwarding messages with A-R headers to non-ASCII recipients. From nobody Wed Apr 1 10:53: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 4BA083A14E8 for ; Wed, 1 Apr 2020 10:53:07 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHCKfK546ioR for ; Wed, 1 Apr 2020 10:53:05 -0700 (PDT) Received: from sigil.arcsin.de (sigil.arcsin.de [46.38.233.110]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BE73A14D7 for ; Wed, 1 Apr 2020 10:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-language:content-type:content-type:in-reply-to :mime-version:date:date:message-id:from:from:references:subject :subject:x-amavis-category; s=dkim01; t=1585763580; x= 1587577981; bh=dLwgFu4Gp/5Px83EzDSr6uKTIYnw0brEWUFNHPxqSPs=; b=t zvsjjb6SJqH2zaKoxIzV0P7D3pDWUpbvZPTcP/O8Fu5CIcqmajUns7TedsHNKbks 2dTEg9eAn/t9h8Xw+uFzRXmQe5X7T+xOqzP2wTc51/S+M+dv4tbuxVDi4fMYzJIy iyidlWga+rrO2pF72qSTrsOqx/5q6U90EL8x+LWikM= X-Amavis-Category: sigil.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200401164203.70DDF16DE877@ary.qy> From: Damian Lukowski Message-ID: Date: Wed, 1 Apr 2020 19:52:34 +0200 MIME-Version: 1.0 In-Reply-To: <20200401164203.70DDF16DE877@ary.qy> Content-Type: multipart/alternative; boundary="------------CA006EAA50D62346AA070F94" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 17:53:08 -0000 This is a multi-part message in MIME format. --------------CA006EAA50D62346AA070F94 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit >> This seems equivalent to >>> authserv-id = sub-domain *("." sub-domain) >>> ; Where sub-domain is imported from 6531 for >>> ; any mail > No, it's 6531 for EAI messages, and 5321 for ASCII messages. If they are not equivalent, there must be a counterexample in which a parser with > authserv-id = sub-domain *("." sub-domain) > ; Where sub-domain is imported from 6531 for > ; any mail and another parser with > authserv-id = sub-domain *("." sub-domain) > ; Where sub-domain is imported from 5321 for ASCII mail > ; and 6531 for EAI mail. , given identical input, disagree on the validity of the A-R header of that input. Can you please show an example? > EAI and ASCII mail are separate mail streams. The component that is > parsing the A-R header had better know ahead of time whether your > system is treating them separately. Can you elaborate on this paragraph? Know what ahead of time? It sounds like you agree, that the validity of an A-R header does depend on external factors, not solely on the A-R content. --------------CA006EAA50D62346AA070F94 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 

This seems equivalent to

authserv-id = sub-domain *("." sub-domain)
   ; Where sub-domain is imported from 6531 for
   ; any mail

No, it's 6531 for EAI messages, and 5321 for ASCII messages.

If they are not equivalent, there must be a counterexample in which a parser with

authserv-id = sub-domain *("." sub-domain)
   ; Where sub-domain is imported from 6531 for
   ; any mail
and another parser with

authserv-id = sub-domain *("." sub-domain)
   ; Where sub-domain is imported from 5321 for ASCII mail
   ; and 6531 for EAI mail.

, given identical input, disagree on the validity of the A-R header of that input. Can you please show an example?

EAI and ASCII mail are separate mail streams. The component that is
parsing the A-R header had better know ahead of time whether your
system is treating them separately.

Can you elaborate on this paragraph? Know what ahead of time? It sounds like you agree, that the validity of an A-R header does depend on external factors, not solely on the A-R content.

--------------CA006EAA50D62346AA070F94-- From nobody Wed Apr 1 13: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 BF25B3A07D6 for ; Wed, 1 Apr 2020 13:29:30 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=DA090oIH; dkim=pass (1536-bit key) header.d=taugh.com header.b=y19rbHIX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7P4BhgNqQ9R for ; Wed, 1 Apr 2020 13:29:26 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83513A07C2 for ; Wed, 1 Apr 2020 13:29:25 -0700 (PDT) Received: (qmail 58987 invoked from network); 1 Apr 2020 20:29: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; s=e669.5e84f9a3.k2004; bh=fnsnws3QpoJzZcF1thyCq++IS9awiquRj2a/Cw+W7as=; b=DA090oIHPXqdf5Cmvv2v3ge0QOh+GenqXFlr+iNWrNQ4f3Ot8M68mdqvnluE8flnRiS+EedmcX3d8YkrG3wVdwgF7+/QH6ijsVISxWIRyb+dYvRfwzr19e1VUnWVj2SPzxsjzTYnrAWo7hUUec5btmj3tMDN9KTQRbBjletG/g6IAkcNzgzhdlJxBlLfzHsXQS9wB458MAzEgMpugZNUx6hxu7Z0IPdwonz8UT6gtb6wXunY3XGn2AxdeGEFlX0r DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=e669.5e84f9a3.k2004; bh=fnsnws3QpoJzZcF1thyCq++IS9awiquRj2a/Cw+W7as=; b=y19rbHIX/GSib5SgtRyIfNxggGRi8h1vaS8ovp0z+DnrxLvxPnVl7LF6iwm/bD7mUycy8g0okrfyFkuQJD7epqdi3qNlXbmBeb9MhSLYHe3zIwOKNW6BIffir/gGWMjg+qZ17v7nhexkneMlIYP1IVzAEDH7vS3pTtQi7Gj3fsc/ttfYobnYjWkI7DhwLi2D0FYzAOjeK9T/xA7snt82sql3lT83162bhVgQO6dXkBFiiH4g/JaEZcjjFkj/gGdr Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Apr 2020 20:29:23 -0000 Received: by ary.qy (Postfix, from userid 501) id 5828B16E2E06; Wed, 1 Apr 2020 16:29:22 -0400 (EDT) Date: 1 Apr 2020 16:29:22 -0400 Message-Id: <20200401202923.5828B16E2E06@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 20:29:31 -0000 In article you write: >> authserv-id = sub-domain *("." sub-domain) >> ; Where sub-domain is imported from 5321 for ASCII mail >> ; and 6531 for EAI mail. > >, given identical input, disagree on the validity of the A-R header of >that input. Can you please show an example? It's the one you found. If the authserv-id has a non-ASCII UTF-8 character, it's invalid under 5321 and valid under 6531. >> EAI and ASCII mail are separate mail streams. The component that is >> parsing the A-R header had better know ahead of time whether your >> system is treating them separately. > >Can you elaborate on this paragraph? Know what ahead of time? It sounds >like you agree, that the validity of an A-R header does depend on >external factors, not solely on the A-R content. Right. ASCII mail and EAI mail are handled as separate streams, even if they share a mail server. See this old blog post of mine: https://jl.ly/Email/i18n3.html R's, John From nobody Wed Apr 1 13:44: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 98E993A0862 for ; Wed, 1 Apr 2020 13:44:00 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pERfKB43wbKc for ; Wed, 1 Apr 2020 13:43:58 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA01C3A0805 for ; Wed, 1 Apr 2020 13:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585773831; x=1587588232; bh=5EgSFrym1mG9wkMgUXhPMa68yO6qwM1almF lc/jCYdY=; b=NUc/ohxjyGusBlg8vXELIUAsfivpzLfmVNaEuqqGj8raFDvb0zA nPrWxAUQ8umsBnIVizYIYvNUDMou0euAjfsue2Np9exXEh/RilWwWVIfr/SyoxQX 95Er93k4djp0lpR33Ns0c2+fowD7rEEmxd+b/JvIBdJwepw3etWMUzTQ= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200401202923.5828B16E2E06@ary.qy> From: Damian Lukowski Message-ID: <5c650beb-f0b7-5cae-3070-b7005dec9dbe@arcsin.de> Date: Wed, 1 Apr 2020 22:44:32 +0200 MIME-Version: 1.0 In-Reply-To: <20200401202923.5828B16E2E06@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 20:44:01 -0000 > It's the one you found. If the authserv-id has a non-ASCII UTF-8 character, > it's invalid under 5321 and valid under 6531. I thought we established that as soon as the authserv-id has non-ASCII UTF-8 characters, the mail is automatically - by definition - a 6531 mail: > As a close approximation, any message which has an x80 bit set in a > character in the header is an EAI message. > Right. ASCII mail and EAI mail are handled as separate streams, even if > they share a mail server. See this old blog post of mine: I'll look into it. From nobody Wed Apr 1 14:05: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 2353E3A0900 for ; Wed, 1 Apr 2020 14:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, 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 (1536-bit key) header.d=iecc.com header.b=pmELtJ9K; dkim=pass (1536-bit key) header.d=taugh.com header.b=HKPhoEs8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtIS4aKdM1JF for ; Wed, 1 Apr 2020 14:05:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7003A08FD for ; Wed, 1 Apr 2020 14:05:51 -0700 (PDT) Received: (qmail 65062 invoked from network); 1 Apr 2020 21:05:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fe24.5e85022e.k2004; bh=c/Tqh5TdUhTr56C4XBOc7kqcOGLSdUPIbPmQ2IrFxp4=; b=pmELtJ9KQYb9JWm/majCjzPHTrDRqP+M+X3f/Tb7hmuv/3A+mfOHqZsjQ5xVOQLoOK1EDwQWos9grlj5auJ3urZoGuikkfFMRen0q/GO2XyCXwSpiSupC1BKjsmYBqiJBv87/f8YZrbmv/b6b8lXFbxazllR/S8LGYaRMBkMtKWC1+jNqwQGISQ9DH+bgBk196J0LYBrHDUG7J+OPzuk4SUAIKOnkpspvYHwJm7t7yK0xewmswuLImzN1dXwilAt DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=fe24.5e85022e.k2004; bh=c/Tqh5TdUhTr56C4XBOc7kqcOGLSdUPIbPmQ2IrFxp4=; b=HKPhoEs8RVMBIjlLr19LSPSWA1Pb7AjYTnvjhsxElLcKiVEvb36JuYb1sfgNcxJ9ijxFloV9pzxsU+S6EWORk8qY2Te6ni9pAaUHUODmLo8o4do6sbclOfoPb2qTV6oRn61SIYA6Kq5r7EQQw4kx8RmeYEHBdeHdw0oUn3LdNuYQm97whJ6S5IbZoo1JM8OcO8nkqYruvue1jelmgwPagdFt22mMlEvKXCgQiAlX97fTKKm4kL041r2jPEsYK2j4 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Apr 2020 21:05:49 -0000 Received: by ary.qy (Postfix, from userid 501) id AFA6C16E323F; Wed, 1 Apr 2020 17:05:49 -0400 (EDT) Date: 1 Apr 2020 17:05:49 -0400 Message-Id: <20200401210549.AFA6C16E323F@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: <5c650beb-f0b7-5cae-3070-b7005dec9dbe@arcsin.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 21:05:53 -0000 In article <5c650beb-f0b7-5cae-3070-b7005dec9dbe@arcsin.de> you write: >> It's the one you found. If the authserv-id has a non-ASCII UTF-8 character, >> it's invalid under 5321 and valid under 6531. > >I thought we established that as soon as the authserv-id has non-ASCII >UTF-8 characters, the mail is automatically - by definition - a 6531 mail: Sorry if it seemed like I said that. It's either a potentially valid EAI message or a definitely invalid ASCII message. If your system doesn't handle EAI mail, it's invalid. If there are bytes with the high bit set but they're not a UTF-8 sequence, or they're not a UTF-8 character allowed in an authserv-id it's invalid even if you handle EAI. R's, John From nobody Wed Apr 1 14:25: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 EF6353A0A15 for ; Wed, 1 Apr 2020 14:25:53 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yMCoDvq7Q9h for ; Wed, 1 Apr 2020 14:25:52 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0151E3A0A1C for ; Wed, 1 Apr 2020 14:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585776349; x=1587590750; bh=MZYCE8SoHNS0JJ8o5F6Ns8jNJDYeJ9dBUKE fp8EQWC4=; b=f5LzjjUysPDd5tAGC0iLV0USKg53+MLPsqz4yjK4OnB66+HpYzD FcHihzAeHovymgKUqTRbW5Mtb/FSlWz26ofA6inJ2NMPUnISxGQBJD742tjwQCo1 gOn1W+rSFQb4SJxN61Ex0D+F7RPKyUxdje/LFy80mwNs3i5l0nHRCNcE= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200401210549.AFA6C16E323F@ary.qy> From: Damian Lukowski Message-ID: <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de> Date: Wed, 1 Apr 2020 23:26:30 +0200 MIME-Version: 1.0 In-Reply-To: <20200401210549.AFA6C16E323F@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 21:25:54 -0000 >>> It's the one you found. If the authserv-id has a non-ASCII UTF-8 character, >>> it's invalid under 5321 and valid under 6531. >> >> I thought we established that as soon as the authserv-id has non-ASCII >> UTF-8 characters, the mail is automatically - by definition - a 6531 mail: > > Sorry if it seemed like I said that. It's either a potentially valid > EAI message or a definitely invalid ASCII message. If your system > doesn't handle EAI mail, it's invalid. Ok, that is definitely an external factor, isn't it? The information, if the system which processed the email, handles EAI, is not contained within the A-R header. Is the information even available in the DATA portion of an SMTP transaction? Can one look inside an .eml file and decide if that email has been processed by an EAI capable system? > If there are bytes with the > high bit set but they're not a UTF-8 sequence, or they're not a UTF-8 > character allowed in an authserv-id it's invalid even if you handle > EAI. That part is fine, because this is decidable from the A-R header itself. From nobody Wed Apr 1 16:10: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 B59BC3A12BD for ; Wed, 1 Apr 2020 16:10:10 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTBZoqNq__FK for ; Wed, 1 Apr 2020 16:10:08 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823973A12B9 for ; Wed, 1 Apr 2020 16:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585782605; x=1587597006; bh=W/6GkNH7mgSQCe95jrI7oTkGxLIjO+bwnj4 CICJSfkg=; b=oC8HfiexY5cA1a9g4pk+4dZg4Ztu4EIGMwKWcp1cUYrCgmhgwaH GGTUYghYHIZlhdgCw3ac8GFGpIiuFAA7RJpMewIU3FZAG+a89Z9b9aNMwxXaPxcP hC7p03OZrnOPgSU/BbhJOx+zHwer8XaWbbc9/p8/FdQ2zbQGSaoQXaNI= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200401210549.AFA6C16E323F@ary.qy> <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de> From: Damian Lukowski Message-ID: <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> Date: Thu, 2 Apr 2020 01:10:46 +0200 MIME-Version: 1.0 In-Reply-To: <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 23:10:11 -0000 >>> It's the one you found. If the authserv-id has a non-ASCII UTF-8 character, >>> it's invalid under 5321 and valid under 6531. >> I thought we established that as soon as the authserv-id has non-ASCII >> UTF-8 characters, the mail is automatically - by definition - a 6531 mail: > Sorry if it seemed like I said that. It's either a potentially valid > EAI message or a definitely invalid ASCII message. If your system > doesn't handle EAI mail, it's invalid. Let's say the system is capable of handling EAI mail. RC6531 sec 3.6: > An SMTPUTF8-aware SMTP client or server > that requires accurate knowledge of whether a message is > internationalized needs to parse all message header fields ... If I understand the section and your new authserv-id definition correctly, an EAI capable system can process plain-ASCII messages, such that with then definition of > authserv-id = sub-domain *("." sub-domain) > ; Where sub-domain is imported from 5321 for ASCII mail > ; and 6531 for EAI mail. , sub-domain comes from RFC5321. If that is so, then this looks to me like a dependency cycle. To decide for an authserv-id whether to pull sub-domain from 5321 or 6531, one needs to know if the message is internationalized. But to obtain that information, one must have parsed all message header fields, per 6531 sec 3.6, including A-R, that is still waiting to be parsed. From nobody Wed Apr 1 16:18: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 EA3283A0C0C for ; Wed, 1 Apr 2020 16:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, 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 (1536-bit key) header.d=iecc.com header.b=n7CmbvcT; dkim=pass (1536-bit key) header.d=taugh.com header.b=SfrQadKp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn2ugpc4nbps for ; Wed, 1 Apr 2020 16:17:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C561B3A0C0A for ; Wed, 1 Apr 2020 16:17:54 -0700 (PDT) Received: (qmail 87754 invoked from network); 1 Apr 2020 23:17:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=156c8.5e852121.k2004; bh=p/zPCxlfYo38JB2nyZu/4tkTtTdWdvZ1yfTr+iz4gmk=; b=n7CmbvcTU4EP//fKd7VXMdFtjBFFp1xFjv8U9qPbjtEU5vGt0tzIwSLeh1pK3Trc2RBtIPfvXmsFbvM9cq1U0hXZFoCa1+3TO8NlouL5VYxU7Lr8HOy3ZD62Mqsj3DD90uuTEBej9I3bU0vqnQ2tyPO+o05tLeRSoCQJgYVPcEzXmZCFL6H+OatjpUIzJ2mfkCIxQJ9xSETRXRpLjp2tcpnQY6Hg197blC0ZQbeuf7k94RKpqcHMyum2jrOxtADG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=156c8.5e852121.k2004; bh=p/zPCxlfYo38JB2nyZu/4tkTtTdWdvZ1yfTr+iz4gmk=; b=SfrQadKplfjllfyhYid0jVYF5voMiLnk6lHGZDaq2uC5P5Wl+iaqfOhjPy/KVGk02LR2OdxNa/MiarG9a5qe5rsfKYjHuoQzHKaqu8ZRcIeYRugjndq5PQ8w8/k5HwW8GsuR+y1MDztAU2VR1rBKPHl3pXiUfJCFDLpOFuSrZU8rDUM9N+T7WBcHt1xK8+Zyn4wJTqNgc4qqnvE5S9ZrHnGza/BeOfXso4yWO9yzDDTK4k2KoVvckM/7Caczkw0k Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 01 Apr 2020 23:17:52 -0000 Received: by ary.qy (Postfix, from userid 501) id D56F316E3E38; Wed, 1 Apr 2020 19:17:52 -0400 (EDT) Date: 1 Apr 2020 19:17:52 -0400 Message-Id: <20200401231752.D56F316E3E38@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 01 Apr 2020 23:17:58 -0000 In article <4013d967-852c-e299-0973-03ba21db5c55@arcsin.de> you write: >Ok, that is definitely an external factor, isn't it? The information, if >the system which processed the email, handles EAI, is not contained >within the A-R header. Is the information even available in the DATA >portion of an SMTP transaction? Can one look inside an .eml file and >decide if that email has been processed by an EAI capable system? Maybe. The EAI flag is sent on the MAIL TO command. See RFC 6531, sec 3.4. If the recipient system adds the usual Received: header, it should include a "WITH UTF8SMTP" or "WITH UTF8SMTPS" clause. I have no idea what's in a .eml file, since the only spec I've seen for it is whatever some version of Outlook does. R's, John From nobody Wed Apr 1 17:32: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 8A36B3A15DD for ; Wed, 1 Apr 2020 17:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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, 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 (1536-bit key) header.d=iecc.com header.b=HV0hSfxc; dkim=pass (1536-bit key) header.d=taugh.com header.b=po+hDJdp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHzyGk4PK2Hh for ; Wed, 1 Apr 2020 17:32:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7CD3A15DA for ; Wed, 1 Apr 2020 17:32:12 -0700 (PDT) Received: (qmail 99231 invoked from network); 2 Apr 2020 00:32:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1839d.5e85328b.k2004; bh=R5AdRUg/Hpk189kNnwWz4Nsa8Ui96M3HkHlrOJkkrA0=; b=HV0hSfxcTsKiLSJFxRb2Ekpz8BaEYOKXUq+SvFWZAPK36XbK+O9FDZr6RCM/7KnX8T6eRfV1SucqISmgtZehsnCgxKMWwX+gPONamAR7lBywW2Dk3FOHwYR4Xs2nYMN+pTMdvCT99GbS+Tygl+0Ktqx6aOsk5oe8b0JaP4Y9NcgvN9k0lASam3c35B/QhGoCciDTYOCtiqezfCPdV+fH1piAXF4z51KzbUXAIfgJ3eqLeDvF2EhHDLUTTM5alC3a DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1839d.5e85328b.k2004; bh=R5AdRUg/Hpk189kNnwWz4Nsa8Ui96M3HkHlrOJkkrA0=; b=po+hDJdpFQ4A3QWsl8cghzN+OkRKhLCwS4xG7KgXPNpYoSAuxRc0fq7xCKXT3GZNXJ+Am5s/Y0Tum0FVzziK/kZLP4FtOhAgzfQoNpqzMFoNQ4rlMmxBVLWayz4n6yO5xjGOVa+2y9dcrEGzOEC4prbagURHBZtEqCFd/fSSpv+zWnfweDXXTJ0rVhSAiIv+eriFmG6hmPlbqjbdoQKTpa4iBFHsOVzqghi+CuFEyycc2+FGSZnADoM1oz3rLMQB Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 02 Apr 2020 00:32:11 -0000 Received: by ary.qy (Postfix, from userid 501) id 0B8AA16E4B5A; Wed, 1 Apr 2020 20:32:10 -0400 (EDT) Date: 1 Apr 2020 20:32:10 -0400 Message-Id: <20200402003211.0B8AA16E4B5A@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Apr 2020 00:32:15 -0000 In article <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> you write: >To decide for an authserv-id whether to pull sub-domain from 5321 or >6531, one needs to know if the message is internationalized. But to >obtain that information, one must have parsed all message header fields, >per 6531 sec 3.6, including A-R, that is still waiting to be parsed. In systems that keep ASCII and EAI mail separate, that info will be in the metadata, whether it arrived in an SMTP session with the SMTPUTF8 option. From nobody Wed Apr 1 18: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 4C08B3A07BC; Wed, 1 Apr 2020 18:05:12 -0700 (PDT) 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 4HJh65QJfIEW; Wed, 1 Apr 2020 18:05:09 -0700 (PDT) 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 7E4083A07B6; Wed, 1 Apr 2020 18:05:09 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id x206so1245628vsx.5; Wed, 01 Apr 2020 18:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8XvWPwmbBKQT+oI985760Xhqv/Ws+iddhNeBt/lriTQ=; b=LuE5Y7MzjuEGEBlrXbMSakYR891aP3zzYlcBWFl33wc2GjyFMD2LBd89BosUzLyH+0 2vwuHq3lxN2HmPWYAEEt6O++QNljMGx/pqQ8ouydo4CP0UNl1u1ukzl+3zg6blUcK0Ss eTck99TkhI7lrcq49cbBxl2VZ57rBMSDeowD2n1cyH29msFl2zTS8QxPQdLxDrYdbOpK wvlJanx7WXHIq8/pqKQCNo/wK73xidzbG5S3HvqH2JKjsy+0/AWcnErE9+FIQ/4UXzZI 2h2f2MnJONAGiMuJIjJ0VwUyBlPrGEb//dZknrNejxE5aN7IU2Ckt+r2XHfYaYEfnhhB Ws2Q== 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=8XvWPwmbBKQT+oI985760Xhqv/Ws+iddhNeBt/lriTQ=; b=mig42+AlwM0wufmgP4rSLM/Fa2UGTNUx+dz013684G2xGvXrwX8taoaMd4TBSrxw2A bZsgBLfhFu4qSvUWupfKy2GA2QDrV8LdDnnkSEkAPQfrbG4UWVfA7E5fY+V+qkX0Urr+ /CWlyDkvH8D9rvXB2GQNDW7jUGZuovIIpj0vzdX2apBT92WGB73WJBcP9mfqT6ilkM4/ Y3dLTxcdgomiuFI8p5l5BKYaJvISnB8d9PQ3xBEeXtmB2SZOjNL09jJadbwmPkMSrez1 oGWCufvZaO9qy5SdmyY5Rki3lbRGo6K6L+1h4jbC9jgjC1dmWGySEmI9Xi/Vu6X7YVL5 vPDg== X-Gm-Message-State: AGi0PuZ/xLF35LekBpE7NKTg4oZQYC9ru2sAnNCMx/pzZv3EGBQsy13o XWjOZawsqmNxaCkW6iNDk1j/RPd20KGzAiYjXqE= X-Google-Smtp-Source: APiQypLWPT9qWkhbcAHdSwRMFBrE3/S6h46YxVsQJg0THFxDE6Dd+2I5rPMWkhRklIgct9+HQToMAyBELPUwqGWPcAk= X-Received: by 2002:a67:f4d5:: with SMTP id s21mr480427vsn.8.1585789508261; Wed, 01 Apr 2020 18:05:08 -0700 (PDT) MIME-Version: 1.0 References: <158572481464.30894.8037097234628362447@ietfa.amsl.com> In-Reply-To: <158572481464.30894.8037097234628362447@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Wed, 1 Apr 2020 18:04:57 -0700 Message-ID: To: Qin Wu Cc: ops-dir@ietf.org, draft-ietf-dmarc-psd.all@ietf.org, last-call@ietf.org, IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000541bc505a2446433" Archived-At: Subject: Re: [dmarc-ietf] Opsdir 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: Thu, 02 Apr 2020 01:05:12 -0000 --000000000000541bc505a2446433 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On the process questions raised: On Wed, Apr 1, 2020 at 12:06 AM Qin Wu via Datatracker wrote: > Minor issue: > This document provide two registries, one is update of DMARC Tag Registry > with > one new element, requested from IANA, the other is DMARC PSD registry > maintained by [psddmarc.org] and following IANA registry style, I see one > is > standard registry, the other is non-standard registry, it is not clear to > me > non-standard registry should be discussed in this document, which introdu= ce > confusion, if we keep both, I am wondering why section 6 still requests t= o > add > an element to standard registry, which functionality we add is > experimental, > which functionality is not. > It's helpful here, I think, that the IANA Considerations section includes the IANA stuff, and an Appendix contains the other stuff. I don't think this is particularly confusing; the two are well-separated. Second related question, this draft updates informational RFC7489 with > additional components and rules, should the front page of this > Experimental RFC > reflect this or not? Nits: Section 1 Somewhere subdommains is used, > somewhere > sub-dommains is used, please be consistent. Section 3.5 said: > "Specifically, > this is > not a mechanism to provide feedback addresses (RUA/RUF) when an > Organizational Domain has declined to do so. > " > Should a reference be added to RUA/RUF, RUA/RUF needs to be expanded or a= dd > abbreviation section in the terminology section. > This is an experiment to see if RFC7489 should be augmented, i.e., is the experiment described here useful to DMARC? If it turns out it is not, then saying this updated the base specification wouldn't be such a good thing. If it turns out that it is, then the DMARCbis work (which is about to start up) will incorporate the experiment such that it becomes permanent. Section 3.2 > OLD TEXT: > " > If the 'np' tag is absent, the policy specified by the "sp" tag (if the > 'sp' > tag is present) or the policy specified by the "p" tag, if the 'sp' tag i= s > not > present, MUST be applied for non-existent subdomains. " NEW TEXT: " If th= e > 'np' > tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is > present) or the policy specified by the "p" tag( if the 'sp' tag is not > present > and =E2=80=98p=E2=80=99tag is present), MUST be applied for non-existent = subdomains. " > Section > 3.2 Change section 3.2 title from "3.2. Section 6.3 General Record > Format" To > 3.2. Changes in Section 6.3 "General Record Format" Similar changes can = be > applicable to other places. > I'll leave this bit to the authors and co-chairs to resolve. -MSK --000000000000541bc505a2446433 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the process questions raised:

On Wed, Apr 1, 20= 20 at 12:06 AM Qin Wu via Datatracker <noreply@ietf.org> wrote:
Minor issue:
This document provide two registries, one is update of DMARC Tag Registry w= ith
one new element, requested from IANA, the other is DMARC PSD registry
maintained by [psddmarc.org] and following IANA registry style, I see one is<= br> standard registry, the other is non-standard registry, it is not clear to m= e
non-standard registry should be discussed in this document, which introduce=
confusion, if we keep both, I am wondering why section 6 still requests to = add
an element to standard registry, which functionality we add is experimental= ,
which functionality is not.

It's he= lpful here, I think, that the IANA Considerations section includes the IANA= stuff, and an Appendix contains the other stuff.=C2=A0 I don't think t= his is particularly confusing; the two are well-separated.

<= /div>
Second related question, this draft updates informational RFC7489 with
additional components and rules, should the front page of this Experimental= RFC
reflect this or not? Nits: Section 1 Somewhere subdommains is used, somewhe= re
sub-dommains is used, please be consistent. Section 3.5 said: "Specifi= cally,
this is
=C2=A0 =C2=A0not a mechanism to provide feedback addresses (RUA/RUF) when a= n
=C2=A0 =C2=A0Organizational Domain has declined to do so.
"
Should a reference be added to RUA/RUF, RUA/RUF needs to be expanded or add=
abbreviation section in the terminology section.

<= /div>
This is an experiment to see if RFC7489 should be augmented, i.e.= , is the experiment described here useful to DMARC?=C2=A0 If it turns out i= t is not, then saying this updated the base specification wouldn't be s= uch a good thing. If it turns out that it is, then the DMARCbis work (which= is about to start up) will incorporate the experiment such that it becomes= permanent.

Section 3.2
=C2=A0OLD TEXT:
"
If the 'np' tag is absent, the policy specified by the "sp&quo= t; tag (if the 'sp'
tag is present) or the policy specified by the "p" tag, if the &#= 39;sp' tag is not
present, MUST be applied for non-existent subdomains. " NEW TEXT: &quo= t; If the 'np'
tag is absent, the policy specified by the "sp" tag (if the '= sp' tag is
present) or the policy specified by the "p" tag( if the 'sp&#= 39; tag is not present
and =E2=80=98p=E2=80=99tag is present), MUST be applied for non-existent su= bdomains. " Section
3.2 Change section 3.2 title from "3.2.=C2=A0 Section 6.3 General Reco= rd Format" To
3.2.=C2=A0 Changes in Section 6.3 "General Record Format" Similar= changes can be
applicable to other places.

I'll le= ave this bit to the authors and co-chairs to resolve.

<= div>-MSK
--000000000000541bc505a2446433-- From nobody Thu Apr 2 03:21: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 298F63A0F4C; Thu, 2 Apr 2020 03:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=CR07IcwS; dkim=pass (2048-bit key) header.d=kitterman.com header.b=NZ2Jm3Yf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0sSf9xENKoN; Thu, 2 Apr 2020 03:21:45 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D3C3A0F4A; Thu, 2 Apr 2020 03:21:44 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id CCF71F8026C; Thu, 2 Apr 2020 06:21:43 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1585822903; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=elwtJdcI0sj6iWF7A9KynSc0+TEwt2eMSns9FMSoEOM=; b=CR07IcwSbSLB5VEXv2vyooocIFzbBzvV3n80uTrxjeP60UldKrEsskxeOcL/AHPBGJP3+ mhHpz2P2FXeg0KICg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1585822903; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=elwtJdcI0sj6iWF7A9KynSc0+TEwt2eMSns9FMSoEOM=; b=NZ2Jm3YfLx5wO3jXu60/43+VtD0i6GiB5xpHctz2fyndOO81/Md+Wkz0TuFCgLFgulquj pWwUl/mU+fz/YRqOu8aMWn43qhGG+dqbb5jJf7dYXHwCAlVomOastUcNLKGvw/0xYVlEiUe SgcdF9e4zlRxKJ0Rt/8dAUIEeSY3pjiYarESK8cJHHgHQZHoL92AGdpW5f0RjW40bxFYSc7 hbcX6xkZesnxHakrPstFO/bo83Ofp+EQOsur+16pXvPoDAr+MfPEzGTTN33gISNHtJWxBGx FxXFBPheU3/fRE1en37ezRksCVxziit86lsX1RMdWghMO+RZs6RoG6SydtHQ== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 7909AF800E7; Thu, 2 Apr 2020 06:21:43 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Cc: "Murray S. Kucherawy" , Qin Wu , last-call@ietf.org, ops-dir@ietf.org, draft-ietf-dmarc-psd.all@ietf.org Date: Thu, 02 Apr 2020 06:20:29 -0400 Message-ID: <2100110.1RVLOuU0sI@sk-desktop> In-Reply-To: References: <158572481464.30894.8037097234628362447@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Opsdir 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: Thu, 02 Apr 2020 10:21:47 -0000 On Wednesday, April 1, 2020 9:04:57 PM EDT Murray S. Kucherawy wrote: > On Wed, Apr 1, 2020 at 12:06 AM Qin Wu via Datatracker > wrote: =2E.. Since I'm the draft author, I'll weigh in: > Section 3.2 >=20 > > OLD TEXT: > > " > > If the 'np' tag is absent, the policy specified by the "sp" tag (if the > > 'sp' > > tag is present) or the policy specified by the "p" tag, if the 'sp' tag= is > > not > > present, MUST be applied for non-existent subdomains. " NEW TEXT: " If = the > > 'np' > > tag is absent, the policy specified by the "sp" tag (if the 'sp' tag is > > present) or the policy specified by the "p" tag( if the 'sp' tag is not > > present > > and =E2=80=98p=E2=80=99tag is present), MUST be applied for non-existen= t subdomains. " The current text is crafted to define the new tag the same way that the=20 existing tags are defined. I would prefer not to be novel about 'np'. I t= hink=20 this would be better as a working group input for DMARCbis to consider=20 rewording how all the tag definitions are constructed. In this case I thin= k=20 consistency is important. > > Section 3.2 > > Change section 3.2 title from "3.2. Section 6.3 General Record Format"= =20 > > To > > 3.2. Changes in Section 6.3 "General Record Format" >> > > Similar changes can be applicable to other places. I have no problem with this proposed change. I think it improves clarity. >=20 > I'll leave this bit to the authors and co-chairs to resolve. >=20 > -MSK That's my thought. I'll wait for the co-chairs before taking any actions t= o=20 update the draft. Scott K From nobody Thu Apr 2 08:34: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 C887C3A15BE for ; Thu, 2 Apr 2020 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SNvcZr5XWCR for ; Thu, 2 Apr 2020 08:34:13 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE20D3A1765 for ; Thu, 2 Apr 2020 08:33:47 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id w2so3147255oic.5 for ; Thu, 02 Apr 2020 08:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sej0Zj/72Lx87ZDm8Dr74F5AfrRl/dM+A9vBpYPtPgA=; b=ftRKrHx85JkmaNsMeNM8N7u+/ww/IRhykA7PecIsXf3N7hvSfwCORHU4ILJ5pY3Foh lYmZ4FPCkpMvbjlPMXxgZBL3QAFnJg5EE7bDcsCAQleKxWnOJF8c6CJwL7udLCONNxz1 AhNjpPFPFz9S08MIP/02k5YMW7y0zL75lTdM938vUDqgPAobE9+83GHeXUMdf3SuZdph lLtDgbtQRdVjx/P4Dn7jSRqxVzQIfYPuvupyMQ1Oix5r9Q8jkqIKr7wJxMHf9zlgGsSm G9FlOXDY0suc2w7VOrxE2K7ibaAbn7SfBvpQ+liytLEKHVRCQerbLuyH/3M36mN7U6Jg 4xFw== 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=sej0Zj/72Lx87ZDm8Dr74F5AfrRl/dM+A9vBpYPtPgA=; b=Y4X2q7cVUQY6eEu1OgBVyrl0NTRZqhLarkIxUxP6J1T+BtRx5EZ9LA6yu2GzE0yI1e Mgs4hgnfzubxQf7wX/iNu7XbLGBzqjiMugFMEiHupy0JHRFL7BW3/DYpSQCwCU/ijNGF IU5K6GNsPgLbE296fexWWlccjueVd1S/MrJsQB+nlKDryIhLvxVuAcrVjLezULl8kzqb ajs7Eh57NtJjUzzi3icB1mxMu50a5qke7gq+uU4yIUx193PLnqYRY2M8Z3V0WPuu/KHY z5SesvbtO1sG07vqVckW/+MtbRT6SfGLNjULGy6Iml71gauF02bwAhOXaNfyuxytI7za iLsA== X-Gm-Message-State: AGi0PubqngoXKitWgeEt5SM2gh/mp0cPIkFfn2M7fKZd6bPmz0CY2bec 2D/Q3d3lAA6hJcDvxDk1WN9u2rvjOKsSD1B/CtY9LA== X-Google-Smtp-Source: APiQypL0RaBGOV6TR9HM3DGGNZuZ6YFsvr2ipFjLhfyKo821y9HWx50pe+I6M/Cm/13LSG6bAXbzbciVM+QFwx8sc1k= X-Received: by 2002:aca:4fc3:: with SMTP id d186mr2501365oib.171.1585841626419; Thu, 02 Apr 2020 08:33:46 -0700 (PDT) MIME-Version: 1.0 References: <158572481464.30894.8037097234628362447@ietfa.amsl.com> <2100110.1RVLOuU0sI@sk-desktop> In-Reply-To: <2100110.1RVLOuU0sI@sk-desktop> From: Seth Blank Date: Thu, 2 Apr 2020 08:33:30 -0700 Message-ID: To: Scott Kitterman , IETF DMARC WG Cc: "Murray S. Kucherawy" , Qin Wu , last-call@ietf.org, ops-dir@ietf.org, draft-ietf-dmarc-psd.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000d1176805a2508637" Archived-At: Subject: Re: [dmarc-ietf] Opsdir 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: Thu, 02 Apr 2020 15:34:15 -0000 --000000000000d1176805a2508637 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 2, 2020 at 3:21 AM Scott Kitterman wrote: > That's my thought. I'll wait for the co-chairs before taking any actions > to > update the draft. > Scott, please prepare a new version of the I-D based upon your comments, but don't post it until IETF Last Call finishes and all other feedback, if any, has been folded in. Seth, as co-Chair --000000000000d1176805a2508637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2020 at 3:21 AM Scott Kitt= erman <scott@kitterman.com>= ; wrote:
That's my thought.=C2=A0 I'll wait for the co-c= hairs before taking any actions to
update the draft.

Scott, please prepare= a new version of the I-D based upon your comments, but don't post it u= ntil IETF Last Call finishes and all other feedback, if any, has been folde= d in.

Seth, as co-Chair
--000000000000d1176805a2508637-- From nobody Thu Apr 2 11:49: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 075923A0C0A; Thu, 2 Apr 2020 11:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=QuhLg5cn; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ZGX8nGPA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czKi6wbagRfe; Thu, 2 Apr 2020 11:48:56 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C9F3A0BCB; Thu, 2 Apr 2020 11:48:56 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CBB9DF8026C; Thu, 2 Apr 2020 14:48:54 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1585853334; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=x5uQ9WIG425PDHL8G77FEsacka+E2nUSsniLEuS9k+M=; b=QuhLg5cnjHgPobdxg1LqYTKOAOHdWDp4RgFiUMpeI5VjLDB4okC9TLag4JFkGWhVIBVgC FLpgHey+jbrdEpmAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1585853334; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=x5uQ9WIG425PDHL8G77FEsacka+E2nUSsniLEuS9k+M=; b=ZGX8nGPASCmeZDW/DJo/TGL/OhxbQ71AXHh8q5wlhnurizylAvq/kGnFHvQIWefOuPiCv XMGqlejJFveXdJ6ZTiHwlA6sdCcejVV32eisLjZVBkUrCSfnD4bd2Dar7HeM2ZkqGBOZwZ+ ASH4NuiNza0r3dVI1e8jwybByhUN5j8cAALd1xB6y0kOeG6P6WTE6RKDx4IdmkRCHdqqeVN 2oFJsGzPBgaY+ti4rMN6PgBV5P3decrQTYUOUB3kRMJcHpML4HR9D+9cmNJAxShE68umeM+ 6d89yqMnuGLYiCbQXA2UDcVkX/B68pQzRjj/Pnwy3yNxR+ztjyV0Kya5wjLg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 8D842F80042; Thu, 2 Apr 2020 14:48:54 -0400 (EDT) From: Scott Kitterman To: last-call@ietf.org Cc: Seth Blank , IETF DMARC WG , ops-dir@ietf.org, draft-ietf-dmarc-psd.all@ietf.org, "Murray S. Kucherawy" , Qin Wu Date: Thu, 02 Apr 2020 14:48:54 -0400 Message-ID: <1904862.B7rBbPpL6e@sk-desktop> In-Reply-To: References: <158572481464.30894.8037097234628362447@ietfa.amsl.com> <2100110.1RVLOuU0sI@sk-desktop> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] [Last-Call] Opsdir 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: Thu, 02 Apr 2020 18:48:58 -0000 On Thursday, April 2, 2020 11:33:30 AM EDT Seth Blank wrote: > On Thu, Apr 2, 2020 at 3:21 AM Scott Kitterman wrote: > > That's my thought. I'll wait for the co-chairs before taking any actions > > to > > update the draft. > > Scott, please prepare a new version of the I-D based upon your comments, > but don't post it until IETF Last Call finishes and all other feedback, if > any, has been folded in. > > Seth, as co-Chair Done. The updated version (XML, text, and rfcdiff) can be found in the WG GitHub repository [1]. Scott K [1] https://github.com/ietf-dmarc-wg/draft-ietf-dmarc-psd From nobody Thu Apr 2 16:00: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 B5F053A1BBB for ; Thu, 2 Apr 2020 16:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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 we2N6By70E2r for ; Thu, 2 Apr 2020 16:00:24 -0700 (PDT) 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 BA98B3A1BB3 for ; Thu, 2 Apr 2020 16:00:24 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id o3so3756098vsd.4 for ; Thu, 02 Apr 2020 16:00:24 -0700 (PDT) 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=8CEkjPUfst48h9Msnipp9bXfOkpF+EojlY0Jt2Vhjfo=; b=m9OjycTTbfuSdwetiquA+/MHLZYQZONpbQKesCHWoTVyhi9mJ0xO1cTg7GqKKqtgxE MLykmQyghKMyPnRkziJN6q/VrF1Uw2zxp0YsbHE0H0kDrEgOvq/Ko1JtaU/AtA0riwIm 8tBiMrUKtYvzHk1In+JQBaq0Q9AU6+Hc1i9ibv6LCqfnFFRnLRlqok71CBVrXixmKpzK 59ejlPW6z7tL1rwwd2G04LIE3e21jab8IVNINk1cIvY3+ZYUVc5i9JL7qfpDd8Rsm2aN KpRe0jh5wS9yExf4VUuBOWG31PYil4AjcXL0nkIwIXwyZx/DbfuRlLUKPuCXm6rGGOOY W/aQ== 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=8CEkjPUfst48h9Msnipp9bXfOkpF+EojlY0Jt2Vhjfo=; b=fLJ8oUE5YpX6knZsGvt3722fB/rFDUO0nO2s5t33rfTqQgVr6XovDeT95oAoeJXNMw d4f1XrFblfvRwqAjzJ54uZ4HVoHSQRGZjVweIXo/WrXnGAU2CR5ds798cuDExnEb+WV1 iZAKO4o70/Rnx3ielo5DCwFAY7BZishvITiPT2SBVjMeGBbF6bbFz6Fi26QaXjZsWDw9 wJFoQi7sDX/AAXNMe2vhdHEWTLiwMXfvt2rHDTKtacGb3jbtS+CA5X5Uab7sE0SnHAMA HIG6/rajCgdLanLNy76E+39IHKohTCCSOieJxSMBIA/97CPBwan6tRffP6QW736K97Bu JdkQ== X-Gm-Message-State: AGi0Pua2glh9Ro5icCN6+g+r7mYUD+TkOeNbSWNRnc98Qv2lgx4ttpcB OJYs/VqOY0eVMNC75Fxtp11AQoP0wrm6uJ4UZ0xC X-Google-Smtp-Source: APiQypIroqlB2vcZRO7FtBREaEMiCnnLaJwAhpRjCuTV/+rGlZh2J03ezXyUreHp4q1JAz9qvxOWJOFRSLAUVI/VTjw= X-Received: by 2002:a67:7d93:: with SMTP id y141mr4043243vsc.124.1585868423214; Thu, 02 Apr 2020 16:00:23 -0700 (PDT) MIME-Version: 1.0 References: <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> <20200402003211.0B8AA16E4B5A@ary.qy> In-Reply-To: <20200402003211.0B8AA16E4B5A@ary.qy> From: Brandon Long Date: Thu, 2 Apr 2020 16:00:10 -0700 Message-ID: To: John Levine Cc: IETF DMARC WG , Damian Lukowski Content-Type: multipart/alternative; boundary="0000000000000741f405a256c405" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 02 Apr 2020 23:00:27 -0000 --0000000000000741f405a256c405 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 1, 2020 at 5:32 PM John Levine wrote: > In article <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> you write: > >To decide for an authserv-id whether to pull sub-domain from 5321 or > >6531, one needs to know if the message is internationalized. But to > >obtain that information, one must have parsed all message header fields, > >per 6531 sec 3.6, including A-R, that is still waiting to be parsed. > > In systems that keep ASCII and EAI mail separate, that info will be in > the metadata, whether it arrived in an SMTP session with the SMTPUTF8 > option. > Does anyone implement it that way? We just upgraded our parser to handle EAI mail, and the parser returns requested data in UTF8, decoding 5322 mail or going straight from 6532 mail as necessary, with specific accessors needing to know what the possible encodings could be. We then check when we go to send mail whether we should specify SMTPUTF8 on the output.. as for input... We see plenty of mail transferred without SMTPUTF8 that contains UTF8 (or other 8-bit characters, but the majority of that became UTF8 probably close to a decade ago), and we just handle it. Unfortunately, everybody thinks they can just make their own emali messages because its a text-like format, and they're very often wrong. Brandon --0000000000000741f405a256c405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 1, 2020 at 5:32 PM John L= evine <johnl@taugh.com> wrote:=
In article <= 6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> you write:<= br> >To decide for an authserv-id whether to pull sub-domain from 5321 or >6531, one needs to know if the message is internationalized. But to
>obtain that information, one must have parsed all message header fields= ,
>per 6531 sec 3.6, including A-R, that is still waiting to be parsed.
In systems that keep ASCII and EAI mail separate, that info will be in
the metadata, whether it arrived in an SMTP session with the SMTPUTF8
option.

Does anyone implement it that w= ay?

We just upgraded our parser to handle EAI mail= , and the parser returns requested data
in UTF8, decoding 5322 ma= il or going straight from 6532 mail as necessary, with
specific a= ccessors needing to know what the possible encodings could be.=C2=A0 We the= n check
when we go to send mail whether we should specify SMTPUTF= 8 on the output.. as for input...

We see plenty of mail trans= ferred without SMTPUTF8 that contains UTF8 (or other
8-bit charac= ters, but the majority of that became UTF8 probably close to a decade ago),= and we
just handle it.

Unfortunately, e= verybody thinks they can just make their own emali messages because its a t= ext-like
format, and they're very often wrong.

=
Brandon=C2=A0
--0000000000000741f405a256c405-- From nobody Thu Apr 2 17:10: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 21F803A08F8 for ; Thu, 2 Apr 2020 17:10:51 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=N1kjSBYA; dkim=pass (1536-bit key) header.d=taugh.com header.b=jMnUDMn7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6VLPXhsrOyb for ; Thu, 2 Apr 2020 17:10:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D420E3A08ED for ; Thu, 2 Apr 2020 17:10:39 -0700 (PDT) Received: (qmail 59674 invoked from network); 3 Apr 2020 00:10: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:references:mime-version:content-type:user-agent; s=e917.5e867efc.k2004; i=johnl-iecc.com@submit.iecc.com; bh=Ru71ZcURM9aZhBNmaqjQG8y/vmtyROGAW4wUu4WtJag=; b=N1kjSBYAbj+kxyDAYQG4aynfVzv6U64WzE3jF27j8y9RFVEGJnJrCK5Nl2CU/ebfFnMTJwC0y3YAjkWbmERlac0SW2UuP5H0yQe7SnqcxtD1xqbDqAK8rIrS23dcoRp33KoHB99oOS31SPLem40vrKanSPqBiodUfVqJ52vT+kMmCrx+ULQcmu1BiuufMPorjhsnVeQsxJaLTNMDLJtwoYzt/QF5IZxX94r1eE+U95LerqkHo3QzhSjo1BcEycOL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=e917.5e867efc.k2004; olt=johnl-iecc.com@submit.iecc.com; bh=Ru71ZcURM9aZhBNmaqjQG8y/vmtyROGAW4wUu4WtJag=; b=jMnUDMn77YRQCHWt3+87u1iwBN+BZFnA/m4Dcqa+tfOHWeAXYYFFIGZcbHCV9MTPqZVtNjtI04hKU7GsQ/fDy7w5Gf8LfV/028Oj6UOt8z/4BGUulFCGZTAcj/wDXGmjsdHnu6UDay793yN65QhuWRuSRjtVS6dqw4OqoUKK4z7pt0D9DoPBgRZZiXDUnQGRqxBA2gfFCDxVRiwHa+vPGIsVRwEjF7bx4nHsbrrPxnw1RB9wv5YHBPdvCjKpLTjw 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; 03 Apr 2020 00:10:36 -0000 Date: 2 Apr 2020 20:10:36 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" Cc: "IETF DMARC WG" In-Reply-To: References: <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> <20200402003211.0B8AA16E4B5A@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 00:10:51 -0000 >> In systems that keep ASCII and EAI mail separate, that info will be in >> the metadata, whether it arrived in an SMTP session with the SMTPUTF8 >> option. > > Does anyone implement it that way? I have no idea. I don't in my code either. > Unfortunately, everybody thinks they can just make their own emali messages > because its a text-like format, and they're very often wrong. Surely you're aware that 50% of all programmers are of below average skill. 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 Apr 2 17:18: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 B5FCB3A093F for ; Thu, 2 Apr 2020 17:18:20 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=EYeULZR3; dkim=pass (1536-bit key) header.d=taugh.com header.b=al0FjPyp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF6LGooQrwd5 for ; Thu, 2 Apr 2020 17:18:03 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B03A3A094A for ; Thu, 2 Apr 2020 17:17:22 -0700 (PDT) Received: (qmail 60973 invoked from network); 3 Apr 2020 00:17:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ee2b.5e868090.k2004; bh=SYNKw65IuoxnsWH9mj0qNxiRmBAIJFpkGKyzgiQe3a0=; b=EYeULZR3Aa12zXgEOYjR6tEfvDWsVvKUa0WgV9kpsjN2Egh2qEjZKxa0C+0tFvu8y2JIZ15BCYDjfGL3tQiRk6uhBPLl9+NZmL+Sv1WIj0krvZpevxZHHs6WL7wfbbCaGlx73UoBxEDhNqBMMN8JpaoHhfSmL8RaSpuB7Iff6r52GMgRdc3fFa5iCR8OhIWwtsjypbGi6+QeYVFRYKqFfDub5uaNCOAephLEMTfJoVs91H1Ca905dXQpCnbFyCST DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ee2b.5e868090.k2004; bh=SYNKw65IuoxnsWH9mj0qNxiRmBAIJFpkGKyzgiQe3a0=; b=al0FjPyp+rbII6QWPqyrKqFlF/SmJyRs1LjmK/ycmmV3qQ5UzGfZ8WuiHy10+g6dPMo9PAHp51nZ9BUMomK5/F3Cb5MwBTd88pd+yixTBlrObBrYYugVEM9vDimE/o9fH6zkbmQGy4xTLlnWxHUMnQoUxVI6RfXkJeBXqs9AZEeHkTiS55Sux9XKPo7qVMnco+NuUEHdGGA0eBZh5if049BJRHj4hqNE7nibAnE3bRgEXdaEwgWHrjtpG6SqNOIc Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2020 00:17:19 -0000 Received: by ary.qy (Postfix, from userid 501) id 8DC9D16F0CF0; Thu, 2 Apr 2020 20:17:18 -0400 (EDT) Date: 2 Apr 2020 20:17:18 -0400 Message-Id: <20200403001719.8DC9D16F0CF0@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: scott@kitterman.com In-Reply-To: <1904862.B7rBbPpL6e@sk-desktop> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [Last-Call] Opsdir 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: Fri, 03 Apr 2020 00:18:24 -0000 In article <1904862.B7rBbPpL6e@sk-desktop> you write: >> Scott, please prepare a new version of the I-D based upon your comments, >> but don't post it until IETF Last Call finishes and all other feedback, if >> any, has been folded in. >> >> Seth, as co-Chair > >Done. The updated version (XML, text, and rfcdiff) can be found in the WG >GitHub repository [1]. Internet drafts are intended to be cheap and plentiful. I'd encourage you to post what you have. If it needs further tweaks and another posted version or two, that's not a big deal. R's, John From nobody Fri Apr 3 09:10: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 F00183A1A36 for ; Fri, 3 Apr 2020 09:10:23 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1LH0ywimqpU for ; Fri, 3 Apr 2020 09:10:22 -0700 (PDT) Received: from sigil.arcsin.de (sigil.arcsin.de [46.38.233.110]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9920F3A1A05 for ; Fri, 3 Apr 2020 09:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-language:content-type:content-type:mime-version:date :date:message-id:subject:subject:from:from:x-amavis-category; s= dkim01; t=1585930211; x=1587744612; bh=fdEP2Av6SKktwCMn3xMchUjrs d0A4puC/owwqPXyvgo=; b=F1fTL/2gN3Pbt2AutgCD9Q3BzW7+QQ+xdC6nT4u4K pXp2SegcFl6zEU6SLJWDaU0mK7Plj+wbrSGot6q0fu90s7oNsQ8pFQN/WIQTw/ZD EVRbY+3QhbK4dV5F8u+9RcAFoFWVlA15U/3jIQzh3+kDbcneyI5rkuwKyY6D+vCl tc= X-Amavis-Category: sigil.arcsin.de; category=CleanTag From: Damian Lukowski Autocrypt: addr=damian.lukowski@credativ.de; prefer-encrypt=mutual; keydata= mQENBFBpf4EBCADX2KZo3C61n0ZMslgS/4a8rvylTXKQTtalxzHXRrV11ksNR8gtVsxRPBTd lwcNnEgADLatuHLZ63ks1T1ePHKDa8zQtCqmvbYAtoKMm8lB91VlSkxcO5gEObU29uud37QB s26wzZ35uS3jvtgSFijeI3ukLYsMh2EPa4MdzRojVXBXaTiDmU4mw+ei3P9g/NjlD48R2qr8 ATC1hu8LZ1ln/1BZ579uIjVbtyHeRNTcBQCMdo0KU8/ax6zP1GGSuJiMk4QvO7LCx0NzjcOV DXzWFT5OBK0KYacaDqIvOFNot/E+lVl5B66t3/4cGfzpCaWwGwXcRKgqotcDwn7YVE4dABEB AAG0LURhbWlhbiBMdWtvd3NraSA8ZGFtaWFuLmx1a293c2tpQGNyZWRhdGl2LmRlPokBOAQT AQIAIgUCUGl/gQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQyMoDfzgSmvQ+cwgA ghoIZUHSUfsDaFAI4dmEbO4XFshUj5h/GDMT67vTF1pHlt19Rv+QUuXdQCCO7EVYqzC0TOro zZk4ckwHixWrkjsumbF3OlYc9bevL63ohXu3qclVFU+Vl3vIOmigV+FA50xKcdJw1zWqki8N p8wbTIsI8F1BQtDo1Ix5MS/aDWyc4VvzNRuKet1VXtGoQedVI5cU1heHYqFZdTafHXVodxF+ hd59rGvWTXeIHMBnI5+UlReOHmFGhF5efyqJIkCLNRnnYg9RaPyLTIlw2suotEle82b7n2tg /hOEegp620zjPmyiVZjvFFD1nUoeGnWHMjJWrKCb9p8QP3rV7UwzErkBDQRQaX+BAQgAszVi k9XvjuXcRerQELFjWLS129X1zhNShunC5Bp1FghtnbmdwPIT6Ep7VhEFSB+43PX7raR8dzvY FmDV6WlH9cimWV/3c3LSJr41tzzyObrnj/cjBzzMYjS2Ls5ficU8lp1+nNyN1Ns0YB4VWwpC zSGsHTaUbIVv1e82216Lvp80ektbGm2vra7aLac6ZKM0/wtuephHZn2w6xUJRADMo79Dxzjz iXr1Eg5YCvO2TIu305eq2Mgshbq9F429JJs4iKiGOdanBlVwtklP0LkM6s2Az2ahgprnbgZD NwshFb5oP9GGTBlzTSkxzHJIx1CVkofyApOtm90Rn8/Peme4iQARAQABiQEfBBgBAgAJBQJQ aX+BAhsMAAoJEMjKA384Epr0sy8IANUKmPlMYzTh61WXNHDcFF0w9jmgx8zrICtdnGG8J1Uf jCVnwsS3YGfeMVVIiecfkEDsrtwun9iij99pUeo9YAbqZlMXRQ19GPq+AdDrWSc1kX4QlV8l 7vzhUMw5Nj74OJQWGEkxtV1fVYs0MEyN7hqQG5TCOANKItzTmNaCHadHsSUjU6LKFzu4q6Wb Vophv18+PVBBr/Hiu9Kt0P3OBAkuoWPzgGdXh6bXstffO6jsNM1/kA1YW0I4khx8OCd5lNgq 3ij3hMZo9Z8dTBzTD5bFlKf3uzzNXl3YQbTs4+zl00QMG1HQJu6abazC5VXAvoLtXHdC+9HP nFVi+roC++Y= To: dmarc@ietf.org Message-ID: Date: Fri, 3 Apr 2020 18:09:44 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5EB62139E98E18D557E76293" Content-Language: en-US Archived-At: Subject: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 16:10:24 -0000 This is a multi-part message in MIME format. --------------5EB62139E98E18D557E76293 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit RFC8601 sec 5 states: > any MTA conforming to > this specification MUST delete any discovered instance of this header > field that claims, by virtue of its authentication service > identifier, to have been added within its trust boundary but that did > not come directly from another trusted MTA. In my opinion, a header that does not conform to the specified authres-header-field in the RFC, is not an Authentication-Results header, has no authentication service identifier, and as such cannot claim anything in the context of the RFC. So suppose there is a mail system with an UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the authserv-id into quotes, because it cannot use it without them, as discussed in the separate thread. What should the system do with an A-R header of an inbound message that incorporates the system's authentication service identifier without using quotes, but that otherwise would be syntactically correct? Again in my opinion, the system needs to keep the header, but what is the RFCs intention? --------------5EB62139E98E18D557E76293 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

RFC8601 sec 5 states:

any MTA conforming to
this specification MUST delete any discovered instance of this header
field that claims, by virtue of its authentication service
identifier, to have been added within its trust boundary but that did
not come directly from another trusted MTA.

In my opinion, a header that does not conform to the specified authres-header-field in the RFC, is not an Authentication-Results header, has no authentication service identifier, and as such cannot claim anything in the context of the RFC. So suppose there is a mail system with an UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the authserv-id into quotes, because it cannot use it without them, as discussed in the separate thread.

What should the system do with an A-R header of an inbound message that incorporates the system's authentication service identifier without using quotes, but that otherwise would be syntactically correct?

Again in my opinion, the system needs to keep the header, but what is the RFCs intention?

--------------5EB62139E98E18D557E76293-- From nobody Fri Apr 3 12:59: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 7A2C53A0746 for ; Fri, 3 Apr 2020 12:59:47 -0700 (PDT) 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 qVmiVrLA77_X for ; Fri, 3 Apr 2020 12:59:45 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 CBB043A074B for ; Fri, 3 Apr 2020 12:59:45 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id w14so5757042vsf.7 for ; Fri, 03 Apr 2020 12:59:45 -0700 (PDT) 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=itVulPW9TYmryHuB9mdJN9iRK8tXVl3FR/vPOQBo3AQ=; b=tvpO98yt10Q3p53ofUD7dIglRmi9GvjtunnP0pLIjbOkut4+EAEUp9X97d/1FSSCnI QaZSS/P+u90BOeM6DAU9O0gHFSI8PizuBcM8s9vqPd7zCMKwA+8xnUerHrmkLnlArxhl Z1+TATSy+UcD8QZl73cjkeF5R2+54vfui6E+NoQzS8xeS9x7R7uyA4QPfaocMhH7C1Eb /OMjTvvNLLmPbGGwUvMma7TSrRwfFSeotxiy1jWC7129+5oJb5aofUuLm/tempBgoUHk nHWDWAPYcBroEX0Zxhe9aTfh+VeOi5VpM26r/1TdOh5HjpBHyKdC1bjeL8oPot3ax8YR jtqw== 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=itVulPW9TYmryHuB9mdJN9iRK8tXVl3FR/vPOQBo3AQ=; b=ZTdz91qO/KQDInr4iQNhgNo6O4RLseAWyxjmB6QEh1+ihIrHXVdYyVp3rJAMLrIVsV rMG3GkznkNnSOcdC9howa/KagtaMhtwUXqAr6fVZiHBZsx0LgcI1UE1Rzl4FrPJAW5Nj 5paXLfba6y98H3tgdCxtizOjbA1lGeHz+CR3WjjOlkHOVtK+7pa0vKTJ8u0hg9ftRvaD INvP88K/r4fmT81FBEvDRFk1K5NX7nz7zTLQvZJ1T4N5HmWdNTwh7OcMHWxWfaBFPo/T d40qOEb33bguZugzuZpYsMSvAlnJzGjDOve7RC32nRToyV/khG97Y/JTeIuLscBRVqei DBPw== X-Gm-Message-State: AGi0PuYA0Z7EfEc/dN+BqRhbASXaPw7DWdwAUUzdgwrPh7QjZDZiZNky AkgSH7pjztCZb71oGOMY6T81YrL0Yn/F30Xi84hOtdY= X-Google-Smtp-Source: APiQypKo9pzQAJgeRh/it6pnNUzfaa38XxcN3rBXiu5EGd0ucHUEBQT0oDut7ydqzqldPO/IRdr8Gmcu0G+YDmMNr/I= X-Received: by 2002:a67:2ed2:: with SMTP id u201mr8353700vsu.209.1585943984266; Fri, 03 Apr 2020 12:59:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brandon Long Date: Fri, 3 Apr 2020 12:59:31 -0700 Message-ID: To: Damian Lukowski Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000d13f0c05a2685bf5" Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 19:59:48 -0000 --000000000000d13f0c05a2685bf5 Content-Type: text/plain; charset="UTF-8" I can see there being an issue here if the inbound smtp server that would normally remove existing AuthRes headers for its admd before adding its own uses a different algorithm than any downstream systems used. In particular, theoretically the inbound smtp server may use software from a different source than the spam system or the clients which consume this header. In practice, I don't know how common it is for clients to consume this header. Also, any mis-handling should be treated as a bug. The system should remove the quotes when comparing, and should also do any decoding to get the admds into the same format. Brandon On Fri, Apr 3, 2020 at 9:10 AM Damian Lukowski wrote: > RFC8601 sec 5 states: > > any MTA conforming to > this specification MUST delete any discovered instance of this header > field that claims, by virtue of its authentication service > identifier, to have been added within its trust boundary but that did > not come directly from another trusted MTA. > > In my opinion, a header that does not conform to the specified > authres-header-field in the RFC, is not an Authentication-Results header, > has no authentication service identifier, and as such cannot claim anything > in the context of the RFC. So suppose there is a mail system with an > UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the > authserv-id into quotes, because it cannot use it without them, as > discussed in the separate thread. > > What should the system do with an A-R header of an inbound message that > incorporates the system's authentication service identifier without using > quotes, but that otherwise would be syntactically correct? > > Again in my opinion, the system needs to keep the header, but what is the > RFCs intention? > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000d13f0c05a2685bf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can see there being an issue here if the inbound smtp se= rver that would normally remove existing AuthRes headers for its admd befor= e adding its own uses a different algorithm than any downstream systems use= d.

In particular, theoretically the inbound smtp server = may use software from a different=C2=A0source than the spam system or the c= lients which consume this header.

In practice, I d= on't know how common it is for clients to consume this header.

Also, any mis-handling should be treated as a bug.

The system=C2=A0should remove the quotes when comparing, = and should also do any decoding to get the admds into the same format.

Brandon

On Fri, Apr 3, 2020 at 9:10 AM Damian Luk= owski <rfc@arcsin.de> wrote:
=
=20 =20 =20

RFC8601 sec 5 states:

any MTA conforming to
this specification MUST delete any discovered instance of this header
field that claims, by virtue of its authentication service
identifier, to have been added within its trust boundary but that did
not come directly from another trusted MTA.

In my opinion, a header that does not conform to the specified authres-header-field in the RFC, is not an Authentication-Results header, has no authentication service identifier, and as such cannot claim anything in the context of the RFC. So suppose there is a mail system with an UTF-8-non-ASCII authserv-id. When creating its own A-R headers, it puts the authserv-id into quotes, because it cannot use it without them, as discussed in the separate thread.

What should the system do with an A-R header of an inbound message that incorporates the system's authentication service identifier without using quotes, but that otherwise would be syntactically correct?

Again in my opinion, the system needs to keep the header, but what is the RFCs intention?

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000d13f0c05a2685bf5-- From nobody Fri Apr 3 13:02: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 EF5B03A090F for ; Fri, 3 Apr 2020 13:02:14 -0700 (PDT) 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 RhvBQkqZ4y9N for ; Fri, 3 Apr 2020 13:02:13 -0700 (PDT) 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 B33873A08F9 for ; Fri, 3 Apr 2020 13:02:13 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id e138so5720440vsc.11 for ; Fri, 03 Apr 2020 13:02:13 -0700 (PDT) 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=qdW1mXQhkOVn5IuQRgFLXThnTM6v2WvEi/Py8Di0oCE=; b=ld9Coll260nYa1j0wFjHNdRvkayXBASIEpy8YReQJeBTOzv/52AJYzUwlAxz9nPlUJ uCWF1TPV74MzBoT/RDYB8xDBZcgik2p+f98yKrw8laGFTal3GvDKOBsoHqprjoYG8um2 nlv7/BpnCccSDmfo+VQcfQxZaPvdE6RYZaFMp13CHwx8Zgwpor3S4y8rZ1WRKKdH/ieK hxdNfndPfXbeuNz4snQk7hpySXOXV7FsWSp9ZpATmt8BN2HQJ7x7cwr0OvDTz6M8e8e5 iKubK1WVwE/njfHqUwoX2GVcFZvHR87E5tTeyf+rgrNgMt/Smr5KTyC0AT+UTd0jYmRp auKQ== 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=qdW1mXQhkOVn5IuQRgFLXThnTM6v2WvEi/Py8Di0oCE=; b=r3weqlXG5P1/E/lkDRjnr1hoxZ56+nbvUSDlSBjX1Ffd0OAsclNg7+TNBSOIS+hBjQ SohtITt/WZlJJdYZx9x9tGFKgHLSv3EIpGwsR8qUZODHci1dEf6Daeky2TAFO7KDJeRJ ihQrdSBdsI7QAwQjM+Xdo7QUnlGy/McHj0UQqwqgx8eLP8VSJfRQIUwsvQRKVFZOo3pW JbgRe+MgeT0G+V3v+AwfEpuFfMTM6phcFCx1siW2wxPGRVqpXj2a5e8ITS62l/XY7p6r DONx8tuyrCAAIBkS92mhrDY7m0ifDXn2brnh9c+nYUgH0g2ng019JPFG9TjrEVaDEpKJ oJLQ== X-Gm-Message-State: AGi0PubE43dSCmfuWIxY+CxaOovB3YCskKno13InLBKl3RfyoK3mXSQ8 JPZkmn1pz5sNiX7rZIHK8TQ04eicA/w5KSOZssnt X-Google-Smtp-Source: APiQypKRWvznPK0R9IR545mrbm0m1Qq0Z6J6FaPxFXY9LEdOLQ9GKRyS4Yweq+hDx4XfF4KrKBLoQPMLgckoiLbok64= X-Received: by 2002:a67:2ed2:: with SMTP id u201mr8365348vsu.209.1585944132284; Fri, 03 Apr 2020 13:02:12 -0700 (PDT) MIME-Version: 1.0 References: <6b4c7533-ebee-796b-e00e-a2bb4075081f@arcsin.de> <20200402003211.0B8AA16E4B5A@ary.qy> In-Reply-To: From: Brandon Long Date: Fri, 3 Apr 2020 13:01:58 -0700 Message-ID: To: John R Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="000000000000a3e9c705a26864a7" Archived-At: Subject: Re: [dmarc-ietf] Definition of "value" in RFC8601 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:02:15 -0000 --000000000000a3e9c705a26864a7 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 2, 2020 at 5:10 PM John R Levine wrote: > >> In systems that keep ASCII and EAI mail separate, that info will be in > >> the metadata, whether it arrived in an SMTP session with the SMTPUTF8 > >> option. > > > > Does anyone implement it that way? > > I have no idea. I don't in my code either. > > > Unfortunately, everybody thinks they can just make their own emali > messages > > because its a text-like format, and they're very often wrong. > > Surely you're aware that 50% of all programmers are of below average > skill. > Clearly. But it goes beyond that, even programmers who are of above average skill aren't expected to be knowledgeable about all of the sharp edges they can run into. Brandon --000000000000a3e9c705a26864a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 2, 2020 at 5:10 PM John R= Levine <johnl@taugh.com> wrot= e:
>> In s= ystems that keep ASCII and EAI mail separate, that info will be in
>> the metadata, whether it arrived in an SMTP session with the SMTPU= TF8
>> option.
>
> Does anyone implement it that way?

I have no idea.=C2=A0 I don't in my code either.

> Unfortunately, everybody thinks they can just make their own emali mes= sages
> because its a text-like format, and they're very often wrong.

Surely you're aware that 50% of all programmers are of below average skill.

Clearly.=C2=A0 But it goes beyon= d that, even programmers who are of above average skill
aren'= t expected to be knowledgeable about all of the sharp edges they can run in= to.

Brandon=C2=A0
--000000000000a3e9c705a26864a7-- From nobody Fri Apr 3 13:05: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 C41623A0935 for ; Fri, 3 Apr 2020 13:05:29 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=k3OZQuLu; dkim=pass (1536-bit key) header.d=taugh.com header.b=kdQBqHEs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaYsVOt75iNT for ; Fri, 3 Apr 2020 13:05:28 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499323A092E for ; Fri, 3 Apr 2020 13:05:28 -0700 (PDT) Received: (qmail 74265 invoked from network); 3 Apr 2020 20:05:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12217.5e879707.k2004; bh=EH4rDwl7+tI6OLIKuajkELLu1nMujxj/ZsAJqkOj0AA=; b=k3OZQuLuXKVMGLg9Zymtmo/BHD+ddC5TjCouJp+t6qbGff2oOjV/RuHDKwWoHi2LdC5ZYfWZdNOzo1XmCIWeS3w0yCB8hGTej7XhkRUdl9I6QrbMkJbvIDjRBkBisBzjm5939ewgpmmKa9OLVCd2mDZ+xBmIBkCmW43d3xTquO06pL+Vs1AqPs/R6BwiteksIzphnFcD2KDdflnceUJk5vGn0aL6xSNXaV+W/aYweBr9nkMxnfNkSmh4fHjcCKYZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12217.5e879707.k2004; bh=EH4rDwl7+tI6OLIKuajkELLu1nMujxj/ZsAJqkOj0AA=; b=kdQBqHEsXpLGzaZQ5ZytY/5e6NGWbnXnQTp0bi0ouxU1YOt9NhcIX+O9YQ9iGueNcjMwivHE5mgTldOA5sHDEIgu4qNJpYymyzX22xBLuy3iunpmoqVVyuaEf6LTWn97dlgS9DlI561fd6vuE+nZurISpjhZ2rQgX7apgZiWl2GCgKeuLDJVQ/HK6llEDOSk+ywDZD3DHTpFEp7JsTH45aZiCmmWMUi23zw+hy+GluOLFDntbH1Ml3z32XpQgaaa Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2020 20:05:26 -0000 Received: by ary.qy (Postfix, from userid 501) id DDAD616FC9A3; Fri, 3 Apr 2020 16:05:26 -0400 (EDT) Date: 3 Apr 2020 16:05:26 -0400 Message-Id: <20200403200526.DDAD616FC9A3@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: rfc@arcsin.de In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:05:30 -0000 In article you write: >> this specification MUST delete any discovered instance of this header >> field that claims, by virtue of its authentication service >> identifier, to have been added within its trust boundary but that did >> not come directly from another trusted MTA. > >In my opinion, a header that does not conform to the specified >authres-header-field in the RFC, is not an Authentication-Results >header, has no authentication service identifier, and as such cannot >claim anything in the context of the RFC. ... Honestly, it doesn't matter. The only A-R headers you can trust are the ones that your own system added, and the point of that text is that you should delete ones that look like yours but that you didn't add. We leave other people's A-R headers in case they might be useful to do forensics, and we have a slightly different version of them in ARC chains which again are only trustworthy if you know who added the ARC seals. R's, John From nobody Fri Apr 3 13:09: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 9A8FD3A094C for ; Fri, 3 Apr 2020 13:09:41 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=s/Au50Z8; dkim=pass (1536-bit key) header.d=taugh.com header.b=Gx7W2WrL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVUZ19dDYm8A for ; Fri, 3 Apr 2020 13:09:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC6A3A0934 for ; Fri, 3 Apr 2020 13:09:38 -0700 (PDT) Received: (qmail 74829 invoked from network); 3 Apr 2020 20:09: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; s=1244a.5e879802.k2004; bh=EkzAJ6UlNf1pTcEKC77AwiM8YAKbAcISp4+nkl1WDO4=; b=s/Au50Z8KOpdHEQQX+RiLzxapPwXX+z4C2go+q7+FnUTDq1Z9Nw3nexG9pOaYmmr3zipTFTlpBBjmhw7v8re8bvC1AZB6dJuPd43xSwjdl3GjAUiWkwq5Ngaq7kCSBckunnFP8xnvEYHiNm158JfmpDV1TVeZ0ABQ+xGpIJLXtbeC/ui5l7uIVAfyBIAV4OkpEYMNIvURVnsO6y7+YtWxzBrt/pj06x0AOJuO929E7sCJmUNCEBnLBsuclrDtFXo DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1244a.5e879802.k2004; bh=EkzAJ6UlNf1pTcEKC77AwiM8YAKbAcISp4+nkl1WDO4=; b=Gx7W2WrL/VKXplr48w/UKoV+MYIKERnOaUiwn5wi+BFxWB5EDKMvyu5ummts1XQqTr2/9Xjw/mPib+dRnScUEjtIAwkj5k/tWj40hmZ1JTqn83xGWNlKg+d0j/v9Mc9fuyOqsQ0284CFjgCp+H5HnWkF43O5/50Rte31tEZTjPzUuJVjaI/d//RS4+eKD8kVOT8hkE9R1Zuj38087oFnodB7h47TjTL0L03ek+ZtTmA8qDXgYpNNLMQRgtJ9kpwu Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 03 Apr 2020 20:09:37 -0000 Received: by ary.qy (Postfix, from userid 501) id AAFD716FCA1B; Fri, 3 Apr 2020 16:09:37 -0400 (EDT) Date: 3 Apr 2020 16:09:37 -0400 Message-Id: <20200403200937.AAFD716FCA1B@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: blong@google.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:09:42 -0000 In article you write: >In practice, I don't know how common it is for clients to consume this >header. They have to if they're adding ARC seals on the way out. Other than that I don't have much idea either. On my system my mailing list software looks at it them to decide how much DMARC hackery to do but again I don't know how common that is. Since the point of the text is that you can only trust your own A-R headers, presumably the code that adds them and that consumes them are at least partly under the same management so I'd think they could agree on their quoting practices. R's, John From nobody Fri Apr 3 13:19: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 ADFA43A09FB for ; Fri, 3 Apr 2020 13:19:06 -0700 (PDT) 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 3syVgXaIjEGF for ; Fri, 3 Apr 2020 13:19:05 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3208C3A09FA for ; Fri, 3 Apr 2020 13:19:04 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id k29so8613226ilg.0 for ; Fri, 03 Apr 2020 13:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cfp0wajwaft+9Hab905hOPsfEYyiVf21KNzwa7sRZ6U=; b=VNWkq6hEOm2k8jv7xyp+s6q8tDrciRtGdhixfQ4SI/y+lORIUzRJrTzQldDL0iZE0Q aL5KfGvanV/Hp1Ra3S0jikY3+cwQSwsk6gjob+prbxKEDiCw5kXn1cjanstF3S526qQT HtENwSWT543uXj5ZSJ4JGxf5xaRowABNeOH+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=Cfp0wajwaft+9Hab905hOPsfEYyiVf21KNzwa7sRZ6U=; b=EfZ9iKXJxWmlWaHkipKJvLW+89V5BYY/mTWMQwK6hne3aRONG5LYycAdHU4g4JO8mq KLYpYRNwrpye1FEBqHiq4tt4W06qQY29GqNG9XdplqQS/gxhj97KDJmJ1wHVOfIlxTtO P3WUjW88aM9HozitWW7tVdYsKxGLtljRqZETO4eRDKgqfQMvZ/Ae8+/vEfUC/+CZsO8d CeAVYgYZsWJbM9mVGHzjHxBQCu1ikCu1qwgyntIzMMZLMX+Aq4ZvMVzbe6rfs7V4iAex Bc5IWaFQq9WsFk0avgHOpFFLDaJ23dhOxyV5yt4xFthw2eaqreWanqh8zpiFvzobjD0H VtUw== X-Gm-Message-State: AGi0Pub34DSi/tHyQajLvzheDcmxPNklVfa8HhjO7W+nQXFSx6/ZlSqg WiO/nEdnuAf1KQtCQg9hs7Ma+vFgskFaFQ05WgYOKQ== X-Google-Smtp-Source: APiQypKfO5bVCZVFZLjYhIktDJJBDmmuttj6yWcPuLKYCxmSY/bRkNLU585qEnQDRKrBoUkSMvc95v/vI9mdkvn68q4= X-Received: by 2002:a92:db04:: with SMTP id b4mr10344230iln.120.1585945144101; Fri, 03 Apr 2020 13:19:04 -0700 (PDT) MIME-Version: 1.0 References: <20200403200937.AAFD716FCA1B@ary.qy> In-Reply-To: <20200403200937.AAFD716FCA1B@ary.qy> From: "Kurt Andersen (b)" Date: Fri, 3 Apr 2020 13:18:52 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Brandon Long Content-Type: multipart/alternative; boundary="000000000000f2a16e05a268a081" Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:19:07 -0000 --000000000000f2a16e05a268a081 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 3, 2020 at 1:09 PM John Levine wrote: > In article < > CABa8R6sbHLfkzHD4gaPBxQbgNy57J1eLXt2sPyAfaTYAY3tG-Q@mail.gmail.com> you > write: > >In practice, I don't know how common it is for clients to consume this > >header. > > They have to if they're adding ARC seals on the way out. > Only if the ADMD's particular implementation to pass through the information from incoming perimeter system to outgoing perimeter system happens to utilize the A-R header(s) for the purpose of conveying that information. --Kurt --000000000000f2a16e05a268a081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 3, 2020 at 1:09 PM John Levin= e <johnl@taugh.com> wrote:
=
In article <CABa8R6sbHLfkzHD4gaPBxQ= bgNy57J1eLXt2sPyAfaTYAY3tG-Q@mail.gmail.com> you write:
>In practice, I don't know how common it is for clients to consume t= his
>header.

They have to if they're adding ARC seals on the way out.=C2=A0

Only if the ADMD's particular implementati= on to pass through the information from incoming perimeter system to outgoi= ng perimeter system happens to utilize the A-R header(s) for the purpose of= conveying that information.

--Kurt
--000000000000f2a16e05a268a081-- From nobody Fri Apr 3 13:30: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 107DB3A0A45 for ; Fri, 3 Apr 2020 13:30:13 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=h9pIxL2u; dkim=pass (1536-bit key) header.d=taugh.com header.b=TQsBXmL2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFsEZ2UfxPpm for ; Fri, 3 Apr 2020 13:30:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553B13A0A42 for ; Fri, 3 Apr 2020 13:30:11 -0700 (PDT) Received: (qmail 79685 invoked from network); 3 Apr 2020 20:30:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1373f.5e879cd2.k2004; i=johnl-iecc.com@submit.iecc.com; bh=bVI4QqtqZeE9rGwhZWkA8ehb4cUpau3n39dqNEo5RyE=; b=h9pIxL2uP1TiZM7DA2BVPAoYWMWSCqZBHQFEVcf7Y0H6TbDWpScgRYPZPMjW4DWvXE3Py/ErYhMtC+f/jX1/djn5CbIgwfpKFfyG7BEhXfsimfuH1S3jr5s7zlCF3Kl2x3N8Mol2IIgU1zlktNbLTKIo1KzYzXOXBTO0vF1SjxJv9hfHEN5+iU8D8z9uQjNwRMkcnRgOeAAONJbSBvkzC5pAjH7+K3YwOCiKTX5+1p9IJwVCYp3xn4gijAm15xJP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1373f.5e879cd2.k2004; olt=johnl-iecc.com@submit.iecc.com; bh=bVI4QqtqZeE9rGwhZWkA8ehb4cUpau3n39dqNEo5RyE=; b=TQsBXmL25pOxMS//shFrzoaxcehXJOUKtelzHwKSZL+5Bk4M9irNf1WUuM35z1Y9el9jU9oADpWsKOgqOVoH37IaHcQirItJ4YVBaeHBRQLbiDHhSokTI5ND20/XRhG6RvESB9dLenF7Tzle12laRnq3znhVDJhz/T+EkjvD5DZcgGyzcflNC7DWEbQL17ujr9ohonMi9pjDtl6agaPsZl6nkOrg+28QrticeAsRvnKoLQTAArjXQUZ43lcfnXi0 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; 03 Apr 2020 20:30:09 -0000 Date: 3 Apr 2020 16:30:09 -0400 Message-ID: From: "John R Levine" To: "Kurt Andersen (b)" Cc: "dmarc@ietf.org" , "Brandon Long" In-Reply-To: References: <20200403200937.AAFD716FCA1B@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:30:13 -0000 >>> In practice, I don't know how common it is for clients to consume this >>> header. >> >> They have to if they're adding ARC seals on the way out. > > Only if the ADMD's particular implementation to pass through the > information from incoming perimeter system to outgoing perimeter system > happens to utilize the A-R header(s) for the purpose of conveying that > information. It would seem pretty perverse to create an AAR header with exactly the same info as the AR header by ignoring the AR header. But whatever. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Fri Apr 3 13:41: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 50C283A0A38 for ; Fri, 3 Apr 2020 13:41:45 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Apt4TeBrjZ8Y for ; Fri, 3 Apr 2020 13:41:43 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816CF3A0A79 for ; Fri, 3 Apr 2020 13:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585946500; x=1587760901; bh=sEAS8xQWRc41rC3i3dxwHVmgiK6dLgYwOpa d2h/Ui2Y=; b=w5iBndTTXJvtMhu6xeA55JQL0NrQS9/0qfhj387pF9J0ydjBP2f XLndPnupdB10GAndzeT+70TokjWQBVxwjK6mlHppjxwhRmUaZQ2w9moUSC59nTmW FJkSY1WP84XZgsRdxkBy5NYUYlirgp8h3HbX+0DF/x3VjdmDL7AUcfSc= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: From: Damian Lukowski Message-ID: <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de> Date: Fri, 3 Apr 2020 22:42:23 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:41:45 -0000 > The system should remove the quotes when comparing, and should also do > any decoding to get the admds into the same format. My question's intent was not particularly about the quotes and UTF-8, I just chose it, because the syntactically invalid version looks more legit than the syntactically valid one. Assume some plain-ASCII examples. A mail system with own authservid of domain.tld receives mail with: > Authentication-Results: domain.tld; spf=pass smtp.mailfrom=x@y.z Needs to be removed? Clearly yes. > Authentication-Results: otherdomain.tld; spf=pass smtp.mailfrom=x@y.z Needs to be removed? Clearly no. > Authentication-Results: {garbage} Needs to be removed? I say no. > Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z Needs to be removed? I say no. > Authentication-Results: domain.tld; {garbage} Needs to be removed? I say no. > Authentication-Results: "domain.tld"; {garbage} Needs to be removed? I say no. > Authentication-Results: "domain.tld"; spf=pass smtp.mailfrom=x@y.z Needs to be removed? Yes. From nobody Fri Apr 3 13:53: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 D07313A0AB3 for ; Fri, 3 Apr 2020 13:53:18 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScqHwASSAHtN for ; Fri, 3 Apr 2020 13:53:17 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F643A0AAD for ; Fri, 3 Apr 2020 13:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1585947194; x=1587761595; bh=Ri3mykdd2xiN0Ix+1U+S2fyva4eLyaX0D5+ P/AG8gpw=; b=gnbJgRy6Lzl6rZZAs+bFfPYuxHNH4ItTiQI0waynqYyVOnA4XBI fjPTU6YoBgoBdmHKDeNje8LBei6LdfLTRL7QJbEA3XlRRW40avgiOuV8l3IdOlVa dMwmyaMPvRWXUTnzAHLcx5jab7zd+b1Yn85wh5reFOONPWEl96KbuGsM= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <20200403200526.DDAD616FC9A3@ary.qy> From: Damian Lukowski Message-ID: Date: Fri, 3 Apr 2020 22:53:57 +0200 MIME-Version: 1.0 In-Reply-To: <20200403200526.DDAD616FC9A3@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 03 Apr 2020 20:53:19 -0000 > Honestly, it doesn't matter. The only A-R headers you can trust are > the ones that your own system added, and the point of that text is > that you should delete ones that look like yours but that you didn't > add. How can a MUST not matter? My personal interest in this area is what needs to be done according to the specification, which unfortunately uses a metaphoric verb for the condition of the MUST. From nobody Sun Apr 5 18:10:49 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 AABE83A0A8B; Sun, 5 Apr 2020 18:10:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley via Datatracker To: Cc: dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158613543159.15216.5517593808552135017@ietfa.amsl.com> Reply-To: Dale Worley Date: Sun, 05 Apr 2020 18:10:31 -0700 Archived-At: Subject: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08 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: Mon, 06 Apr 2020 01:10:32 -0000 Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: review-draft-ietf-dmarc-psd-08 Reviewer: Dale R. Worley Review Date: 2020-04-05 IETF LC End Date: 2020-04-08 IESG Telechat date: not known * Summary: This draft is on the right track but has open issues, described in the review. * Major issues: The privacy concerns described in section 4 are written as if there is no certainty that the mechanisms described in the document properly mitigate them. So the document appears to be incomplete. OTOH, since this is an Experimental RFC, such mitigation isn't necessary if there is commitment to do so later. In that case, the section should explicitly state that these are open issues and that there is an intention of revising the document to mitigate them. The text suggests that a mail receiver(?) that does DMARC processing has knowledge of all PSDs. This seems a priori unlikely and even impossible to implement. So this ought to be either explained at the appropriate place or resolved technically. * Minor issues: The document has the (common) editorial problem that it is written by people who are deeply familiar with the subject, and it's difficult to read if one doesn't share that familiarity. This is particularly significant because DMARC is an e-mail facility that (ideally) will affect all e-mail that is sent, so the target audience really should be anyone who has a basic understanding of e-mail. Three particular elements of this are: - It would be very helpful if the Introduction could state, in a few sentences, the purpose and operation of DMARC, thus informing the reader of the framework whose deficiencies this document attempts to address. In particular, one shouldn't have to read the DMARC RFCs to be able to read this document and understand its general import. - The "experiment" appendixes are unclear about what the experiments actually are: what questions they are to answer, what actions will be taken, how the results will be evaluated. Starting each appendix with an overview paragraph would be helpful. - Forward references should be minimized so that a reader can understand the document in one pass. As a derivative of the first of these elements, the terminology used for the properties of domain names is not clearly defined. In particular, where does a registration "occur"? The only term for which I think the general audience possesses an unambiguous definition is "the registered domain name", e.g. ietf.org. Now I *think* its PSD is ".org", but it might be "ietf.org", and I don't know whether the registration of ietf.org "occurs" at ietf.org or .org. Further points I didn't understand are pointed out in the review of the Abstract and Introduction. * Nits/editorial comments: Abstract I'm having quite a bit of difficulty figuring out exactly what the Abstract means. I'm sure that the working group clearly understands what is meant, but the writing is just loose enough that I can't fix the meaning. To raise the immediate questions: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. This sentence is quite good, as it introduces what DMARC is all about. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. You want to make clear here that "registration" means "domain name ownership registration" (which is what section 2.2 says). Otherwise it leaves open that there is some sort of DMARC registration that you might intend, until the reader gets to section 2.2. There's an ambiguity regarding "where" a registration happens. E.g., does the registration of "ietf.org" "occur at" "ietf.org" or "occur at" "org"? It's possible that this could be simplified/disambiguated by not using this term, but instead phrasing this in terms of domain names that "are registered", and the allowed relationships between them. And it appears certain that there are DNS nodes where registrations are only done *above* that node, e.g. "datatracker.ietf.org", which this sentence (if taken literally) says is not permitted by DMARC. Is the property you want to declare "one node where registrations are done cannot exist below another node where registrations are done"? Or perhaps domain names like "datatracker.ietf.org" are of no interest to DMARC because DMARC is never applied to messages for which that is the relevant address? Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for these domains as well. This sentence doesn't make it clear what "these domains" refers to. Domains at which registrations can occur are referred to as Public Suffix Domains (PSDs). This document describes an extension to DMARC to enable DMARC functionality for PSDs. It would probably be clearer to use "domain name ownership registrations" again here. This sentence suggests that the registration of "ietf.org" "occurs at" "org" and so "org" is a PSD. This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC enforcement. This suggests that implementations believe that they know of all PSDs, so they can "consider them ineligible for DMARC enforcement". But it's hard to imagine that that they can know that they know of all PSDs. An additional point, and I'm not sure how valuable this is, would be to clarify "I'm holding an e-mail message in my hands. What do I do next?", that is, What address in the message is the domain whose DMARC information is applied to the message? And what indeed does DMARC processing do to a message? For most of the sentences of the Abstract, this is not important, but it leaves the effect of the last sentence unclear, as "DMARC is not enforced on messages whose *sender* is in a PSD" is quite a bit different from "DMARC is not enforced on messages whose *recipient* is in a PSD". (Section 3.3 suggests that the address in the From header of the message is the one that is used for DMARC processing.) It's unclear what exactly is the contents of a "public suffix list". Naively, it appears that it is the list of domain names under which names can be registered, but the text uses the term in the plural, so there must be some additional structure. Also, it seems there are some significant privacy matters addressed by this document, and it's probably worth adding a sentence to notify the reader of that. 1. Introduction A number of the questions about the Abstract apply to the Introduction as well. But generally, since e-mail is a subject that every reader has a basic knowledge of, it would be useful to write the introduction so that one did not have to have a knowledge of the DMARC architecture to understand the introduction. "gov.example" publishes the following DMARC record: "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example" at _dmarc.gov.example. Even better would be this aid to people who don't already know DMARC implementation: "gov.example" publishes the following DMARC DNS record: _dmarc.gov.example. TXT \ "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example" -- the non-existent organizational domain of @tax.gov.example I suspect you mean "t4x.gov.example" here. This document provides a simple extension to DMARC [RFC7489] to allow [...] This sentence lists 4 important items, each of which is fairly long, which together are the summary of the whole document, so it might be useful to break this into a bullet-list. 2. Terminology and Definitions In many cases the public portion of the DNS tree is [...] What does "the public portion" mean? I'm guessing it means "the names not available for private registration", but you should be unambiguous here. They are not available for private registration. In many cases the public portion of the DNS tree is more than one level deep. It seems like these two sentences are redundant and the flow of the paragraph would be better if they were removed. ... Actually once they are removed, it reveals that the next two sentences largely duplicate the first two sentences of the paragraph. 2.3. Longest PSD The longest PSD is the Organizational Domain with one label removed. 2.4. Organizational Domain The term Organizational Domains is defined in DMARC [RFC7489] Section 3.2. 2.4 should be moved ahead of 2.3 to avoid a forward-reference. But it would be really helpful if the definition of Organizational Domain was either summarized here or completely copied from RFC7489. In particular, if Organizational Domain is not the same as registered domain name, that should be flagged. 2.5. Public Suffix Operator (PSO) A Public Suffix Operator manages operations within its PSD. Better to explicitly define the possession relationship explicitly: A Public Suffix Operator is an organization which manages operations within a PSD, particularly the DNS records published for names at and under that domain name. -- 2.6. PSO Controlled Domain Names PSO Controlled Domain Names are names in the DNS that are managed by a PSO and are not available for use as Organizational Domains. Depending on PSD policy, these will have one (e.g., ".com") or more (e.g., ".co.uk") name components. The second sentence is odd; is it useful? Is it just to say "PSO Controlled Domain Names may have one or more components."? 3.1. General Updates References to "Domain Owners" also apply to PSOs. This change really ought to be localized to a specific textual change somewhere in RFC 7489, in the say way that the other changes are specific amendments to the DMARC algorithm. 3.2. Section 6.3 General Record Format These section titles are difficult to read. At first I thought there was some typographical problem. But you could clarify this as "3.2. Updates to Section 6.3. General Record Format". Similarly for the other subsections of section 3. 3.3. Section 6.5. Domain Owner Actions The mechanism for doing so is one of the experimental elements of this document. I think that what this means is that the whole document is an experimental "mechanism for doing so". If so, I think it could be better phrased This document is an experimental mechanism for doing so. -- 3.4. Section 6.6.1. Extract Author Domain [...] when the domain name extracted by the receiver (from the RFC5322.From) is on the public suffix list used by the receiver. This touches the question above about what a public suffix list is, and how there can be more than one of them. But without that knowledge, it's hard to see which PSL is "used" by the receiver of the message. Also, it's not clear to me how *this* document creates a capability which applies to domains that are on the PSL. E.g., if an "np" is defined for ".org", it applies to (that is, affects processing of e-mail from) any "X.org" that doesn't have its own DMARC records. But I don't see how an "np" tag for ".org" affects processing of messages from "example@org". 3.5. Section 6.6.3. Policy Discovery (discussed in the experiment description (Appendix A)) Given that this text is nominally an update to the text of RFC 7489, you want to disambiguate the binding of "Appendix A": (discussed in the experiment description ([this document] Appendix A)) 3.6. Section 7. DMARC Feedback See Section 4 of this document for discussion of Privacy Considerations. Similarly to section 3.5, but also clarifying the scope of "privacy considerations": See Section 4 of [this document] for discussion of Privacy Considerations for PSD DMARC. 4. Privacy Considerations The Privacy Considerations of [RFC7489] apply to this document. This could be clarified as Additionally, the Privacy Considerations of [RFC7489] apply to the mechanisms described by this document. -- Providing feedback reporting to PSOs can, in some cases, create leakage of information outside of an organization to the PSO. "outside" probably isn't the word you want to use here, as it is easier to read "outside" as giving the original location of "information" than to read "outside" as giving the direction of "leakage". Perhaps Providing feedback reporting to PSOs can, in some cases, create leakage of information out of an organization to the PSO of its domain name. -- To minimize this potential concern, PSD DMARC feedback is best limited to Aggregate Reports. [...] [...] any Feedback Reporting related to multi- organizational PSDs ought to be limited to non-existent domains except in cases where the reporter knows that PSO requires use of DMARC. I can't see where in the document that these principles are turned into MUST statements that ensure the privacy issues are solved. The experiment is to evaluate different possible approaches. Calling this an "experiment" suggests that these is an intended series of actions whose result will answer the listed questions. But there doesn't seem to be any such actions listed. The description makes it sound like what is intended is continuing discussions in the working group, but that wouldn't be an "experiment". A.2. Non-Existent Subdomain Policy Similar questions arise for this section. The second paragraph suggests that the experiment is to see whether the "np" tag is successful. There are also suggestions that it would be more generally useful for DMARC. What does "it" refer to? (Does it mean "this ability"?) Appendix B. DMARC PSD Registry Examples In this appendix, it appears that the contents of the experiment are clear in the authors' minds, but there is no summary at the top that states what the experimental facilities are and the "big picture" into which they fit. Appendix C. Implementations C.1. Authheaders Module What e-mail MTA is Authheaders an extension for? [END] From nobody Mon Apr 6 08:55: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 402803A0B49 for ; Mon, 6 Apr 2020 08:55:20 -0700 (PDT) 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 DUbZtyIIaHf8 for ; Mon, 6 Apr 2020 08:55:17 -0700 (PDT) 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 341F73A0B22 for ; Mon, 6 Apr 2020 08:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1586188506; bh=wgUEq4Hb3+3EPtSmABe+PzotnI5GCoXPSuC9Ws+JDN4=; l=2473; h=To:References:From:Date:In-Reply-To; b=DDHpSmtNlEup8VlrcSzlPDCufZTHbJvnp9sgov2lOklPjZRV7KnZOr7qdsjsAftth duk16J1ROTcHI+WQ6aAls034xZ7XIwpVWIqLH0M0WPwuTGkJFluQmwzWqLTITcpnGF mKMIod4NsD0HgJzdhwkjN3eILQmaYukm00She+YXIDe3hf1xoRwmZwqkOuKyX Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005E8B50DA.00000BA8; Mon, 06 Apr 2020 17:55:06 +0200 To: dmarc@ietf.org References: <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de> From: Alessandro Vesely Message-ID: <7084d678-ce11-fa3f-8b59-67e46da841f7@tana.it> Date: Mon, 6 Apr 2020 17:55:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 06 Apr 2020 15:55:20 -0000 On Fri 03/Apr/2020 22:42:23 +0200 Damian Lukowski wrote: >> The system should remove the quotes when comparing, and should also do >> any decoding to get the admds into the same format. > > My question's intent was not particularly about the quotes and UTF-8, I > just chose it, because the syntactically invalid version looks more > legit than the syntactically valid one. Assume some plain-ASCII > examples. A mail system with own authservid of domain.tld receives mail > with: My system, my rules: >> Authentication-Results: domain.tld; spf=pass smtp.mailfrom=x@y.z > > Needs to be removed? Clearly yes. Yes, and log it. >> Authentication-Results: otherdomain.tld; spf=pass smtp.mailfrom=x@y.z > > Needs to be removed? Clearly no. Rename the header field to Old-Authentication-Results anyway. >> Authentication-Results: {garbage} > > Needs to be removed? I say no. Rename the header field to Old-Authentication-Results anyway. >> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z > > Needs to be removed? I say no. Yes, and log it. >> Authentication-Results: domain.tld; {garbage} > > Needs to be removed? I say no. Yes, and log it. >> Authentication-Results: "domain.tld"; {garbage} > > Needs to be removed? I say no. > >> Authentication-Results: "domain.tld"; spf=pass smtp.mailfrom=x@y.z > > Needs to be removed? Yes. Both cases are renamed to Old-Authentication-Results anyway. The part that would log it, however, doesn't recognize the quotes (I'm going to fix it now) and intermittently removes the header. Note that some tools, e.g. Thunderbird DKIM-Verifier[*] can be configured to either "Read Authentication-Results header" or not. Hence is makes sense to rename all on entry. Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA simultaneously accessing two mailboxes, at example.com and example.org, say. Of course you would configure the tool to trust both of their authserv-id (which is already beyond what an average user is willing to configure). Then, a malicious party can send you a message at your @example.com address, bearing a faked Authentication-Results by example.org. Should the tool trust it? jm2c Ale -- [*] https://www.reddit.com/r/Thunderbird/comments/5nheej/is_it_possible_to_make_thunderbird_display_the/ (The "Edit 2" is bogus, but the previous edit describes the point well.) From nobody Mon Apr 6 10:22: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 96E9F3A0B14 for ; Mon, 6 Apr 2020 10:22:11 -0700 (PDT) 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 LyrEf4PmfmJp for ; Mon, 6 Apr 2020 10:22:09 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 88EBB3A0B0C for ; Mon, 6 Apr 2020 10:22:09 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id l23so153147otf.3 for ; Mon, 06 Apr 2020 10:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RRMxtb1si+gqF4f0BolhUhB6X4hTWgNY9OyKiQ3O7j4=; b=ubPqa9Sulz+rwb8AN43I4QC2oe4LGwxrzWyURwzGGV8rkZXNCcv12pl0bwPRVPpNkU 46EyfOZlY+Sv3jGhw7NldDdDaL8cDqCBGw3aDyIH7cJzEI5s1vZZYggwwoZk5AmemN34 Nl4ufaqXTZdnrJiJBZagikHUqbbHawEylQUzP41OshPghls0Ypgt8CbWDRGz39ECdY9J tbM8JTCYbk490BfMn9+wz7VHiH5Zr5NieGKthjShtRQZ+f8R7KqG77DYuseWNletoyLd aopvo0r0t6dpRED5xS3o8eExpINJQmUXI//XkUMZQzsv+YXrS64N3gJ7E0NNR7Q3ed7G DJig== 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=RRMxtb1si+gqF4f0BolhUhB6X4hTWgNY9OyKiQ3O7j4=; b=XoSPoFH+IoFRsjpY1ZwJ3HIuxXGqmf1Q+pPjrXnyCaaL2EQv2tt/xI/PaC8XYoSCpx XYjDwUHC7box5Ti5T/uDO5NbLPQQrvNJHBdR++nxa5UIl2SymteCLhOYOc+Nq8Ss3d30 WItcm5eEZ3GOKoDr9T55utmaE3kscHGEahmGZW31oGJYpoaAKPZftpfOgCV+/SWruCx/ m5sA/rh/bW4Bi5uGB/H/5ri1s1aP9Wi3drUg538XWFnESP2XYlSNP3CPtCiFQPW3q6uG 9NzuOLJ+BbxXlh9zKwHLz0hJuxAL5NvfcHw38M7JPVUvmV46veMZHOE6W6LaJoE5we4V BHsA== X-Gm-Message-State: AGi0PubAdtL7q+xHcoc+l/ZS0m7lrNK7HF0i3s/3J53S1beZCgzSY8Zd 7+Q7QdP88h/joWDgiZ5PeC9CWKIhDxkymDhA0tD1trvD X-Google-Smtp-Source: APiQypJ5KySzOMmU9KQ/c5+BV8TF8wXwxeHOHVEqBQz5mGXmsQQmt8ZeqzdBT5rvfhHTJ1LMOJFzaWnL8XdqN31eq8o= X-Received: by 2002:a9d:1988:: with SMTP id k8mr129540otk.4.1586193728532; Mon, 06 Apr 2020 10:22:08 -0700 (PDT) MIME-Version: 1.0 References: <158619357716.2395.9626087376923274203@ietfa.amsl.com> In-Reply-To: <158619357716.2395.9626087376923274203@ietfa.amsl.com> From: Tim Wicinski Date: Mon, 6 Apr 2020 13:21:56 -0400 Message-ID: To: IETF DMARC WG Cc: "Murray S. Kucherawy" , Elizabeth Zwicky Content-Type: multipart/alternative; boundary="000000000000bbf4dc05a2a2810e" Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-dmarcbis-01.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, 06 Apr 2020 17:22:12 -0000 --000000000000bbf4dc05a2a2810e Content-Type: text/plain; charset="UTF-8" Updates to draft-kucherawy-dmarc-dmarcbis updated IANA Considerations to reflect new DNS Underscore Registry https://trac.ietf.org/trac/dmarc/ticket/36 Moved xml schema to own versioned document Fixed internal cross reference issue Edits to escape _ properly Fixed references to RFC6651 Updated Obsolete References https://trac.ietf.org/trac/dmarc/ticket/35 I also pulled the ABNF out into its own file, and I've been looking at a few of the tickets around updating the ABNF, and how we could validate it. This led to a long discussion with Mr. Levine about a better way to track external references to ABNF objects. There are several tickets related to ABNF and several related to the XML, and that's before we go through the document itself. the XML schema has several issues in the issue tracker, and it seemed to make sense to pull it out so it can also be referenced by others. Very useful discussions with Mr. Vesely and Mr. Levine on versioning the XML schema and some of the open issues https://github.com/moonshiner/draft-kucherawy-dmarc-dmarcbis On Mon, Apr 6, 2020 at 1:19 PM wrote: > > A new version of I-D, draft-kucherawy-dmarc-dmarcbis-01.txt > has been successfully submitted by Tim Wicinski and posted to the > IETF repository. > > Name: draft-kucherawy-dmarc-dmarcbis > Revision: 01 > Title: Domain-based Message Authentication, Reporting, and > Conformance (DMARC) > Document date: 2020-04-06 > Group: Individual Submission > Pages: 73 > URL: > https://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-dmarcbis-01.txt > Status: > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ > Htmlized: > https://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kucherawy-dmarc-dmarcbis > Diff: > https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dmarc-dmarcbis-01 > > Abstract: > Domain-based Message Authentication, Reporting, and Conformance > (DMARC) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. > > Originators of Internet Mail need to be able to associate reliable > and authenticated domain identifiers with messages, communicate > policies about messages that use those identifiers, and report about > mail using those identifiers. These abilities have several benefits: > Receivers can provide feedback to Domain Owners about the use of > their domains; this feedback can provide valuable insight about the > management of internal operations and the presence of external domain > name abuse. > > DMARC does not produce or encourage elevated delivery privilege of > authenticated email. DMARC is a mechanism for policy distribution > that enables increasingly strict handling of messages that fail > authentication checks, ranging from no action, through altered > delivery, up to message rejection. > > This document obsoletes RFC 7489. > > > > > 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 > > > --000000000000bbf4dc05a2a2810e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



Updates=C2= =A0to=C2=A0draft-kucherawy-dmarc-dmarcbis


=C2=A0 =C2=A0 updated IANA Considerations to reflect= new DNS Underscore Registry https://trac.ietf.org/trac/dmarc/ticket/36

=C2=A0 =C2=A0 Moved xml schema to own versioned docu= ment

=C2=A0 =C2=A0 Fixed internal cross reference issue

=C2=A0 =C2=A0 Edits to escape _ properly

=C2=A0 =C2=A0 Fixed references to RFC6651

=C2=A0 =C2=A0 Updated Obsolete References https://trac.ietf.org/trac/dma= rc/ticket/35


I also pulled the ABNF out i= nto its own file, and I've been looking at a few of the tickets

around updating the ABNF, an= d how we could validate it. =C2= =A0 This led to a long discussion with

Mr. Levine about a better wa= y to track external references to ABNF objects.=C2=A0

There are several tickets re= lated to ABNF and several related to the XML, and that's before

we go through the document i= tself.=C2=A0


the XML schema has several i= ssues in the issue tracker, and it seemed to make sense to pull it out so i= t can also be referenced by others.=C2=A0 Very useful discussions with Mr.=C2=A0 Vesely and Mr. Levine on versioning the XM= L schema and some of the open issues



https://github.com/moonshiner/= draft-kucherawy-dmarc-dmarcbis


On Mon, Apr 6, 2020 at 1:19 PM = <internet-drafts@ietf.org> wrote:
A new version of I-D, draft-kucherawy-dmarc-dmarcbis-01.txt
has been successfully submitted by Tim Wicinski and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kucherawy-dmarc-dmarcbi= s
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Domain-based Message Authenticatio= n, Reporting, and Conformance (DMARC)
Document date:=C2=A0 2020-04-06
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 73
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-kucherawy-dm= arc-dmarcbis-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-dmarcbis/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-kucherawy-dmarc-dmarcbis
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-kucherawy-dmarc-dm= arcbis-01

Abstract:
=C2=A0 =C2=A0Domain-based Message Authentication, Reporting, and Conformanc= e
=C2=A0 =C2=A0(DMARC) 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, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.

=C2=A0 =C2=A0Originators of Internet Mail need to be able to associate reli= able
=C2=A0 =C2=A0and authenticated domain identifiers with messages, communicat= e
=C2=A0 =C2=A0policies about messages that use those identifiers, and report= about
=C2=A0 =C2=A0mail using those identifiers.=C2=A0 These abilities have sever= al benefits:
=C2=A0 =C2=A0Receivers can provide feedback to Domain Owners about the use = of
=C2=A0 =C2=A0their domains; this feedback can provide valuable insight abou= t the
=C2=A0 =C2=A0management of internal operations and the presence of external= domain
=C2=A0 =C2=A0name abuse.

=C2=A0 =C2=A0DMARC does not produce or encourage elevated delivery privileg= e of
=C2=A0 =C2=A0authenticated email.=C2=A0 DMARC is a mechanism for policy dis= tribution
=C2=A0 =C2=A0that enables increasingly strict handling of messages that fai= l
=C2=A0 =C2=A0authentication checks, ranging from no action, through altered=
=C2=A0 =C2=A0delivery, up to message rejection.

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




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.

The IETF Secretariat


--000000000000bbf4dc05a2a2810e-- From nobody Tue Apr 7 00: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 680AB3A17E6 for ; Tue, 7 Apr 2020 00:09:11 -0700 (PDT) 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=arcsin.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6_bT0mj7wXX for ; Tue, 7 Apr 2020 00:09:09 -0700 (PDT) Received: from scalar.arcsin.de (scalar.arcsin.de [185.162.250.16]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3989E3A17E2 for ; Tue, 7 Apr 2020 00:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-language:content-type :content-type:in-reply-to:mime-version:date:date:message-id:from :from:references:subject:subject:x-amavis-category; s=dkim01; t= 1586243342; x=1588057743; bh=9KA/8YL7Mgeb9Uq9rVVhn/LgOITRxddO4fP R6Ou/jhI=; b=I1FzhsYTvB7kUQqdTfBQMG+ikvAd09pOcj8K2dm6PikNhqqCybp Ig+Xru9XCNdo/uNBMDsLseLNb/sCeKpURlPcZOD5lWgSJkGXISCRZaF15mqXnLVU 6Otm5irqDehFVKJrmiydOsFpaR/3YMtfTfpS5PeXMJQk9JidTM3R1g+A= X-Amavis-Category: scalar.arcsin.de; category=CleanTag To: dmarc@ietf.org References: <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de> <7084d678-ce11-fa3f-8b59-67e46da841f7@tana.it> From: Damian Lukowski Message-ID: <13fd0dec-d02b-b5ca-cee8-a405d891dced@arcsin.de> Date: Tue, 7 Apr 2020 09:09:01 +0200 MIME-Version: 1.0 In-Reply-To: <7084d678-ce11-fa3f-8b59-67e46da841f7@tana.it> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Apr 2020 07:09:11 -0000 >>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z >> >> Needs to be removed? I say no. > > > Yes, and log it. Please notice the comma instead of the semicolon, it wasn't a typo. Would you still remove it? >>> Authentication-Results: domain.tld; {garbage} >> >> Needs to be removed? I say no. > > Yes, and log it. Interesting, you suggest to parse "lazily", i.e. as soon as a token looks like an authserv-id, treat it as such. > Both cases are renamed to Old-Authentication-Results anyway. The part that > would log it, however, doesn't recognize the quotes (I'm going to fix it now) > and intermittently removes the header. I wanted to object that the RFC does not allow to tamper with "innocent" headers, but it actually does not forbid it. That said, I could even remove previous A-R headers altogether and be RFC compliant, so a lazy evaluation parser can be compliant as well. Thanks. > Note that some tools, e.g. Thunderbird DKIM-Verifier[*] can be configured to > either "Read Authentication-Results header" or not. Hence is makes sense to > rename all on entry. > > Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA > simultaneously accessing two mailboxes, at example.com and example.org, say. > Of course you would configure the tool to trust both of their authserv-id > (which is already beyond what an average user is willing to configure). Then, > a malicious party can send you a message at your @example.com address, bearing > a faked Authentication-Results by example.org. Should the tool trust it? Wouldn't a trust-list per mailbox solve the issue, instead of a global trust-list? From nobody Tue Apr 7 01:48: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 CAAA83A192B for ; Tue, 7 Apr 2020 01:47:58 -0700 (PDT) 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 YUHCHeQ_rC8r for ; Tue, 7 Apr 2020 01:47:56 -0700 (PDT) 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 99AC93A18C1 for ; Tue, 7 Apr 2020 01:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1586249274; bh=/zG9ksMY263dRgRI+6gOFqZatlnfthv05svqDB4WGPw=; l=2594; h=To:References:From:Date:In-Reply-To; b=BgRyV455OWWczhJZLL09p5a/j9a9YFKBCkR5AtvlviZqDfacw7Pk7q/NLPBvdoddA 0TvUoGKDXgMq+SinevKXb63KF/rYVce8wKyn86mC48nawqjdAUpDCCoHmI9dYgl6K9 hRmJlWm4oz23QXvKKjrtECxvXGmSkkC4NPzExtLyeeN25esNnFjPVzhTuRwdD Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC02A.000000005E8C3E3A.000037D2; Tue, 07 Apr 2020 10:47:54 +0200 To: dmarc@ietf.org References: <0fbab9d5-d00e-42ff-3059-8cb269ff1591@arcsin.de> <7084d678-ce11-fa3f-8b59-67e46da841f7@tana.it> <13fd0dec-d02b-b5ca-cee8-a405d891dced@arcsin.de> From: Alessandro Vesely Message-ID: <8a487e6d-fcc8-fdb6-eaba-074641c70d03@tana.it> Date: Tue, 7 Apr 2020 10:47:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <13fd0dec-d02b-b5ca-cee8-a405d891dced@arcsin.de> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 07 Apr 2020 08:47:59 -0000 On Tue 07/Apr/2020 09:09:01 +0200 Damian Lukowski wrote: >>>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z >>> >>> Needs to be removed? I say no. >> >> >> Yes, and log it. > > Please notice the comma instead of the semicolon, it wasn't a typo. > Would you still remove it? If I can lazily (or sloppily) identify it as an authserv-id, so can do other tools too. >> Both cases are renamed to Old-Authentication-Results anyway. The part that >> would log it, however, doesn't recognize the quotes (I'm going to fix it now) >> and intermittently removes the header. > > I wanted to object that the RFC does not allow to tamper with "innocent" > headers, but it actually does not forbid it. That said, I could even > remove previous A-R headers altogether and be RFC compliant, so a lazy > evaluation parser can be compliant as well. IMHO that's the simplest approach. By renaming (otherwise obscuring) instead of deleting you still leave room for debugging and forensics. >> Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA >> simultaneously accessing two mailboxes, at example.com and example.org, say. >> Of course you would configure the tool to trust both of their authserv-id >> (which is already beyond what an average user is willing to configure). Then, >> a malicious party can send you a message at your @example.com address, bearing >> a faked Authentication-Results by example.org. Should the tool trust it? > > Wouldn't a trust-list per mailbox solve the issue, instead of a global > trust-list? Per-mailbox lists might seem to do it. However, consider, in the above scenario, making the decision to forward some or all of your @example.org traffic to your example.com mailbox, directly from example.org server. Now you'd want to trust example.org A-Rs even when they arrive through example.com. The only easy way that I see to accomplish that is to instruct example.com to whitelist example.org's A-R; if example.com admins trust example.org, that is: For simplicity and maximum security, a border MTA could remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. [...] A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing the header field originating from all others. https://tools.ietf.org/html/rfc8601#section-5 Best Ale -- From nobody Tue Apr 7 03:43: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 38A983A1AEC for ; Tue, 7 Apr 2020 03:43:56 -0700 (PDT) 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 syx7iWFQv0nU for ; Tue, 7 Apr 2020 03:43:54 -0700 (PDT) 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 958D83A1AEE for ; Tue, 7 Apr 2020 03:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1586256232; bh=qPcDQmo/BR61WyMwNRvczoGQJty1sG0QTZf8p8M48ck=; l=2284; h=To:References:From:Date:In-Reply-To; b=C0YRyT5iiaeEiZQG0OcE0/IYtedjctiWy9IJ8o98YbTYwcC7xgcylNKNjgUrBIM4l Y6mvRh26YJr7GDf+zN1yOL5PkeqOokUQTZDk7o5oLWS4Xw6fZAiXDIsQ6Die9ovEaG Nz/+Ydfn1UKjRJOmY/+xqk4MHI3UQhHRG87jN3wR8AM5XVI/3Pc0SG9tWTulr Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005E8C5968.000046E3; Tue, 07 Apr 2020 12:43:52 +0200 To: dmarc@ietf.org References: <158619357716.2395.9626087376923274203@ietfa.amsl.com> From: Alessandro Vesely Message-ID: <3b7a0c04-5d6e-7483-c5b3-ff0faa2cd632@tana.it> Date: Tue, 7 Apr 2020 12:43:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-dmarcbis-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 10:43:56 -0000 On Mon 06/Apr/2020 19:21:56 +0200 Tim Wicinski wrote: > Updates to draft-kucherawy-dmarc-dmarcbis > [...] > On Mon, Apr 6, 2020 at 1:19 PM wrote: > [...] >> Htmlized: https://tools.ietf.org/html/draft-kucherawy-dmarc-dmarcbis-01 I took a look at the new doc's diffs, and found a few nits: *RFC3986 instead of RFC7208* In some places this was wrongly replaced. I found: - In relaxed mode, the [RFC3986]-authenticated domain - [RFC3986], which can authenticate both the domain - when a message fails both [RFC3986] and [RFC6376] *RFC3986 instead of URI* The following snippet is quite unreadable: When a Mail Receiver discovers a DMARC policy in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" or "ruf" tag, the following verification steps are to be taken: Would "The component of a URI ([RFC3986]) specified in..." be better? *Semicolon in the version tag* DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM, which says: Note that WSP is allowed anywhere around tags. In particular, any WSP after the "=" and any WSP before the terminating ";" is not part of the value; however, WSP inside the value is significant. https://tools.ietf.org/html/rfc6376#section-3.2 This seems to imply that "v = DMARC1 ;" (with spaces) is valid. In addition, a tag is specified as: tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] That is, without a trailing semicolon. So it sound confusing to insist on the semicolon, as in «a tag of "v=DMARC1;"», «containing at least "v=DMARC1;"», and * The version of DMARC being used is "DMARC1" ("v=DMARC1;") *Repeated URIs* Sometimes URIs are redundantly repeated in parentheses. I found: common one is maintained by the Mozilla Foundation and made public at http://publicsuffix.org (http://publicsuffix.org). From: "user@example.org via Bug Tracker" support@example.com (mailto:support@example.com) and an informal industry consortium: DMARC.org (see http://dmarc.org (http://dmarc.org)). jm2c Ale -- From nobody Thu Apr 9 08:05: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 BB86D3A0943; Thu, 9 Apr 2020 08:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sandra Murphy via Datatracker To: Cc: dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158644469471.21209.9811712342867228933@ietfa.amsl.com> Reply-To: Sandra Murphy Date: Thu, 09 Apr 2020 08:04:54 -0700 Archived-At: Subject: [dmarc-ietf] Secdir last call review of draft-ietf-dmarc-psd-08 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, 09 Apr 2020 15:04:55 -0000 Reviewer: Sandra Murphy Review result: Has Nits This is a secdir review of draft-ietf-dmarc-psd-08 (DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document presents an extension to DMARC for Public Suffix Domains (PSD) (and their operators (PSO)), which are domains that are not organizational domains and are not subject to DMARC processing. In DMARC, these PSD domains can not publish policy or receive feedback for subdomains. The extension allows PSDs to express policy for organizational domain that are not themselves implementing policy. It also provides a new tag that covers non-existing subdomains. I find the document to be well written and well laid out (even in the face of a few comments below). Note: I am not conversant with DMARC and have only read the underlying normative references to the extent necessary to review this document. Consider the source in reading these comments. The security considerations section states that it does not change the security considerations of the base DMARC specification RFC7489. That is common in extensions to existing protocols. But the authors, to their credit, note that this extension increases some of the risks identified in the security considerations of rFC7489. I wish more authors of extensions to existing protocols did similar analysis. The security considerations section points in particular to Section 12.5 of RFC7489, which describes the risks of external reporting addresses. Section 4 of this document describes the privacy concerns of feedback reports leaking information outside an organizational domain. Section 12.5 of RFC7489 of RFC7489 points to a verification mechanism in Section 7.1 of RFC7489. Section 7.1 presents a detailed procedure to verify that a feedback reporting address is safe to report to, particularly for rua or ruf tags. Question to the authors: has the correctness of that procedure in the presence of this extension been considered? I can't tell. Some wordsmithing comments: Section 4.1 page 9 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage: Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs are significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. PSD DMARC is opt-out (by publishing a DMARC record at the Organizational Domain level) vice opt-in, which would be the more desirable characteristic. This means that any non-DMARC organizational domain would have its feedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive. The sentences "For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. and "This means that any non-DMARC organizational domain would have its feedback reports redirected to the PSO." seem to say the same thing. Are they redundant? Or is there a difference there that I am not seeing? Section A page 11 If the experiment shows that PSD DMARC solves a real problem and can be used at a large scale, the results could prove to be useful in removing constraints outside of the IETF that would permit broader deployment. I would read "removing constraints ... that would permit broader deployment" as meaning constraints that permit deployment are being removed. The "that" would in ordinary reading refer to "contraints". I think the intended meaning is "removing constraints ... where those constraints hamper broader deployment" or "removing constraints ... thereby permitting broader deployment" And I'm not sure whether "outside of the IETF" means that the removing occurs outside the IETF or that the constraints exist outside the IETF. I suspect both, but I don't know that it makes much difference. Section A.1 page 12 This section concerns the privacy concerns arising from the external reporting described in Section 4.1. In Section 4.1, the privacy risk exists for "non-DMARC organizational domains" under a multi-organizational PSD (presumably PSD DMARC participating, right?) that does not mandate DMARC usage for its registrants. Section A.1 states that knowing which PSDs do not present this risk would be beneficial and describes an experiment to produce that knowledge. Desirable attributes for such a mechanism includes the following: o List PSDs that either mandate DMARC for their registrants or for which all lower level domains are controlled by the PSO and that the relevant PSO has indicated a desire for the PSD to participate in PSD DMARC I get the "mandate DMARC" part - the risk exists in the case the PSD does not mandate DMARC - if the PSD mandates DMARC, it does not produce the privacy risk. I do not get the next part: or for which all lower level domains are controlled by the PSO and that the relevant PSO has indicated a desire for the PSD to participate in PSD DMARC" I do not see how the desire of the PSO that the PSD should participate in PSD DMARC would help alleviate the privacy risk for the PSD's registrant organizational domains. In the first place, what does the PSO's desire got to do with alleviating risk? In the second place, this mechanism is supposed to produce a list of PSDs that do not produce the risk. The risk in Section 4.1 assumes (or so I thought) that the PSD participates in PSD DMARC. So if the PSD is not participating in PSD DMARC, then it is therefore not producing risk, but it obeys the PSO desire, then the PSD becomes in the category of producing the risk, not alleviating risk. I suspect I am just confused here. --Sandy Murphy From nobody Thu Apr 9 12:54: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 7D69A3A0D12; Thu, 9 Apr 2020 12:54:20 -0700 (PDT) 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 WR7rJ5WuDdfK; Thu, 9 Apr 2020 12:54:16 -0700 (PDT) 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 6056D3A0D0C; Thu, 9 Apr 2020 12:54:16 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id o14so437982uat.13; Thu, 09 Apr 2020 12:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cdDwdDANnFtMMko1tWuxOAyblzuzcBUj4HcMEs+pQlw=; b=TymQRT8IiwSJ5M8neN1J+a8eyzlv/V3140wBWXniW1MJW+f7VLL7Z6BomXo6/0YiaF JuLE68UX6U0S/y6yPBjl40XFU/4rNFuzSskio5BOq4YTsNBZd7IWfWioM5hu+eB5/g4Y hjbcY8Ok+EyoeIiPabW+dP9nwXO+P/E2+hdtMpdRQxjYXLuhQ1OxJOhQ1z97yBaalALp uYi2GZ3XNPoV/L6vPnb74t1j4u0WRErpUzyBTFH1N7UuajTPzfYn6M9KlCI1Y7WNT3NU O3PNZCnSbxTZ/LJrJ73ovXH+eIkO36/cOftqmEmDoYXwJNqLOFzAaIJmEFpF8+CVZZZo h1Cw== 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=cdDwdDANnFtMMko1tWuxOAyblzuzcBUj4HcMEs+pQlw=; b=k7Wur1t9IyilGocU6BBnQX1m/M6ldJ1TKxVmhGiPDSwQP0MvLdRKuIwaJM3PBWfLqJ y43oUNNCCY4/XlTD9WvvR61q6MrffrJjFgAjDjVNS1s9rOnmwZ49K4NUnt/VJJeQWDL9 Pprm49racY2eT0bhBOeqC7d/hi2rbUg66mkPPq+/sdL/yakJ+jINVooFn8OrwBd4paLS ewVt6MC6VECG4ZPjRUbFYB7D3QXUk8ZOzaXrfwumlhE2d2utwZXiaDVCcTsGbmA6O+FX kcvf+YX3AbEgC3y/wCPmh7UvTDl4saOaIdsRCxzapf2WVYymIhemqp0V25gOKnz3911M pR/Q== X-Gm-Message-State: AGi0PuZ4SzN7Qby1RYhLjxmyOLPm+uT3UbJTawmir3x8SzOGDJWr0x2A Ip/5M2HJ2b7d8uQcZOSY1brg0XNVposi/NXRiJ9ncVAB+MI= X-Google-Smtp-Source: APiQypJdq8c9AbJzxN5687LrzTl8uahIr2ZyolWNsQPxmTHnqKlkyGt9ZkM0H19M6m40tAoaTg0eLfMmMskVTmw8SNA= X-Received: by 2002:a9f:2102:: with SMTP id 2mr700517uab.41.1586462055243; Thu, 09 Apr 2020 12:54:15 -0700 (PDT) MIME-Version: 1.0 References: <158613543159.15216.5517593808552135017@ietfa.amsl.com> In-Reply-To: <158613543159.15216.5517593808552135017@ietfa.amsl.com> From: Todd Herr Date: Thu, 9 Apr 2020 15:54:02 -0400 Message-ID: To: Dale Worley Cc: gen-art@ietf.org, last-call@ietf.org, dmarc , draft-ietf-dmarc-psd.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000040a80105a2e0fb29" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 09 Apr 2020 19:54:21 -0000 --00000000000040a80105a2e0fb29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having reviewed the comments, I'm wondering if perhaps the following draft rewrite of the Abstract section might be a first step to address many of the points raised? *AbstractDMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. * *The original design of DMARC applies only to domains that are registered with a domain name registrar (called =E2=80=9COrganizational Domains=E2=80= =9D in RFC 7489) and nodes in the tree below Organizational Domains. Organizational Domains are themselves nodes in the tree below domain names reserved for registration, with the latter commonly referred to as =E2=80=9CTop Level Do= mains=E2=80=9D (TLDs) (e.g., =E2=80=98.com=E2=80=99, =E2=80=98.co.uk =E2=80= =99, etc.), although in this document they will be referred to as Public Suffix Domains (PSDs).* *Since its deployment in 2015, use of DMARC has shown a clear need for the ability to express policy for PSDs. This document describes an extension to DMARC to enable DMARC functionality for PSDs.* *RFC 7489 describes an algorithm for a mail-receiving organization to use in determining the Organizational Domain of an inbound mail message, and this algorithm recommends the use of a =E2=80=9Cpublic suffix list=E2=80=9D= (PSL), with the most common one maintained by the Mozilla Foundation and made public at >. Use of such a PSL by a mail-receiving organization will be required in order to discover and apply any DMARC policy declared by a PSD.* *This document also seeks to address implementations that consider a domain on a public Suffix list to be ineligible for DMARC* On Sun, Apr 5, 2020 at 9:11 PM Dale Worley via Datatracker wrote: > Reviewer: Dale Worley > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. > > For more information, please see the FAQ at > > . > > Document: review-draft-ietf-dmarc-psd-08 > Reviewer: Dale R. Worley > Review Date: 2020-04-05 > IETF LC End Date: 2020-04-08 > IESG Telechat date: not known > > * Summary: > > This draft is on the right track but has open issues, described > in the review. > > * Major issues: > > The privacy concerns described in section 4 are written as if there is > no certainty that the mechanisms described in the document properly > mitigate them. So the document appears to be incomplete. OTOH, since > this is an Experimental RFC, such mitigation isn't necessary if there > is commitment to do so later. In that case, the section should > explicitly state that these are open issues and that there is an > intention of revising the document to mitigate them. > > The text suggests that a mail receiver(?) that does DMARC processing > has knowledge of all PSDs. This seems a priori unlikely and even > impossible to implement. So this ought to be either explained at the > appropriate place or resolved technically. > > * Minor issues: > > The document has the (common) editorial problem that it is written by > people who are deeply familiar with the subject, and it's difficult to > read if one doesn't share that familiarity. This is particularly > significant because DMARC is an e-mail facility that (ideally) will > affect all e-mail that is sent, so the target audience really should > be anyone who has a basic understanding of e-mail. Three particular > elements of this are: > > - It would be very helpful if the Introduction could state, in a few > sentences, the purpose and operation of DMARC, thus informing the > reader of the framework whose deficiencies this document attempts to > address. In particular, one shouldn't have to read the DMARC RFCs > to be able to read this document and understand its general import. > > - The "experiment" appendixes are unclear about what the experiments > actually are: what questions they are to answer, what actions will > be taken, how the results will be evaluated. Starting each appendix > with an overview paragraph would be helpful. > > - Forward references should be minimized so that a reader can > understand the document in one pass. > > As a derivative of the first of these elements, the terminology used > for the properties of domain names is not clearly defined. In > particular, where does a registration "occur"? The only term for > which I think the general audience possesses an unambiguous definition > is "the registered domain name", e.g. ietf.org. Now I *think* its PSD > is ".org", but it might be "ietf.org", and I don't know whether the > registration of ietf.org "occurs" at ietf.org or .org. Further points > I didn't understand are pointed out in the review of the > Abstract and Introduction. > > * Nits/editorial comments: > > Abstract > > I'm having quite a bit of difficulty figuring out exactly what the > Abstract means. I'm sure that the working group clearly understands > what is meant, but the writing is just loose enough that I can't fix > the meaning. To raise the immediate questions: > > DMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for > message validation, disposition, and reporting, that a mail-receiving > organization can use to improve mail handling. > > This sentence is quite good, as it introduces what DMARC is all about. > > The design of DMARC > presumes that domain names represent either nodes in the tree below > which registrations occur, or nodes where registrations have > occurred; it does not permit a domain name to have both of these > properties simultaneously. > > You want to make clear here that "registration" means "domain name > ownership registration" (which is what section 2.2 says). Otherwise > it leaves open that there is some sort of DMARC registration that you > might intend, until the reader gets to section 2.2. > > There's an ambiguity regarding "where" a registration happens. E.g., > does the registration of "ietf.org" "occur at" "ietf.org" or "occur > at" "org"? It's possible that this could be simplified/disambiguated > by not using this term, but instead phrasing this in terms of domain > names that "are registered", and the allowed relationships between > them. > > And it appears certain that there are DNS nodes where registrations > are only done *above* that node, e.g. "datatracker.ietf.org", which > this sentence (if taken literally) says is not permitted by DMARC. Is > the property you want to declare "one node where registrations are > done cannot exist below another node where registrations are done"? > > Or perhaps domain names like "datatracker.ietf.org" are of no interest > to DMARC because DMARC is never applied to messages for which that is > the relevant address? > > Since its deployment in 2015, use of > DMARC has shown a clear need for the ability to express policy for > these domains as well. > > This sentence doesn't make it clear what "these domains" refers to. > > Domains at which registrations can occur are referred to as Public > Suffix Domains (PSDs). This document describes an extension to DMARC > to enable DMARC functionality for PSDs. > > It would probably be clearer to use "domain name ownership > registrations" again here. > > This sentence suggests that the registration of "ietf.org" "occurs at" > "org" and so "org" is a PSD. > > This document also seeks to address implementations that consider a > domain on a public Suffix list to be ineligible for DMARC > enforcement. > > This suggests that implementations believe that they know of all PSDs, > so they can "consider them ineligible for DMARC enforcement". But > it's hard to imagine that that they can know that they know of all > PSDs. > > An additional point, and I'm not sure how valuable this is, would be > to clarify "I'm holding an e-mail message in my hands. What do I do > next?", that is, What address in the message is the domain whose DMARC > information is applied to the message? And what indeed does DMARC > processing do to a message? For most of the sentences of the > Abstract, this is not important, but it leaves the effect of the last > sentence unclear, as "DMARC is not enforced on messages whose *sender* > is in a PSD" is quite a bit different from "DMARC is not enforced on > messages whose *recipient* is in a PSD". (Section 3.3 suggests that > the address in the From header of the message is the one that is used > for DMARC processing.) > > It's unclear what exactly is the contents of a "public suffix list". > Naively, it appears that it is the list of domain names under which > names can be registered, but the text uses the term in the plural, so > there must be some additional structure. > > Also, it seems there are some significant privacy matters addressed by > this document, and it's probably worth adding a sentence to notify the > reader of that. > > 1. Introduction > > A number of the questions about the Abstract apply to the Introduction > as well. But generally, since e-mail is a subject that every reader > has a basic knowledge of, it would be useful to write the introduction > so that one did not have to have a knowledge of the DMARC architecture > to understand the introduction. > > "gov.example" publishes the following DMARC record: > > "v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmarc.service.gov.example" > > at > > _dmarc.gov.example. > > Even better would be this aid to people who don't already know DMARC > implementation: > > "gov.example" publishes the following DMARC DNS record: > > _dmarc.gov.example. TXT \ > "v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmarc.service.gov.exa= mple" > > -- > > the non-existent organizational domain of @tax.gov.example > > I suspect you mean "t4x.gov.example" here. > > This document provides a simple extension to DMARC [RFC7489] to > allow [...] > > This sentence lists 4 important items, each of which is fairly long, > which together are the summary of the whole document, so it might be > useful to break this into a bullet-list. > > 2. Terminology and Definitions > > In many cases the public portion of the DNS tree is [...] > > What does "the public portion" mean? I'm guessing it means "the names > not available for private registration", but you should be unambiguous > here. > > They are not available for private > registration. In many cases the public portion of the DNS tree is > more than one level deep. > > It seems like these two sentences are redundant and the flow of the > paragraph would be better if they were removed. ... Actually once they > are removed, it reveals that the next two sentences largely duplicate > the first two sentences of the paragraph. > > 2.3. Longest PSD > > The longest PSD is the Organizational Domain with one label removed. > > 2.4. Organizational Domain > > The term Organizational Domains is defined in DMARC [RFC7489] > Section 3.2. > > 2.4 should be moved ahead of 2.3 to avoid a forward-reference. But it > would be really helpful if the definition of Organizational Domain was > either summarized here or completely copied from RFC7489. In > particular, if Organizational Domain is not the same as registered > domain name, that should be flagged. > > 2.5. Public Suffix Operator (PSO) > > A Public Suffix Operator manages operations within its PSD. > > Better to explicitly define the possession relationship explicitly: > > A Public Suffix Operator is an organization which manages > operations within a PSD, particularly the DNS records published for > names at and under that domain name. > > -- > > 2.6. PSO Controlled Domain Names > > PSO Controlled Domain Names are names in the DNS that are managed by > a PSO and are not available for use as Organizational Domains. > Depending on PSD policy, these will have one (e.g., ".com") or more > (e.g., ".co.uk") name components. > > The second sentence is odd; is it useful? Is it just to say "PSO > Controlled Domain Names may have one or more components."? > > 3.1. General Updates > > References to "Domain Owners" also apply to PSOs. > > This change really ought to be localized to a specific textual change > somewhere in RFC 7489, in the say way that the other changes are > specific amendments to the DMARC algorithm. > > 3.2. Section 6.3 General Record Format > > These section titles are difficult to read. At first I thought there > was some typographical problem. But you could clarify this as "3.2. > Updates to Section 6.3. General Record Format". Similarly for the > other subsections of section 3. > > 3.3. Section 6.5. Domain Owner Actions > > The mechanism for doing so is one of the > experimental elements of this document. > > I think that what this means is that the whole document is an > experimental "mechanism for doing so". If so, I think it could be > better phrased > > This document is an experimental mechanism for doing so. > > -- > > 3.4. Section 6.6.1. Extract Author Domain > > [...] when the domain name extracted by the receiver (from the > RFC5322.From) is on the public suffix list used by the receiver. > > This touches the question above about what a public suffix list is, > and how there can be more than one of them. But without that > knowledge, it's hard to see which PSL is "used" by the receiver of the > message. > > Also, it's not clear to me how *this* document creates a capability > which applies to domains that are on the PSL. E.g., if an "np" is > defined for ".org", it applies to (that is, affects processing of > e-mail from) any "X.org" that doesn't have its own DMARC records. But > I don't see how an "np" tag for ".org" affects processing of messages > from "example@org". > > 3.5. Section 6.6.3. Policy Discovery > > (discussed in the experiment description > (Appendix A)) > > Given that this text is nominally an update to the text of RFC 7489, > you want to disambiguate the binding of "Appendix A": > > (discussed in the experiment description > ([this document] Appendix A)) > > 3.6. Section 7. DMARC Feedback > > See Section 4 of this document for discussion of Privacy > Considerations. > > Similarly to section 3.5, but also clarifying the scope of "privacy > considerations": > > See Section 4 of [this document] for discussion of Privacy > Considerations for PSD DMARC. > > 4. Privacy Considerations > > The Privacy Considerations of [RFC7489] apply to this document. > > This could be clarified as > > Additionally, the Privacy Considerations of [RFC7489] apply to the > mechanisms described by this document. > > -- > > Providing feedback reporting to PSOs can, in some cases, create > leakage of information outside of an organization to the PSO. > > "outside" probably isn't the word you want to use here, as it is > easier to read "outside" as giving the original location of > "information" than to read "outside" as giving the direction of > "leakage". Perhaps > > Providing feedback reporting to PSOs can, in some cases, create > leakage of information out of an organization to the PSO of its > domain name. > > -- > > To minimize this potential concern, > PSD DMARC feedback is best limited to Aggregate Reports. [...] > > [...] any Feedback Reporting related to multi- > organizational PSDs ought to be limited to non-existent domains > except in cases where the reporter knows that PSO requires use of > DMARC. > > I can't see where in the document that these principles are turned > into MUST statements that ensure the privacy issues are solved. > > The experiment is to evaluate different possible approaches. > > Calling this an "experiment" suggests that these is an intended series > of actions whose result will answer the listed questions. But there > doesn't seem to be any such actions listed. The description makes it > sound like what is intended is continuing discussions in the working > group, but that wouldn't be an "experiment". > > A.2. Non-Existent Subdomain Policy > > Similar questions arise for this section. The second paragraph > suggests that the experiment is to see whether the "np" tag is > successful. > > There are also > suggestions that it would be more generally useful for DMARC. > > What does "it" refer to? (Does it mean "this ability"?) > > Appendix B. DMARC PSD Registry Examples > > In this appendix, it appears that the contents of the experiment are > clear in the authors' minds, but there is no summary at the top that > states what the experimental facilities are and the "big picture" into > which they fit. > > Appendix C. Implementations > > C.1. Authheaders Module > > What e-mail MTA is Authheaders an extension for? > > [END] > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --=20 Todd Herr --00000000000040a80105a2e0fb29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having reviewed the comments, I= 'm wondering if perhaps the following draft rewrite of the Abstract sec= tion might be a first step to address many of the points raised?

<= b style=3D"font-weight:normal" id=3D"gmail-docs-internal-guid-fce386d9-7fff= -dc67-41b0-42892eeba272">

Abstract

DMAR= C (Domain-based Message Authentication, Reporting, and Conformance) is a sc= alable mechanism by which a mail-originating organization can express domai= n-level policies and preferences for message validation, disposition, and r= eporting, that a mail-receiving organization can use to improve mail handli= ng.=C2=A0=C2=A0


The original des= ign of DMARC applies only to domains that are registered with a domain name= registrar (called =E2=80=9COrganizational Domains=E2=80=9D in RFC 7489) an= d nodes in the tree below Organizational Domains. Organizational Domains ar= e themselves nodes in the tree below domain names reserved for registration= , with the latter commonly referred to as =E2=80=9CTop Level Domains=E2=80= =9D (TLDs) (e.g., =E2=80=98.com=E2=80=99, =E2=80=98.co.uk=E2=80=99, etc.), although in this document they will be referre= d to as Public Suffix Domains (PSDs).


Since its deployment in 2015, use of DMARC has shown a clear need f= or the ability to express policy for PSDs. This document describes an exten= sion to DMARC to enable DMARC functionality for PSDs.

=

RFC 7489 describes an algorithm for a mail-receiving = organization to use in determining the Organizational Domain of an inbound = mail message, and this algorithm recommends the use of a =E2=80=9Cpublic su= ffix list=E2=80=9D (PSL), with the most common one maintained by the Mozill= a Foundation and made public at <http://publicsuffix.org/>. Use of such a PSL by a mail-receiving o= rganization will be required in order to discover and apply any DMARC polic= y declared by a PSD.


This docume= nt also seeks to address implementations that consider a domain on a public= Suffix list to be ineligible for DMARC



On Sun, Apr 5, 2020 at 9:11 PM = Dale Worley via Datatracker <noreply= @ietf.org> wrote:
Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.=C2=A0 The General Area Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.=C2=A0 Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document:=C2=A0 review-draft-ietf-dmarc-psd-08
Reviewer:=C2=A0 Dale R. Worley
Review Date:=C2=A0 2020-04-05
IETF LC End Date:=C2=A0 2020-04-08
IESG Telechat date:=C2=A0 not known

* Summary:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This draft is on the right track but has open is= sues, described
=C2=A0 =C2=A0 =C2=A0 =C2=A0in the review.

* Major issues:

The privacy concerns described in section 4 are written as if there is
no certainty that the mechanisms described in the document properly
mitigate them.=C2=A0 So the document appears to be incomplete.=C2=A0 OTOH, = since
this is an Experimental RFC, such mitigation isn't necessary if there is commitment to do so later.=C2=A0 In that case, the section should
explicitly state that these are open issues and that there is an
intention of revising the document to mitigate them.

The text suggests that a mail receiver(?) that does DMARC processing
has knowledge of all PSDs.=C2=A0 This seems a priori unlikely and even
impossible to implement.=C2=A0 So this ought to be either explained at the<= br> appropriate place or resolved technically.

* Minor issues:

The document has the (common) editorial problem that it is written by
people who are deeply familiar with the subject, and it's difficult to<= br> read if one doesn't share that familiarity.=C2=A0 This is particularly<= br> significant because DMARC is an e-mail facility that (ideally) will
affect all e-mail that is sent, so the target audience really should
be anyone who has a basic understanding of e-mail.=C2=A0 Three particular elements of this are:

- It would be very helpful if the Introduction could state, in a few
=C2=A0 sentences, the purpose and operation of DMARC, thus informing the =C2=A0 reader of the framework whose deficiencies this document attempts to=
=C2=A0 address.=C2=A0 In particular, one shouldn't have to read the DMA= RC RFCs
=C2=A0 to be able to read this document and understand its general import.<= br>
- The "experiment" appendixes are unclear about what the experime= nts
=C2=A0 actually are:=C2=A0 what questions they are to answer, what actions = will
=C2=A0 be taken, how the results will be evaluated.=C2=A0 Starting each app= endix
=C2=A0 with an overview paragraph would be helpful.

- Forward references should be minimized so that a reader can
=C2=A0 understand the document in one pass.

As a derivative of the first of these elements, the terminology used
for the properties of domain names is not clearly defined.=C2=A0 In
particular, where does a registration "occur"?=C2=A0 The only ter= m for
which I think the general audience possesses an unambiguous definition
is "the registered domain name", e.g. ietf.org.=C2=A0 Now I *think* its= PSD
is ".org", but it might be "ietf.org", and I don't know = whether the
registration of ietf.org "occurs" at ietf.org or .org.=C2=A0 Further points I didn't understand are pointed out in the review of the
Abstract and Introduction.

* Nits/editorial comments:

Abstract

I'm having quite a bit of difficulty figuring out exactly what the
Abstract means.=C2=A0 I'm sure that the working group clearly understan= ds
what is meant, but the writing is just loose enough that I can't fix the meaning.=C2=A0 To raise the immediate questions:

=C2=A0 =C2=A0DMARC (Domain-based Message Authentication, Reporting, and
=C2=A0 =C2=A0Conformance) is a scalable mechanism by which a mail-originati= ng
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.

This sentence is quite good, as it introduces what DMARC is all about.

=C2=A0 =C2=A0The design of DMARC
=C2=A0 =C2=A0presumes that domain names represent either nodes in the tree = below
=C2=A0 =C2=A0which registrations occur, or nodes where registrations have =C2=A0 =C2=A0occurred; it does not permit a domain name to have both of the= se
=C2=A0 =C2=A0properties simultaneously.

You want to make clear here that "registration" means "domai= n name
ownership registration" (which is what section 2.2 says).=C2=A0 Otherw= ise
it leaves open that there is some sort of DMARC registration that you
might intend, until the reader gets to section 2.2.

There's an ambiguity regarding "where" a registration happens= .=C2=A0 E.g.,
does the registration of "ietf.org" "occur at" "ietf.org"= ; or "occur
at" "org"?=C2=A0 It's possible that this could be simpli= fied/disambiguated
by not using this term, but instead phrasing this in terms of domain
names that "are registered", and the allowed relationships betwee= n
them.

And it appears certain that there are DNS nodes where registrations
are only done *above* that node, e.g. "datatracker.ietf.org"= ;, which
this sentence (if taken literally) says is not permitted by DMARC.=C2=A0 Is=
the property you want to declare "one node where registrations are
done cannot exist below another node where registrations are done"?
Or perhaps domain names like "datatracker.ietf.org" are of = no interest
to DMARC because DMARC is never applied to messages for which that is
the relevant address?

=C2=A0 =C2=A0Since its deployment in 2015, use of
=C2=A0 =C2=A0DMARC has shown a clear need for the ability to express policy= for
=C2=A0 =C2=A0these domains as well.

This sentence doesn't make it clear what "these domains" refe= rs to.

=C2=A0 =C2=A0Domains at which registrations can occur are referred to as Pu= blic
=C2=A0 =C2=A0Suffix Domains (PSDs).=C2=A0 This document describes an extens= ion to DMARC
=C2=A0 =C2=A0to enable DMARC functionality for PSDs.

It would probably be clearer to use "domain name ownership
registrations" again here.

This sentence suggests that the registration of "ietf.org" "occurs= at"
"org" and so "org" is a PSD.

=C2=A0 =C2=A0This document also seeks to address implementations that consi= der a
=C2=A0 =C2=A0domain on a public Suffix list to be ineligible for DMARC
=C2=A0 =C2=A0enforcement.

This suggests that implementations believe that they know of all PSDs,
so they can "consider them ineligible for DMARC enforcement".=C2= =A0 But
it's hard to imagine that that they can know that they know of all
PSDs.

An additional point, and I'm not sure how valuable this is, would be to clarify "I'm holding an e-mail message in my hands.=C2=A0 What = do I do
next?", that is, What address in the message is the domain whose DMARC=
information is applied to the message?=C2=A0 And what indeed does DMARC
processing do to a message?=C2=A0 For most of the sentences of the
Abstract, this is not important, but it leaves the effect of the last
sentence unclear, as "DMARC is not enforced on messages whose *sender*=
is in a PSD" is quite a bit different from "DMARC is not enforced= on
messages whose *recipient* is in a PSD".=C2=A0 (Section 3.3 suggests t= hat
the address in the From header of the message is the one that is used
for DMARC processing.)

It's unclear what exactly is the contents of a "public suffix list= ".
Naively, it appears that it is the list of domain names under which
names can be registered, but the text uses the term in the plural, so
there must be some additional structure.

Also, it seems there are some significant privacy matters addressed by
this document, and it's probably worth adding a sentence to notify the<= br> reader of that.

1.=C2=A0 Introduction

A number of the questions about the Abstract apply to the Introduction
as well.=C2=A0 But generally, since e-mail is a subject that every reader has a basic knowledge of, it would be useful to write the introduction
so that one did not have to have a knowledge of the DMARC architecture
to understand the introduction.

=C2=A0 =C2=A0"gov.example" publishes the following DMARC record:<= br>
=C2=A0 =C2=A0"v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmarc.service.gov.e= xample"

=C2=A0 =C2=A0at

=C2=A0 =C2=A0_dmarc.gov.example.

Even better would be this aid to people who don't already know DMARC implementation:

=C2=A0 =C2=A0"gov.example" publishes the following DMARC DNS reco= rd:

=C2=A0 =C2=A0_dmarc.gov.example.=C2=A0 TXT \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmar= c.service.gov.example"

--

=C2=A0 =C2=A0the non-existent organizational domain of @tax.gov.example

I suspect you mean "t4x.gov.example" here.

=C2=A0 =C2=A0This document provides a simple extension to DMARC [RFC7489] t= o
=C2=A0 =C2=A0allow [...]

This sentence lists 4 important items, each of which is fairly long,
which together are the summary of the whole document, so it might be
useful to break this into a bullet-list.

2.=C2=A0 Terminology and Definitions

=C2=A0 =C2=A0In many cases the public portion of the DNS tree is [...]

What does "the public portion" mean?=C2=A0 I'm guessing it me= ans "the names
not available for private registration", but you should be unambiguous=
here.

=C2=A0 =C2=A0They are not available for private
=C2=A0 =C2=A0registration.=C2=A0 In many cases the public portion of the DN= S tree is
=C2=A0 =C2=A0more than one level deep.

It seems like these two sentences are redundant and the flow of the
paragraph would be better if they were removed. ... Actually once they
are removed, it reveals that the next two sentences largely duplicate
the first two sentences of the paragraph.

=C2=A0 =C2=A02.3.=C2=A0 Longest PSD

=C2=A0 =C2=A0The longest PSD is the Organizational Domain with one label re= moved.

=C2=A0 =C2=A02.4.=C2=A0 Organizational Domain

=C2=A0 =C2=A0The term Organizational Domains is defined in DMARC [RFC7489]<= br> =C2=A0 =C2=A0Section 3.2.

2.4 should be moved ahead of 2.3 to avoid a forward-reference.=C2=A0 But it=
would be really helpful if the definition of Organizational Domain was
either summarized here or completely copied from RFC7489.=C2=A0 In
particular, if Organizational Domain is not the same as registered
domain name, that should be flagged.

=C2=A0 =C2=A02.5.=C2=A0 Public Suffix Operator (PSO)

=C2=A0 =C2=A0A Public Suffix Operator manages operations within its PSD.
Better to explicitly define the possession relationship explicitly:

=C2=A0 =C2=A0A Public Suffix Operator is an organization which manages
=C2=A0 =C2=A0operations within a PSD, particularly the DNS records publishe= d for
=C2=A0 =C2=A0names at and under that domain name.

--

=C2=A0 =C2=A02.6.=C2=A0 PSO Controlled Domain Names

=C2=A0 =C2=A0PSO Controlled Domain Names are names in the DNS that are mana= ged by
=C2=A0 =C2=A0a PSO and are not available for use as Organizational Domains.=
=C2=A0 =C2=A0Depending on PSD policy, these will have one (e.g., ".com= ") or more
=C2=A0 =C2=A0(e.g., ".co.uk") name components.

The second sentence is odd; is it useful?=C2=A0 Is it just to say "PSO=
Controlled Domain Names may have one or more components."?

=C2=A0 =C2=A03.1.=C2=A0 General Updates

=C2=A0 =C2=A0References to "Domain Owners" also apply to PSOs.
This change really ought to be localized to a specific textual change
somewhere in RFC 7489, in the say way that the other changes are
specific amendments to the DMARC algorithm.

=C2=A0 =C2=A03.2.=C2=A0 Section 6.3 General Record Format

These section titles are difficult to read.=C2=A0 At first I thought there<= br> was some typographical problem.=C2=A0 But you could clarify this as "3= .2.
Updates to Section 6.3.=C2=A0 General Record Format".=C2=A0 Similarly = for the
other subsections of section 3.

3.3.=C2=A0 Section 6.5.=C2=A0 Domain Owner Actions

=C2=A0 =C2=A0The mechanism for doing so is one of the
=C2=A0 =C2=A0experimental elements of this document.

I think that what this means is that the whole document is an
experimental "mechanism for doing so".=C2=A0 If so, I think it co= uld be
better phrased

=C2=A0 =C2=A0This document is an experimental mechanism for doing so.

--

=C2=A0 =C2=A03.4.=C2=A0 Section 6.6.1.=C2=A0 Extract Author Domain

=C2=A0 =C2=A0[...] when the domain name extracted by the receiver (from the=
=C2=A0 =C2=A0RFC5322.From) is on the public suffix list used by the receive= r.

This touches the question above about what a public suffix list is,
and how there can be more than one of them.=C2=A0 But without that
knowledge, it's hard to see which PSL is "used" by the receiv= er of the
message.

Also, it's not clear to me how *this* document creates a capability
which applies to domains that are on the PSL.=C2=A0 E.g., if an "np&qu= ot; is
defined for ".org", it applies to (that is, affects processing of=
e-mail from) any "X.org" that doesn't have its own DMARC reco= rds.=C2=A0 But
I don't see how an "np" tag for ".org" affects proc= essing of messages
from "example@org".

=C2=A0 =C2=A03.5.=C2=A0 Section 6.6.3.=C2=A0 Policy Discovery

=C2=A0 =C2=A0 =C2=A0 (discussed in the experiment description
=C2=A0 =C2=A0 =C2=A0 (Appendix A))

Given that this text is nominally an update to the text of RFC 7489,
you want to disambiguate the binding of "Appendix A":

=C2=A0 =C2=A0 =C2=A0 (discussed in the experiment description
=C2=A0 =C2=A0 =C2=A0 ([this document] Appendix A))

=C2=A0 =C2=A03.6.=C2=A0 Section 7.=C2=A0 DMARC Feedback

=C2=A0 =C2=A0See Section 4 of this document for discussion of Privacy
=C2=A0 =C2=A0Considerations.

Similarly to section 3.5, but also clarifying the scope of "privacy considerations":

=C2=A0 =C2=A0See Section 4 of [this document] for discussion of Privacy
=C2=A0 =C2=A0Considerations for PSD DMARC.

=C2=A0 =C2=A04.=C2=A0 Privacy Considerations

=C2=A0 =C2=A0The Privacy Considerations of [RFC7489] apply to this document= .

This could be clarified as

=C2=A0 =C2=A0Additionally, the Privacy Considerations of [RFC7489] apply to= the
=C2=A0 =C2=A0mechanisms described by this document.

--

=C2=A0 =C2=A0Providing feedback reporting to PSOs can, in some cases, creat= e
=C2=A0 =C2=A0leakage of information outside of an organization to the PSO.<= br>
"outside" probably isn't the word you want to use here, as it= is
easier to read "outside" as giving the original location of
"information" than to read "outside" as giving the dire= ction of
"leakage".=C2=A0 Perhaps

=C2=A0 =C2=A0Providing feedback reporting to PSOs can, in some cases, creat= e
=C2=A0 =C2=A0leakage of information out of an organization to the PSO of it= s
=C2=A0 =C2=A0domain name.

--

=C2=A0 =C2=A0To minimize this potential concern,
=C2=A0 =C2=A0PSD DMARC feedback is best limited to Aggregate Reports.=C2=A0= [...]

=C2=A0 =C2=A0[...] any Feedback Reporting related to multi-
=C2=A0 =C2=A0organizational PSDs ought to be limited to non-existent domain= s
=C2=A0 =C2=A0except in cases where the reporter knows that PSO requires use= of
=C2=A0 =C2=A0DMARC.

I can't see where in the document that these principles are turned
into MUST statements that ensure the privacy issues are solved.

=C2=A0 =C2=A0The experiment is to evaluate different possible approaches.
Calling this an "experiment" suggests that these is an intended s= eries
of actions whose result will answer the listed questions.=C2=A0 But there doesn't seem to be any such actions listed.=C2=A0 The description makes= it
sound like what is intended is continuing discussions in the working
group, but that wouldn't be an "experiment".

A.2.=C2=A0 Non-Existent Subdomain Policy

Similar questions arise for this section.=C2=A0 The second paragraph
suggests that the experiment is to see whether the "np" tag is successful.

=C2=A0 =C2=A0There are also
=C2=A0 =C2=A0suggestions that it would be more generally useful for DMARC.<= br>
What does "it" refer to?=C2=A0 (Does it mean "this ability&q= uot;?)

Appendix B.=C2=A0 DMARC PSD Registry Examples

In this appendix, it appears that the contents of the experiment are
clear in the authors' minds, but there is no summary at the top that states what the experimental facilities are and the "big picture"= into
which they fit.

Appendix C.=C2=A0 Implementations

=C2=A0 =C2=A0C.1.=C2=A0 Authheaders Module

What e-mail MTA is Authheaders an extension for?

[END]



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


--
Todd Herr
<= /div>
--00000000000040a80105a2e0fb29-- From nobody Thu Apr 9 13:36: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 DDA953A0DDF; Thu, 9 Apr 2020 13:36:26 -0700 (PDT) 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 sGVX7YzIu-QP; Thu, 9 Apr 2020 13:36:20 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29C13A0FB6; Thu, 9 Apr 2020 13:35:58 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id h189so110311vsc.13; Thu, 09 Apr 2020 13:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=msbmiiaKTT/+t1DfFqpYCSgWnUV33m2GnQDvvNPkhxM=; b=TJh0MFWEr9Ehdv5ucIXcPQ05Tg1yK6tIBUTgjJ/xcIKuPBcXhOrNRorNFrF82DUWAo 6RVYwnvO3G9s93KYvZyOjUmIAKR+FpALLV2k60+Ol+W+ZhrsbwHx8oFU8YtPD/Pd2lHJ Fj4IYqdFhX4mRWeMMtzoe8rXzoSLP/6TGCh162QlUznF8+6es08p3Yi0zgidqKpExFU2 1EX0bgOMe+/n5gjLrJ5Dw84EdDvZCtByhPgX/JbJs6UQwU+Tyvq9xgkJ7iPI6DM695dy 1coWTcOmWDonu4J2q6csTzqFXpzaDBaj+nrVVxUgFBOiPAsI6eRfE5sqHPnVZ2kHu1Sa JyEQ== 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=msbmiiaKTT/+t1DfFqpYCSgWnUV33m2GnQDvvNPkhxM=; b=L6yuwlNLi9AeYSwuFjt07kMckmGP8N3X9AF60fP73Ii+WdneBlqeDFElocaDFQwTT9 ZMfJgCSZnc7RhOCsKMLS7LPL51/d8Y7cbTxJ62a3E0CSbZcAIrTPlUktw1GvAsDxisHV 35qEQ1psjOMUjE0RMaTg5oh8W+bHLuY255Iyz7kN/5xK0bHtyNO/hvZLkDc4uxuxonIb X+8HVI/up2RLF3wHBz33T195XJ2zUvtA4i7OAnRG3m6oPvNuD+fZRTRES5jTa0Q3wdvj uCzbKhCW61gx1Iq3K7IMO/eGLGFi6rNQGcfgo6oxA5sZf448b+gFcOmjqOORvmiNhSq9 rxew== X-Gm-Message-State: AGi0PuZOqzckirOHXoqWbzqfFIlHUGpA6FE6B3a/X/PZGXCEuXfpQf6H xjqshjaf9PFfd8NKQhO4t5Mw6JjuESy6viLtcsQ= X-Google-Smtp-Source: APiQypJ/AnJrh9NjjQ9+SJldt+6LGfvWjqL/j3gnKWfzFQ6i7qTJy0MmD02pDqkJ/cNxTa8j6swBGMVCZBDP1OtX0dY= X-Received: by 2002:a67:804a:: with SMTP id b71mr1524595vsd.175.1586464557329; Thu, 09 Apr 2020 13:35:57 -0700 (PDT) MIME-Version: 1.0 References: <158613543159.15216.5517593808552135017@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 9 Apr 2020 13:35:45 -0700 Message-ID: To: Todd Herr Cc: Dale Worley , General Area Review Team , dmarc Content-Type: multipart/alternative; boundary="0000000000006376a405a2e190b6" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 09 Apr 2020 20:36:27 -0000 --0000000000006376a405a2e190b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Reducing Ccs) That seems like it paints a much clearer picture, which is what Dale was after. A great start! On Thu, Apr 9, 2020 at 12:54 PM Todd Herr wrote: > Having reviewed the comments, I'm wondering if perhaps the following draf= t > rewrite of the Abstract section might be a first step to address many of > the points raised? > > *AbstractDMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for messag= e > validation, disposition, and reporting, that a mail-receiving organizatio= n > can use to improve mail handling. * > > *The original design of DMARC applies only to domains that are registered > with a domain name registrar (called =E2=80=9COrganizational Domains=E2= =80=9D in RFC 7489) > and nodes in the tree below Organizational Domains. Organizational Domain= s > are themselves nodes in the tree below domain names reserved for > registration, with the latter commonly referred to as =E2=80=9CTop Level = Domains=E2=80=9D > (TLDs) (e.g., =E2=80=98.com=E2=80=99, =E2=80=98.co.uk =E2= =80=99, etc.), although in this > document they will be referred to as Public Suffix Domains (PSDs).* > > *Since its deployment in 2015, use of DMARC has shown a clear need for th= e > ability to express policy for PSDs. This document describes an extension = to > DMARC to enable DMARC functionality for PSDs.* > > *RFC 7489 describes an algorithm for a mail-receiving organization to use > in determining the Organizational Domain of an inbound mail message, and > this algorithm recommends the use of a =E2=80=9Cpublic suffix list=E2=80= =9D (PSL), with the > most common one maintained by the Mozilla Foundation and made public at > >. Use of such a PSL = by > a mail-receiving organization will be required in order to discover and > apply any DMARC policy declared by a PSD.* > > *This document also seeks to address implementations that consider a > domain on a public Suffix list to be ineligible for DMARC* > > > On Sun, Apr 5, 2020 at 9:11 PM Dale Worley via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Dale Worley >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed by >> the IESG for the IETF Chair. Please treat these comments just like >> any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: review-draft-ietf-dmarc-psd-08 >> Reviewer: Dale R. Worley >> Review Date: 2020-04-05 >> IETF LC End Date: 2020-04-08 >> IESG Telechat date: not known >> >> * Summary: >> >> This draft is on the right track but has open issues, described >> in the review. >> >> * Major issues: >> >> The privacy concerns described in section 4 are written as if there is >> no certainty that the mechanisms described in the document properly >> mitigate them. So the document appears to be incomplete. OTOH, since >> this is an Experimental RFC, such mitigation isn't necessary if there >> is commitment to do so later. In that case, the section should >> explicitly state that these are open issues and that there is an >> intention of revising the document to mitigate them. >> >> The text suggests that a mail receiver(?) that does DMARC processing >> has knowledge of all PSDs. This seems a priori unlikely and even >> impossible to implement. So this ought to be either explained at the >> appropriate place or resolved technically. >> >> * Minor issues: >> >> The document has the (common) editorial problem that it is written by >> people who are deeply familiar with the subject, and it's difficult to >> read if one doesn't share that familiarity. This is particularly >> significant because DMARC is an e-mail facility that (ideally) will >> affect all e-mail that is sent, so the target audience really should >> be anyone who has a basic understanding of e-mail. Three particular >> elements of this are: >> >> - It would be very helpful if the Introduction could state, in a few >> sentences, the purpose and operation of DMARC, thus informing the >> reader of the framework whose deficiencies this document attempts to >> address. In particular, one shouldn't have to read the DMARC RFCs >> to be able to read this document and understand its general import. >> >> - The "experiment" appendixes are unclear about what the experiments >> actually are: what questions they are to answer, what actions will >> be taken, how the results will be evaluated. Starting each appendix >> with an overview paragraph would be helpful. >> >> - Forward references should be minimized so that a reader can >> understand the document in one pass. >> >> As a derivative of the first of these elements, the terminology used >> for the properties of domain names is not clearly defined. In >> particular, where does a registration "occur"? The only term for >> which I think the general audience possesses an unambiguous definition >> is "the registered domain name", e.g. ietf.org. Now I *think* its PSD >> is ".org", but it might be "ietf.org", and I don't know whether the >> registration of ietf.org "occurs" at ietf.org or .org. Further points >> I didn't understand are pointed out in the review of the >> Abstract and Introduction. >> >> * Nits/editorial comments: >> >> Abstract >> >> I'm having quite a bit of difficulty figuring out exactly what the >> Abstract means. I'm sure that the working group clearly understands >> what is meant, but the writing is just loose enough that I can't fix >> the meaning. To raise the immediate questions: >> >> DMARC (Domain-based Message Authentication, Reporting, and >> Conformance) is a scalable mechanism by which a mail-originating >> organization can express domain-level policies and preferences for >> message validation, disposition, and reporting, that a mail-receiving >> organization can use to improve mail handling. >> >> This sentence is quite good, as it introduces what DMARC is all about. >> >> The design of DMARC >> presumes that domain names represent either nodes in the tree below >> which registrations occur, or nodes where registrations have >> occurred; it does not permit a domain name to have both of these >> properties simultaneously. >> >> You want to make clear here that "registration" means "domain name >> ownership registration" (which is what section 2.2 says). Otherwise >> it leaves open that there is some sort of DMARC registration that you >> might intend, until the reader gets to section 2.2. >> >> There's an ambiguity regarding "where" a registration happens. E.g., >> does the registration of "ietf.org" "occur at" "ietf.org" or "occur >> at" "org"? It's possible that this could be simplified/disambiguated >> by not using this term, but instead phrasing this in terms of domain >> names that "are registered", and the allowed relationships between >> them. >> >> And it appears certain that there are DNS nodes where registrations >> are only done *above* that node, e.g. "datatracker.ietf.org", which >> this sentence (if taken literally) says is not permitted by DMARC. Is >> the property you want to declare "one node where registrations are >> done cannot exist below another node where registrations are done"? >> >> Or perhaps domain names like "datatracker.ietf.org" are of no interest >> to DMARC because DMARC is never applied to messages for which that is >> the relevant address? >> >> Since its deployment in 2015, use of >> DMARC has shown a clear need for the ability to express policy for >> these domains as well. >> >> This sentence doesn't make it clear what "these domains" refers to. >> >> Domains at which registrations can occur are referred to as Public >> Suffix Domains (PSDs). This document describes an extension to DMARC >> to enable DMARC functionality for PSDs. >> >> It would probably be clearer to use "domain name ownership >> registrations" again here. >> >> This sentence suggests that the registration of "ietf.org" "occurs at" >> "org" and so "org" is a PSD. >> >> This document also seeks to address implementations that consider a >> domain on a public Suffix list to be ineligible for DMARC >> enforcement. >> >> This suggests that implementations believe that they know of all PSDs, >> so they can "consider them ineligible for DMARC enforcement". But >> it's hard to imagine that that they can know that they know of all >> PSDs. >> >> An additional point, and I'm not sure how valuable this is, would be >> to clarify "I'm holding an e-mail message in my hands. What do I do >> next?", that is, What address in the message is the domain whose DMARC >> information is applied to the message? And what indeed does DMARC >> processing do to a message? For most of the sentences of the >> Abstract, this is not important, but it leaves the effect of the last >> sentence unclear, as "DMARC is not enforced on messages whose *sender* >> is in a PSD" is quite a bit different from "DMARC is not enforced on >> messages whose *recipient* is in a PSD". (Section 3.3 suggests that >> the address in the From header of the message is the one that is used >> for DMARC processing.) >> >> It's unclear what exactly is the contents of a "public suffix list". >> Naively, it appears that it is the list of domain names under which >> names can be registered, but the text uses the term in the plural, so >> there must be some additional structure. >> >> Also, it seems there are some significant privacy matters addressed by >> this document, and it's probably worth adding a sentence to notify the >> reader of that. >> >> 1. Introduction >> >> A number of the questions about the Abstract apply to the Introduction >> as well. But generally, since e-mail is a subject that every reader >> has a basic knowledge of, it would be useful to write the introduction >> so that one did not have to have a knowledge of the DMARC architecture >> to understand the introduction. >> >> "gov.example" publishes the following DMARC record: >> >> "v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmarc.service.gov.example= " >> >> at >> >> _dmarc.gov.example. >> >> Even better would be this aid to people who don't already know DMARC >> implementation: >> >> "gov.example" publishes the following DMARC DNS record: >> >> _dmarc.gov.example. TXT \ >> "v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmarc.service.gov.ex= ample" >> >> -- >> >> the non-existent organizational domain of @tax.gov.example >> >> I suspect you mean "t4x.gov.example" here. >> >> This document provides a simple extension to DMARC [RFC7489] to >> allow [...] >> >> This sentence lists 4 important items, each of which is fairly long, >> which together are the summary of the whole document, so it might be >> useful to break this into a bullet-list. >> >> 2. Terminology and Definitions >> >> In many cases the public portion of the DNS tree is [...] >> >> What does "the public portion" mean? I'm guessing it means "the names >> not available for private registration", but you should be unambiguous >> here. >> >> They are not available for private >> registration. In many cases the public portion of the DNS tree is >> more than one level deep. >> >> It seems like these two sentences are redundant and the flow of the >> paragraph would be better if they were removed. ... Actually once they >> are removed, it reveals that the next two sentences largely duplicate >> the first two sentences of the paragraph. >> >> 2.3. Longest PSD >> >> The longest PSD is the Organizational Domain with one label removed. >> >> 2.4. Organizational Domain >> >> The term Organizational Domains is defined in DMARC [RFC7489] >> Section 3.2. >> >> 2.4 should be moved ahead of 2.3 to avoid a forward-reference. But it >> would be really helpful if the definition of Organizational Domain was >> either summarized here or completely copied from RFC7489. In >> particular, if Organizational Domain is not the same as registered >> domain name, that should be flagged. >> >> 2.5. Public Suffix Operator (PSO) >> >> A Public Suffix Operator manages operations within its PSD. >> >> Better to explicitly define the possession relationship explicitly: >> >> A Public Suffix Operator is an organization which manages >> operations within a PSD, particularly the DNS records published for >> names at and under that domain name. >> >> -- >> >> 2.6. PSO Controlled Domain Names >> >> PSO Controlled Domain Names are names in the DNS that are managed by >> a PSO and are not available for use as Organizational Domains. >> Depending on PSD policy, these will have one (e.g., ".com") or more >> (e.g., ".co.uk") name components. >> >> The second sentence is odd; is it useful? Is it just to say "PSO >> Controlled Domain Names may have one or more components."? >> >> 3.1. General Updates >> >> References to "Domain Owners" also apply to PSOs. >> >> This change really ought to be localized to a specific textual change >> somewhere in RFC 7489, in the say way that the other changes are >> specific amendments to the DMARC algorithm. >> >> 3.2. Section 6.3 General Record Format >> >> These section titles are difficult to read. At first I thought there >> was some typographical problem. But you could clarify this as "3.2. >> Updates to Section 6.3. General Record Format". Similarly for the >> other subsections of section 3. >> >> 3.3. Section 6.5. Domain Owner Actions >> >> The mechanism for doing so is one of the >> experimental elements of this document. >> >> I think that what this means is that the whole document is an >> experimental "mechanism for doing so". If so, I think it could be >> better phrased >> >> This document is an experimental mechanism for doing so. >> >> -- >> >> 3.4. Section 6.6.1. Extract Author Domain >> >> [...] when the domain name extracted by the receiver (from the >> RFC5322.From) is on the public suffix list used by the receiver. >> >> This touches the question above about what a public suffix list is, >> and how there can be more than one of them. But without that >> knowledge, it's hard to see which PSL is "used" by the receiver of the >> message. >> >> Also, it's not clear to me how *this* document creates a capability >> which applies to domains that are on the PSL. E.g., if an "np" is >> defined for ".org", it applies to (that is, affects processing of >> e-mail from) any "X.org" that doesn't have its own DMARC records. But >> I don't see how an "np" tag for ".org" affects processing of messages >> from "example@org". >> >> 3.5. Section 6.6.3. Policy Discovery >> >> (discussed in the experiment description >> (Appendix A)) >> >> Given that this text is nominally an update to the text of RFC 7489, >> you want to disambiguate the binding of "Appendix A": >> >> (discussed in the experiment description >> ([this document] Appendix A)) >> >> 3.6. Section 7. DMARC Feedback >> >> See Section 4 of this document for discussion of Privacy >> Considerations. >> >> Similarly to section 3.5, but also clarifying the scope of "privacy >> considerations": >> >> See Section 4 of [this document] for discussion of Privacy >> Considerations for PSD DMARC. >> >> 4. Privacy Considerations >> >> The Privacy Considerations of [RFC7489] apply to this document. >> >> This could be clarified as >> >> Additionally, the Privacy Considerations of [RFC7489] apply to the >> mechanisms described by this document. >> >> -- >> >> Providing feedback reporting to PSOs can, in some cases, create >> leakage of information outside of an organization to the PSO. >> >> "outside" probably isn't the word you want to use here, as it is >> easier to read "outside" as giving the original location of >> "information" than to read "outside" as giving the direction of >> "leakage". Perhaps >> >> Providing feedback reporting to PSOs can, in some cases, create >> leakage of information out of an organization to the PSO of its >> domain name. >> >> -- >> >> To minimize this potential concern, >> PSD DMARC feedback is best limited to Aggregate Reports. [...] >> >> [...] any Feedback Reporting related to multi- >> organizational PSDs ought to be limited to non-existent domains >> except in cases where the reporter knows that PSO requires use of >> DMARC. >> >> I can't see where in the document that these principles are turned >> into MUST statements that ensure the privacy issues are solved. >> >> The experiment is to evaluate different possible approaches. >> >> Calling this an "experiment" suggests that these is an intended series >> of actions whose result will answer the listed questions. But there >> doesn't seem to be any such actions listed. The description makes it >> sound like what is intended is continuing discussions in the working >> group, but that wouldn't be an "experiment". >> >> A.2. Non-Existent Subdomain Policy >> >> Similar questions arise for this section. The second paragraph >> suggests that the experiment is to see whether the "np" tag is >> successful. >> >> There are also >> suggestions that it would be more generally useful for DMARC. >> >> What does "it" refer to? (Does it mean "this ability"?) >> >> Appendix B. DMARC PSD Registry Examples >> >> In this appendix, it appears that the contents of the experiment are >> clear in the authors' minds, but there is no summary at the top that >> states what the experimental facilities are and the "big picture" into >> which they fit. >> >> Appendix C. Implementations >> >> C.1. Authheaders Module >> >> What e-mail MTA is Authheaders an extension for? >> >> [END] >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > Todd Herr > --0000000000006376a405a2e190b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Reducing Ccs)

That seems like it paints a much cle= arer picture, which is what Dale was after.=C2=A0 A great start!
<= br>
On Thu,= Apr 9, 2020 at 12:54 PM Todd Herr <toddmherr@gmail.com> wrote:
Having re= viewed the comments, I'm wondering if perhaps the following draft rewri= te of the Abstract section might be a first step to address many of the poi= nts raised?

=

Abstract

DMARC (Domain-based Message A= uthentication, Reporting, and Conformance) is a scalable mechanism by which= a mail-originating organization can express domain-level policies and pref= erences for message validation, disposition, and reporting, that a mail-rec= eiving organization can use to improve mail handling.=C2=A0=C2=A0

The original = design of DMARC applies only to domains that are registered with a domain n= ame registrar (called =E2=80=9COrganizational Domains=E2=80=9D in RFC 7489)= and nodes in the tree below Organizational Domains. Organizational Domains= are themselves nodes in the tree below domain names reserved for registrat= ion, with the latter commonly referred to as =E2=80=9CTop Level Domains=E2= =80=9D (TLDs) (e.g., =E2=80=98.com=E2=80=99, =E2=80=98.co.uk=E2=80=99, etc.), although in this document= they will be referred to as Public Suffix Domains (PSDs).


Since its deployment= in 2015, use of DMARC has shown a clear need for the ability to express po= licy for PSDs. This document describes an extension to DMARC to enable DMAR= C functionality for PSDs.


RFC 7489 describes an algorithm for a mail-receiving = organization to use in determining the Organizational Domain of an inbound = mail message, and this algorithm recommends the use of a =E2=80=9Cpublic su= ffix list=E2=80=9D (PSL), with the most common one maintained by the Mozill= a Foundation and made public at <http://publicsuffix.org/>. Use of such a PSL by = a mail-receiving organization will be required in order to discover and app= ly any DMARC policy declared by a PSD.


This document also seeks to address imp= lementations that consider a domain on a public Suffix list to be ineligibl= e for DMARC



On Sun, Apr 5, 2020 at 9:1= 1 PM Dale Worley via Datatracker <noreply@ietf.org> wrote:
Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.=C2=A0 The General Area Review Team (Gen-ART) reviews all IETF documents being processed by
the IESG for the IETF Chair.=C2=A0 Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document:=C2=A0 review-draft-ietf-dmarc-psd-08
Reviewer:=C2=A0 Dale R. Worley
Review Date:=C2=A0 2020-04-05
IETF LC End Date:=C2=A0 2020-04-08
IESG Telechat date:=C2=A0 not known

* Summary:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This draft is on the right track but has open is= sues, described
=C2=A0 =C2=A0 =C2=A0 =C2=A0in the review.

* Major issues:

The privacy concerns described in section 4 are written as if there is
no certainty that the mechanisms described in the document properly
mitigate them.=C2=A0 So the document appears to be incomplete.=C2=A0 OTOH, = since
this is an Experimental RFC, such mitigation isn't necessary if there is commitment to do so later.=C2=A0 In that case, the section should
explicitly state that these are open issues and that there is an
intention of revising the document to mitigate them.

The text suggests that a mail receiver(?) that does DMARC processing
has knowledge of all PSDs.=C2=A0 This seems a priori unlikely and even
impossible to implement.=C2=A0 So this ought to be either explained at the<= br> appropriate place or resolved technically.

* Minor issues:

The document has the (common) editorial problem that it is written by
people who are deeply familiar with the subject, and it's difficult to<= br> read if one doesn't share that familiarity.=C2=A0 This is particularly<= br> significant because DMARC is an e-mail facility that (ideally) will
affect all e-mail that is sent, so the target audience really should
be anyone who has a basic understanding of e-mail.=C2=A0 Three particular elements of this are:

- It would be very helpful if the Introduction could state, in a few
=C2=A0 sentences, the purpose and operation of DMARC, thus informing the =C2=A0 reader of the framework whose deficiencies this document attempts to=
=C2=A0 address.=C2=A0 In particular, one shouldn't have to read the DMA= RC RFCs
=C2=A0 to be able to read this document and understand its general import.<= br>
- The "experiment" appendixes are unclear about what the experime= nts
=C2=A0 actually are:=C2=A0 what questions they are to answer, what actions = will
=C2=A0 be taken, how the results will be evaluated.=C2=A0 Starting each app= endix
=C2=A0 with an overview paragraph would be helpful.

- Forward references should be minimized so that a reader can
=C2=A0 understand the document in one pass.

As a derivative of the first of these elements, the terminology used
for the properties of domain names is not clearly defined.=C2=A0 In
particular, where does a registration "occur"?=C2=A0 The only ter= m for
which I think the general audience possesses an unambiguous definition
is "the registered domain name", e.g. ietf.org.=C2=A0 Now I *think* its= PSD
is ".org", but it might be "ietf.org", and I don't know = whether the
registration of ietf.org "occurs" at ietf.org or .org.=C2=A0 Further points I didn't understand are pointed out in the review of the
Abstract and Introduction.

* Nits/editorial comments:

Abstract

I'm having quite a bit of difficulty figuring out exactly what the
Abstract means.=C2=A0 I'm sure that the working group clearly understan= ds
what is meant, but the writing is just loose enough that I can't fix the meaning.=C2=A0 To raise the immediate questions:

=C2=A0 =C2=A0DMARC (Domain-based Message Authentication, Reporting, and
=C2=A0 =C2=A0Conformance) is a scalable mechanism by which a mail-originati= ng
=C2=A0 =C2=A0organization can express domain-level policies and preferences= for
=C2=A0 =C2=A0message validation, disposition, and reporting, that a mail-re= ceiving
=C2=A0 =C2=A0organization can use to improve mail handling.

This sentence is quite good, as it introduces what DMARC is all about.

=C2=A0 =C2=A0The design of DMARC
=C2=A0 =C2=A0presumes that domain names represent either nodes in the tree = below
=C2=A0 =C2=A0which registrations occur, or nodes where registrations have =C2=A0 =C2=A0occurred; it does not permit a domain name to have both of the= se
=C2=A0 =C2=A0properties simultaneously.

You want to make clear here that "registration" means "domai= n name
ownership registration" (which is what section 2.2 says).=C2=A0 Otherw= ise
it leaves open that there is some sort of DMARC registration that you
might intend, until the reader gets to section 2.2.

There's an ambiguity regarding "where" a registration happens= .=C2=A0 E.g.,
does the registration of "ietf.org" "occur at" "ietf.org"= ; or "occur
at" "org"?=C2=A0 It's possible that this could be simpli= fied/disambiguated
by not using this term, but instead phrasing this in terms of domain
names that "are registered", and the allowed relationships betwee= n
them.

And it appears certain that there are DNS nodes where registrations
are only done *above* that node, e.g. "datatracker.ietf.org"= ;, which
this sentence (if taken literally) says is not permitted by DMARC.=C2=A0 Is=
the property you want to declare "one node where registrations are
done cannot exist below another node where registrations are done"?
Or perhaps domain names like "datatracker.ietf.org" are of = no interest
to DMARC because DMARC is never applied to messages for which that is
the relevant address?

=C2=A0 =C2=A0Since its deployment in 2015, use of
=C2=A0 =C2=A0DMARC has shown a clear need for the ability to express policy= for
=C2=A0 =C2=A0these domains as well.

This sentence doesn't make it clear what "these domains" refe= rs to.

=C2=A0 =C2=A0Domains at which registrations can occur are referred to as Pu= blic
=C2=A0 =C2=A0Suffix Domains (PSDs).=C2=A0 This document describes an extens= ion to DMARC
=C2=A0 =C2=A0to enable DMARC functionality for PSDs.

It would probably be clearer to use "domain name ownership
registrations" again here.

This sentence suggests that the registration of "ietf.org" "occurs= at"
"org" and so "org" is a PSD.

=C2=A0 =C2=A0This document also seeks to address implementations that consi= der a
=C2=A0 =C2=A0domain on a public Suffix list to be ineligible for DMARC
=C2=A0 =C2=A0enforcement.

This suggests that implementations believe that they know of all PSDs,
so they can "consider them ineligible for DMARC enforcement".=C2= =A0 But
it's hard to imagine that that they can know that they know of all
PSDs.

An additional point, and I'm not sure how valuable this is, would be to clarify "I'm holding an e-mail message in my hands.=C2=A0 What = do I do
next?", that is, What address in the message is the domain whose DMARC=
information is applied to the message?=C2=A0 And what indeed does DMARC
processing do to a message?=C2=A0 For most of the sentences of the
Abstract, this is not important, but it leaves the effect of the last
sentence unclear, as "DMARC is not enforced on messages whose *sender*=
is in a PSD" is quite a bit different from "DMARC is not enforced= on
messages whose *recipient* is in a PSD".=C2=A0 (Section 3.3 suggests t= hat
the address in the From header of the message is the one that is used
for DMARC processing.)

It's unclear what exactly is the contents of a "public suffix list= ".
Naively, it appears that it is the list of domain names under which
names can be registered, but the text uses the term in the plural, so
there must be some additional structure.

Also, it seems there are some significant privacy matters addressed by
this document, and it's probably worth adding a sentence to notify the<= br> reader of that.

1.=C2=A0 Introduction

A number of the questions about the Abstract apply to the Introduction
as well.=C2=A0 But generally, since e-mail is a subject that every reader has a basic knowledge of, it would be useful to write the introduction
so that one did not have to have a knowledge of the DMARC architecture
to understand the introduction.

=C2=A0 =C2=A0"gov.example" publishes the following DMARC record:<= br>
=C2=A0 =C2=A0"v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmarc.service.gov.e= xample"

=C2=A0 =C2=A0at

=C2=A0 =C2=A0_dmarc.gov.example.

Even better would be this aid to people who don't already know DMARC implementation:

=C2=A0 =C2=A0"gov.example" publishes the following DMARC DNS reco= rd:

=C2=A0 =C2=A0_dmarc.gov.example.=C2=A0 TXT \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "v=3DDMARC1; p=3Dreject; rua=3Dmailto:dmarc@dmar= c.service.gov.example"

--

=C2=A0 =C2=A0the non-existent organizational domain of @tax.gov.example

I suspect you mean "t4x.gov.example" here.

=C2=A0 =C2=A0This document provides a simple extension to DMARC [RFC7489] t= o
=C2=A0 =C2=A0allow [...]

This sentence lists 4 important items, each of which is fairly long,
which together are the summary of the whole document, so it might be
useful to break this into a bullet-list.

2.=C2=A0 Terminology and Definitions

=C2=A0 =C2=A0In many cases the public portion of the DNS tree is [...]

What does "the public portion" mean?=C2=A0 I'm guessing it me= ans "the names
not available for private registration", but you should be unambiguous=
here.

=C2=A0 =C2=A0They are not available for private
=C2=A0 =C2=A0registration.=C2=A0 In many cases the public portion of the DN= S tree is
=C2=A0 =C2=A0more than one level deep.

It seems like these two sentences are redundant and the flow of the
paragraph would be better if they were removed. ... Actually once they
are removed, it reveals that the next two sentences largely duplicate
the first two sentences of the paragraph.

=C2=A0 =C2=A02.3.=C2=A0 Longest PSD

=C2=A0 =C2=A0The longest PSD is the Organizational Domain with one label re= moved.

=C2=A0 =C2=A02.4.=C2=A0 Organizational Domain

=C2=A0 =C2=A0The term Organizational Domains is defined in DMARC [RFC7489]<= br> =C2=A0 =C2=A0Section 3.2.

2.4 should be moved ahead of 2.3 to avoid a forward-reference.=C2=A0 But it=
would be really helpful if the definition of Organizational Domain was
either summarized here or completely copied from RFC7489.=C2=A0 In
particular, if Organizational Domain is not the same as registered
domain name, that should be flagged.

=C2=A0 =C2=A02.5.=C2=A0 Public Suffix Operator (PSO)

=C2=A0 =C2=A0A Public Suffix Operator manages operations within its PSD.
Better to explicitly define the possession relationship explicitly:

=C2=A0 =C2=A0A Public Suffix Operator is an organization which manages
=C2=A0 =C2=A0operations within a PSD, particularly the DNS records publishe= d for
=C2=A0 =C2=A0names at and under that domain name.

--

=C2=A0 =C2=A02.6.=C2=A0 PSO Controlled Domain Names

=C2=A0 =C2=A0PSO Controlled Domain Names are names in the DNS that are mana= ged by
=C2=A0 =C2=A0a PSO and are not available for use as Organizational Domains.=
=C2=A0 =C2=A0Depending on PSD policy, these will have one (e.g., ".com= ") or more
=C2=A0 =C2=A0(e.g., ".co.uk") name components.

The second sentence is odd; is it useful?=C2=A0 Is it just to say "PSO=
Controlled Domain Names may have one or more components."?

=C2=A0 =C2=A03.1.=C2=A0 General Updates

=C2=A0 =C2=A0References to "Domain Owners" also apply to PSOs.
This change really ought to be localized to a specific textual change
somewhere in RFC 7489, in the say way that the other changes are
specific amendments to the DMARC algorithm.

=C2=A0 =C2=A03.2.=C2=A0 Section 6.3 General Record Format

These section titles are difficult to read.=C2=A0 At first I thought there<= br> was some typographical problem.=C2=A0 But you could clarify this as "3= .2.
Updates to Section 6.3.=C2=A0 General Record Format".=C2=A0 Similarly = for the
other subsections of section 3.

3.3.=C2=A0 Section 6.5.=C2=A0 Domain Owner Actions

=C2=A0 =C2=A0The mechanism for doing so is one of the
=C2=A0 =C2=A0experimental elements of this document.

I think that what this means is that the whole document is an
experimental "mechanism for doing so".=C2=A0 If so, I think it co= uld be
better phrased

=C2=A0 =C2=A0This document is an experimental mechanism for doing so.

--

=C2=A0 =C2=A03.4.=C2=A0 Section 6.6.1.=C2=A0 Extract Author Domain

=C2=A0 =C2=A0[...] when the domain name extracted by the receiver (from the=
=C2=A0 =C2=A0RFC5322.From) is on the public suffix list used by the receive= r.

This touches the question above about what a public suffix list is,
and how there can be more than one of them.=C2=A0 But without that
knowledge, it's hard to see which PSL is "used" by the receiv= er of the
message.

Also, it's not clear to me how *this* document creates a capability
which applies to domains that are on the PSL.=C2=A0 E.g., if an "np&qu= ot; is
defined for ".org", it applies to (that is, affects processing of=
e-mail from) any "X.org" that doesn't have its own DMARC reco= rds.=C2=A0 But
I don't see how an "np" tag for ".org" affects proc= essing of messages
from "example@org".

=C2=A0 =C2=A03.5.=C2=A0 Section 6.6.3.=C2=A0 Policy Discovery

=C2=A0 =C2=A0 =C2=A0 (discussed in the experiment description
=C2=A0 =C2=A0 =C2=A0 (Appendix A))

Given that this text is nominally an update to the text of RFC 7489,
you want to disambiguate the binding of "Appendix A":

=C2=A0 =C2=A0 =C2=A0 (discussed in the experiment description
=C2=A0 =C2=A0 =C2=A0 ([this document] Appendix A))

=C2=A0 =C2=A03.6.=C2=A0 Section 7.=C2=A0 DMARC Feedback

=C2=A0 =C2=A0See Section 4 of this document for discussion of Privacy
=C2=A0 =C2=A0Considerations.

Similarly to section 3.5, but also clarifying the scope of "privacy considerations":

=C2=A0 =C2=A0See Section 4 of [this document] for discussion of Privacy
=C2=A0 =C2=A0Considerations for PSD DMARC.

=C2=A0 =C2=A04.=C2=A0 Privacy Considerations

=C2=A0 =C2=A0The Privacy Considerations of [RFC7489] apply to this document= .

This could be clarified as

=C2=A0 =C2=A0Additionally, the Privacy Considerations of [RFC7489] apply to= the
=C2=A0 =C2=A0mechanisms described by this document.

--

=C2=A0 =C2=A0Providing feedback reporting to PSOs can, in some cases, creat= e
=C2=A0 =C2=A0leakage of information outside of an organization to the PSO.<= br>
"outside" probably isn't the word you want to use here, as it= is
easier to read "outside" as giving the original location of
"information" than to read "outside" as giving the dire= ction of
"leakage".=C2=A0 Perhaps

=C2=A0 =C2=A0Providing feedback reporting to PSOs can, in some cases, creat= e
=C2=A0 =C2=A0leakage of information out of an organization to the PSO of it= s
=C2=A0 =C2=A0domain name.

--

=C2=A0 =C2=A0To minimize this potential concern,
=C2=A0 =C2=A0PSD DMARC feedback is best limited to Aggregate Reports.=C2=A0= [...]

=C2=A0 =C2=A0[...] any Feedback Reporting related to multi-
=C2=A0 =C2=A0organizational PSDs ought to be limited to non-existent domain= s
=C2=A0 =C2=A0except in cases where the reporter knows that PSO requires use= of
=C2=A0 =C2=A0DMARC.

I can't see where in the document that these principles are turned
into MUST statements that ensure the privacy issues are solved.

=C2=A0 =C2=A0The experiment is to evaluate different possible approaches.
Calling this an "experiment" suggests that these is an intended s= eries
of actions whose result will answer the listed questions.=C2=A0 But there doesn't seem to be any such actions listed.=C2=A0 The description makes= it
sound like what is intended is continuing discussions in the working
group, but that wouldn't be an "experiment".

A.2.=C2=A0 Non-Existent Subdomain Policy

Similar questions arise for this section.=C2=A0 The second paragraph
suggests that the experiment is to see whether the "np" tag is successful.

=C2=A0 =C2=A0There are also
=C2=A0 =C2=A0suggestions that it would be more generally useful for DMARC.<= br>
What does "it" refer to?=C2=A0 (Does it mean "this ability&q= uot;?)

Appendix B.=C2=A0 DMARC PSD Registry Examples

In this appendix, it appears that the contents of the experiment are
clear in the authors' minds, but there is no summary at the top that states what the experimental facilities are and the "big picture"= into
which they fit.

Appendix C.=C2=A0 Implementations

=C2=A0 =C2=A0C.1.=C2=A0 Authheaders Module

What e-mail MTA is Authheaders an extension for?

[END]



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


--
Todd Herr
<= /div>
--0000000000006376a405a2e190b6-- From nobody Thu Apr 9 14:04: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 C92133A0E83 for ; Thu, 9 Apr 2020 14:04:39 -0700 (PDT) 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=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 lKE2wL5-1tqb for ; Thu, 9 Apr 2020 14:04:37 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3A83A0E7E for ; Thu, 9 Apr 2020 14:04:37 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id p13so106446ilp.3 for ; Thu, 09 Apr 2020 14:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HfODZfzH1vNOUq2d9Z5QHP7U5mvYvCmSDvHLGdv9XkY=; b=BPnGceJhMBKq/eB5QJWpFtleGriLjqE9oweXREbr9C1V5qXqG8cfmV49gUhC+kV4IG VwHWlzVhM1LxNSJFpJn87JeqSjHS3QAglUrwNxNItE3fwRJsnVY+hd3CRF1IwFyrTRaF 8Ho6W/wU39gVFXbrYo5P9L85DJCv7BEYvmzjU= 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=HfODZfzH1vNOUq2d9Z5QHP7U5mvYvCmSDvHLGdv9XkY=; b=CQHMaQDCY5us93hNn2PpSVc3UvT8CaiO/h8FBiaEHzou8C79nXo13Nj/Z5PugzCARh M2qAsNWeAvfTzJC9SStnz+vFK5ZacVn+Puh5qs8f6f/7KgXGEHJeCJyECTDhbKHgYh1u e5woHGo4xsmF7oaBNZxkO74MLhaGEieWDJ/514y+BX/KOtZ5pBXAptyGY4IYLYbk3yn5 WbEthSzgcdNMwla6kdTfV2Z6Dkg5G5+r6lOFdHKFpPd/U0ycJGAjxoQdCHcjHwjdDRhb uyMdy0uISCsgvzGgFzhOkYfWRZFAwQJHFRmUG42udzKpBJgk7E9gbnH+FWbOJyC2yYOk oipQ== X-Gm-Message-State: AGi0Puar98c0OiS8y9Rl7/0gmep9lJEDx35FmtNqcWhWWWLZQZqU9xKi XRt/m3C45DzgKbwFCGweLiZEgZgKsS8QZSivckUTSA== X-Google-Smtp-Source: APiQypLj2xK2esJYg6UaJMRA7nJP6/oZzbaLFdd7XnS1k9H8VSUGmj8kZSYXpFXf8HRT2qMNQwj53NuEwqzK1z2GKdw= X-Received: by 2002:a92:db04:: with SMTP id b4mr1813287iln.120.1586466277029; Thu, 09 Apr 2020 14:04:37 -0700 (PDT) MIME-Version: 1.0 References: <158613543159.15216.5517593808552135017@ietfa.amsl.com> In-Reply-To: From: "Kurt Andersen (b)" Date: Thu, 9 Apr 2020 14:04:22 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Todd Herr , dmarc , General Area Review Team , Dale Worley Content-Type: multipart/alternative; boundary="000000000000e41ee005a2e1f607" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 09 Apr 2020 21:04:40 -0000 --000000000000e41ee005a2e1f607 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 9, 2020 at 1:36 PM Murray S. Kucherawy wrote: > > That seems like it paints a much clearer picture, which is what Dale was > after. A great start! > > On Thu, Apr 9, 2020 at 12:54 PM Todd Herr wrote: > >> Having reviewed the comments, I'm wondering if perhaps the following >> draft rewrite of the Abstract section might be a first step to address m= any >> of the points raised? >> >> *AbstractDMARC (Domain-based Message Authentication, Reporting, and >> Conformance) is a scalable mechanism by which a mail-originating >> organization can express domain-level policies and preferences for messa= ge >> validation, disposition, and reporting, that a mail-receiving organizati= on >> can use to improve mail handling. * >> >> *The original design of DMARC applies only to domains that are registere= d >> with a domain name registrar (called =E2=80=9COrganizational Domains=E2= =80=9D in RFC 7489) >> and nodes in the tree below Organizational Domains. Organizational Domai= ns >> are themselves nodes in the tree below domain names reserved for >> registration, with the latter commonly referred to as =E2=80=9CTop Level= Domains=E2=80=9D >> (TLDs) (e.g., =E2=80=98.com=E2=80=99, =E2=80=98.co.uk =E2= =80=99, etc.), although in this >> document they will be referred to as Public Suffix Domains (PSDs).* >> >> *Since its deployment in 2015, use of DMARC has shown a clear need for >> the ability to express policy for PSDs. This document describes an >> extension to DMARC to enable DMARC functionality for PSDs.* >> >> *RFC 7489 describes an algorithm for a mail-receiving organization to us= e >> in determining the Organizational Domain of an inbound mail message, and >> this algorithm recommends the use of a =E2=80=9Cpublic suffix list=E2=80= =9D (PSL), with the >> most common one maintained by the Mozilla Foundation and made public at >> >. Use of such a PSL= by >> a mail-receiving organization will be required in order to discover and >> apply any DMARC policy declared by a PSD.* >> >> *This document also seeks to address implementations that consider a >> domain on a public Suffix list to be ineligible for DMARC* >> > I have two concerns with the proposed abstract: 1. ".co.uk" is not a TLD. TLDs are single label domains - there are ccTLDs and gTLDs. 2. The invocation of the PSL compounds the issue that was raised by Dave Crocker. How DMARC (RFC 7489) determines the organizational domain is orthogonal to this proposal which simply calls for a conditional additio= nal check at the "org - 1" level. I recommend striking the penultimate paragraph in the proposal. --Kurt --000000000000e41ee005a2e1f607 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 9, 2020 at 1:36 PM Murray S. Kucherawy <superuser@gmail.com> wrote:

That seem= s like it paints a much clearer picture, which is what Dale was after.=C2= =A0 A great start!

On Thu, Apr 9, 2020 at 12:54 PM Todd Herr <toddmherr@gmail.com&g= t; wrote:
Having reviewed the comments, I'm wondering if perhaps th= e following draft rewrite of the Abstract section might be a first step to = address many of the points raised?

Abstract

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-family:Arial;color:rgb(0,0,0);background-color:transpare= nt;font-weight:400;font-style:normal;font-variant:normal;text-decoration:no= ne;vertical-align:baseline;white-space:pre-wrap">DMARC (Domain-based Messag= e Authentication, Reporting, and Conformance) is a scalable mechanism by wh= ich a mail-originating organization can express domain-level policies and p= references for message validation, disposition, and reporting, that a mail-= receiving organization can use to improve mail handling.=C2=A0=C2=A0=


The original design of DMARC applies only to domains that= are registered with a domain name registrar (called =E2=80=9COrganizationa= l Domains=E2=80=9D in RFC 7489) and nodes in the tree below Organizational = Domains. Organizational Domains are themselves nodes in the tree below doma= in names reserved for registration, with the latter commonly referred to as= =E2=80=9CTop Level Domains=E2=80=9D (TLDs) (e.g., =E2=80=98.com=E2=80=99, = =E2=80=98.co.uk=E2=80=99, e= tc.), although in this document they will be referred to as Public Suffix D= omains (PSDs).


Since its deployment in 2015, use of= DMARC has shown a clear need for the ability to express policy for PSDs. T= his document describes an extension to DMARC to enable DMARC functionality = for PSDs.


RFC 7489 describes an algorithm for a mai= l-receiving organization to use in determining the Organizational Domain of= an inbound mail message, and this algorithm recommends the use of a =E2=80= =9Cpublic suffix list=E2=80=9D (PSL), with the most common one maintained b= y the Mozilla Foundation and made public at <http://publicsuffix.org/<= /span>>. Use of su= ch a PSL by a mail-receiving organization will be required in order to disc= over and apply any DMARC policy declared by a PSD.

= This document also seeks to address implementations that consider a domain = on a public Suffix list to be ineligible for DMARC


I have two concerns with the proposed abstract:
  1. "= ;.co.uk" is not a TLD. TLDs are single la= bel domains - there are ccTLDs and gTLDs.
  2. The invocation of the PSL= compounds the issue that was raised by Dave Crocker. How DMARC (RFC 7489) = determines the organizational domain is orthogonal to this proposal which s= imply calls for a conditional additional check at the "org - 1" l= evel. I recommend striking the penultimate paragraph in the proposal.
    3. <= /ol>
--Kurt=C2=A0
--000000000000e41ee005a2e1f607-- From nobody Thu Apr 9 16:09: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 036333A12CA for ; Thu, 9 Apr 2020 16:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=W/pdj5K5; dkim=pass (1536-bit key) header.d=taugh.com header.b=JpetNRHz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGDB5tfxoFSN for ; Thu, 9 Apr 2020 16:09:35 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEE23A12C9 for ; Thu, 9 Apr 2020 16:09:35 -0700 (PDT) Received: (qmail 3492 invoked from network); 9 Apr 2020 23:09:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d9f.5e8fab2e.k2004; bh=F8ar9fiXFLqQgWz3BLVeWiECivOFp9OqRCCudjVXsL4=; b=W/pdj5K56eDI7xb8lclXOOB/EInseLqUa2Ss2B6pLyLw/TCw6c/AbjVPsMU4lO1hE7ztdmS+qN/CThbFmd/y5aEMFyiAbq5lbtfN+jAN+27AGx6aNxT7tg9cbjJ05q6mSF10eDsI1Gzyzd5se7zsRlleP1EucwYhBRy0tRAMXN4R/J3o55x3eUqgIfr89yG05/g65hlHUjAWBcDIGVOby1lIWj5sTsW+Z51zzhGVlkA1dDkUSxQ0egLSgXadGpmh DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=d9f.5e8fab2e.k2004; bh=F8ar9fiXFLqQgWz3BLVeWiECivOFp9OqRCCudjVXsL4=; b=JpetNRHznp358XLVwpfauwenGJ03S1eF9DB6zP9JILT6kT8chpgZZpnJwGO5OgzZJXoQvX1ym4+0mDVaRn0g0jhx0JfI8sL1+vH5JUS+mLzJ/W1Q3E2o0xa1PfhKDSY6LOViRhUqAaB98/dZEoRVx3CBsmNIsegnP4sHS+cC7fbbn2AfuFiedMfkt+/eqGa4rhUver6Q1ZaPZNIH7wbYVVZhuZQ5QCzo9+fCAqeAcIa7GgTaXGWxgGjZ8WpN/BaX Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 09 Apr 2020 23:09:33 -0000 Received: by ary.qy (Postfix, from userid 501) id E0CBD17638B4; Thu, 9 Apr 2020 19:09:33 -0400 (EDT) Date: 9 Apr 2020 19:09:33 -0400 Message-Id: <20200409230933.E0CBD17638B4@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: kboth@drkurt.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 09 Apr 2020 23:09:37 -0000 In article you write: > 1. ".co.uk" is not a TLD. TLDs are single label domains - there are > ccTLDs and gTLDs. Right. > 2. The invocation of the PSL compounds the issue that was raised by Dave > Crocker. How DMARC (RFC 7489) determines the organizational domain is > orthogonal to this proposal which simply calls for a conditional additional > check at the "org - 1" level. I recommend striking the penultimate > paragraph in the proposal. I'd suggest weasel wording it to say that the domain above an org domain is often known as a public suffix domain, which typically delegates the org domains below it to a unrelated parties. This spec allows public suffix domains to publish policies to supplant those of their child org domains ... I agree we should stay as far from mentioning the PSL and its specific implementation as possible. Who knows, someday people might get around to trying my dbound in DNS implementation instead. R's, John From nobody Fri Apr 10 06:39: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 329D93A0B13 for ; Fri, 10 Apr 2020 06:38:56 -0700 (PDT) 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 C2Qwweqx0Log for ; Fri, 10 Apr 2020 06:38:53 -0700 (PDT) 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 BB9C33A0AEE for ; Fri, 10 Apr 2020 06:38:52 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id b5so1333546vsb.1 for ; Fri, 10 Apr 2020 06:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LzRGr+mhMwkD0/LI/ZXPRixza9rQ5Klu6Th50UCUSkI=; b=TDgE/iXGJr1b1MkX74B6CpCf++MNeGOnjuPVqyxa61C7cKHNMsT0GozKAJQIDKP8kh 2FatB+U70gRjyqF3jkyxZQ+/KY7q3w/7HRzoevqdcp47sZTUKvU0OVqWQHedfMjo068C ok562CEouMWs5dNgPlTf7wfFaD/JtDKreYjNWnbMvFwrfh8fXjcqNrF8ClsHpD4KIFhH gn6N67zVhGLkOb5kk9zeDYSaxY5KybOea1a53tNcN1/nuLx72Tbce7DrQ2E9U+/h3plA nG/InQp8SP+Xy9u7L++rpt63dfdzP1jcw1KXWi2I/TX4vhbig77Hq24c56PDbu+l/rgg rzGQ== 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=LzRGr+mhMwkD0/LI/ZXPRixza9rQ5Klu6Th50UCUSkI=; b=X092EAw80keo1O6jqxY6WCY05pc6wFle0b95g+H9+GDwJOHbwpTfgIvXB3ARdnG+U/ z5MjaYx7VgoagnMDLKVQv2FX0vlkXJ/YLQpQUCyVl+z3AxoLsU6Zq3AcdxArI+A4DGgD Cd+oMsyanRV6aHFZh8EUtRdIyVqn4ARxxu8RSaHEHUZVW8188wMRlwwjgffqAD3AQc4h RMB+c1h+/WnrrP4MXzhM7voOC7wX1wqZuSTeRPk2aIGHw41e3EhlDqFSWo9UkHCnLFho TUAM55G+dvg+wczdj1IYT7UUnEsVY1hcpz22tUuhXZO70CqGY1BWyvQKZD1eqCtCFZym UPYA== X-Gm-Message-State: AGi0PuYhWH98NtaPeG6gyObH9Mk6bRcWGIITgRyQnWSAFdf9WHSifsE/ urXIwkyLhZfBWtqi+dRz6cJk55qf4ypNVWN9diSfiQcOP4o= X-Google-Smtp-Source: APiQypJxE+UafMNAe/w1h4aInHYCTyPAh3byRsv2TXvX81SNkhTrxWS02UEd6D+tss9rRkF8us5WbksUUS8lq1OSae8= X-Received: by 2002:a05:6102:1043:: with SMTP id h3mr2203325vsq.39.1586525931527; Fri, 10 Apr 2020 06:38:51 -0700 (PDT) MIME-Version: 1.0 References: <20200409230933.E0CBD17638B4@ary.qy> In-Reply-To: <20200409230933.E0CBD17638B4@ary.qy> From: Todd Herr Date: Fri, 10 Apr 2020 09:38:40 -0400 Message-ID: To: John Levine Cc: dmarc , kboth@drkurt.com Content-Type: multipart/alternative; boundary="0000000000009363fa05a2efdaa1" Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 13:39:02 -0000 --0000000000009363fa05a2efdaa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 9, 2020 at 7:09 PM John Levine wrote: > In article a7a_Sx7aMhBQ@mail.gmail.com> you write: > > 1. ".co.uk" is not a TLD. TLDs are single label domains - there are > > ccTLDs and gTLDs. > > Right. > I don't disagree, but what I was going for here was some level of consistency with section 3.2 of RFC 7489, which reads in part: 1. Acquire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list. The point of the paragraph in question wasn't to define TLDs (or PSDs) but rather to better define "domain names reserved for registration". > > > 2. The invocation of the PSL compounds the issue that was raised by > Dave > > Crocker. How DMARC (RFC 7489) determines the organizational domain is > > orthogonal to this proposal which simply calls for a conditional > additional > > check at the "org - 1" level. I recommend striking the penultimate > > paragraph in the proposal. > > I'd suggest weasel wording it to say that the domain above an org > domain is often known as a public suffix domain, which typically > delegates the org domains below it to a unrelated parties. This spec > allows public suffix domains to publish policies to supplant those of > their child org domains ... > > I agree we should stay as far from mentioning the PSL and its specific > implementation as possible. Who knows, someday people might get > around to trying my dbound in DNS implementation instead. > Dale twice in his comments expresses doubt that it's possible for anyone to know all PSDs; the mention of a specific PSL in the abstract was an attempt to answer those doubts. The second paragraph could be rewritten as *The original design of DMARC applies only to domains that are registered with a domain name registrar (called =E2=80=9COrganizational Domains=E2=80= =9D in RFC 7489) and nodes in the tree below Organizational Domains. Organizational Domains are themselves nodes in the tree below domain names reserved for registration, the latter of which will be referred to as Public Suffix Domains (PSDs) in this document.* But how to address Dale's concerns about how one knows all PSDs? --=20 Todd Herr --0000000000009363fa05a2efdaa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 9, 2020 = at 7:09 PM John Levine <johnl@taugh.c= om> wrote:
In article <CABuGu1rekWo3mRkK_OpRksYNrSmPaF= HD6k1_K=3D= a7a_Sx7aMhBQ@mail.gmail.com> you write:
>=C2=A0 =C2=A01. ".co.uk" is not a TLD. TLDs are single label domains -= there are
>=C2=A0 =C2=A0ccTLDs and gTLDs.

Right.

I don't disagree, = but what I was going for here was some level of consistency with section 3.= 2 of RFC 7489, which reads in part:

1. Acqu= ire a "public suffix" list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under ".co.uk"; other TLDs such as ".com" appear in the IANA registry of top-level DN= S domains. A public suffix list is the union of all of these. Appen= dix A.6.1 contains some discussion about obtaining a public suffix list.

The point of t= he paragraph in question wasn't to define TLDs (or PSDs) but rather to = better define "domain names reserved for registration".
= =C2=A0

>=C2=A0 =C2=A02. The invocation of the PSL compounds the issue that was = raised by Dave
>=C2=A0 =C2=A0Crocker. How DMARC (RFC 7489) determines the organizationa= l domain is
>=C2=A0 =C2=A0orthogonal to this proposal which simply calls for a condi= tional additional
>=C2=A0 =C2=A0check at the "org - 1" level. I recommend striki= ng the penultimate
>=C2=A0 =C2=A0paragraph in the proposal.

I'd suggest weasel wording it to say that the domain above an org
domain is often known as a public suffix domain, which typically
delegates the org domains below it to a unrelated parties.=C2=A0 This spec<= br> allows public suffix domains to publish policies to supplant those of
their child org domains ...

I agree we should stay as far from mentioning the PSL and its specific
implementation as possible.=C2=A0 Who knows, someday people might get
around to trying my dbound in DNS implementation instead.
<= div>
Dale twice in his comments expresses doubt that it's= possible for anyone to know all PSDs; the mention of a specific PSL in the= abstract was an attempt to answer those doubts.

The second paragraph could be rewritten as

The original design of DMARC applies only to domains that are register= ed with a domain name registrar (called =E2=80=9COrganizational Domains=E2= =80=9D in RFC 7489) and nodes in the tree below Organizational Domains. Org= anizational Domains are themselves nodes in the tree below domain names res= erved for registration, the latter of which will be referred to as Public S= uffix Domains (PSDs) in this document.
But how to address Dale's con= cerns about how one knows all PSDs?

--
Todd Herr

--0000000000009363fa05a2efdaa1-- From nobody Fri Apr 10 06:49: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 4FE353A0AE2 for ; Fri, 10 Apr 2020 06:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=NScqng3A; dkim=pass (2048-bit key) header.d=kitterman.com header.b=mplnyRa5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLy38azMoH2N for ; Fri, 10 Apr 2020 06:49:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927AA3A0ADE for ; Fri, 10 Apr 2020 06:49:26 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 212DEF80272 for ; Fri, 10 Apr 2020 09:49:25 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1586526565; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fn347Itap1GS3w/xs8uYRYWcht5QN2umpnc6BBVI2Ao=; b=NScqng3AzfYmxARuGw3AKEZb2crKV1EnLW5aaG6+EeoWP46McW6DuMZHe+nyFr82dOIYb IDuiSSDDlzDrTveAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1586526565; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=fn347Itap1GS3w/xs8uYRYWcht5QN2umpnc6BBVI2Ao=; b=mplnyRa5q2pJ8A2hbIezC80vqrnktuoJVKJCcsDW7bMbfaMO7p8DK1G6kQAKDkOydvg8X ns75KUYa2B8Ebk350vc0mHe4IPeqOTvdkm1Tm0p6oqb3wZ3JVyRidWScOxZ4qMzp5I2oXN3 vrSkmFps3KagQLdy2otQ1/tsT2CuIKZlBvjakjaXpJTghnPR3SV8d0WEKDQYWHH8MrvCk63 CLUUVT/0N87C/909SFr68v2MKIL0mvASRmaXR6BOomw3M0wYIkgOg8UN7gDe2pTQmfGoEdt Q61VmXeuUE3fgWxBHsOMPEkLfZLSynsBsJeCBVu58oJGFtgc7ky6sKWT2e4w== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id E7CF4F801E9 for ; Fri, 10 Apr 2020 09:49:24 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 10 Apr 2020 09:49:24 -0400 Message-ID: <3377169.EuQdDTRyQv@sk-desktop> In-Reply-To: References: <20200409230933.E0CBD17638B4@ary.qy> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 13:49:28 -0000 On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote: > On Thu, Apr 9, 2020 at 7:09 PM John Levine wrote: > > In article >=20 > > a7a_Sx7aMhBQ@mail.gmail.com> you write: > > > 1. ".co.uk" is not a TLD. TLDs are single label domains - there are > > > ccTLDs and gTLDs. > >=20 > > Right. >=20 > I don't disagree, but what I was going for here was some level of > consistency with section 3.2 of RFC 7489, which reads in part: >=20 > 1. Acquire a "public suffix" list, i.e., a list of DNS domain names > reserved for registrations. Some country Top-Level Domains > (TLDs) make specific registration requirements, e.g., the United > Kingdom places company registrations under ".co.uk"; other TLDs > such as ".com" appear in the IANA registry of top-level DNS > domains. A public suffix list is the union of all of these. > Appendix A.6.1 > contains some > discussion about obtaining a public > suffix list. >=20 >=20 > The point of the paragraph in question wasn't to define TLDs (or PSDs) but > rather to better define "domain names reserved for registration". >=20 > > > 2. The invocation of the PSL compounds the issue that was raised by > >=20 > > Dave > >=20 > > > Crocker. How DMARC (RFC 7489) determines the organizational domain = is > > > orthogonal to this proposal which simply calls for a conditional > >=20 > > additional > >=20 > > > check at the "org - 1" level. I recommend striking the penultimate > > > paragraph in the proposal. > >=20 > > I'd suggest weasel wording it to say that the domain above an org > > domain is often known as a public suffix domain, which typically > > delegates the org domains below it to a unrelated parties. This spec > > allows public suffix domains to publish policies to supplant those of > > their child org domains ... > >=20 > > I agree we should stay as far from mentioning the PSL and its specific > > implementation as possible. Who knows, someday people might get > > around to trying my dbound in DNS implementation instead. >=20 > Dale twice in his comments expresses doubt that it's possible for anyone = to > know all PSDs; the mention of a specific PSL in the abstract was an attem= pt > to answer those doubts. >=20 > The second paragraph could be rewritten as >=20 > *The original design of DMARC applies only to domains that are registered > with a domain name registrar (called =E2=80=9COrganizational Domains=E2= =80=9D in RFC 7489) > and nodes in the tree below Organizational Domains. Organizational Domains > are themselves nodes in the tree below domain names reserved for > registration, the latter of which will be referred to as Public Suffix > Domains (PSDs) in this document.* >=20 > But how to address Dale's concerns about how one knows all PSDs? To the extent this is a problem, it's RFC 7489's problem. This document=20 leverages it's existing definitions. That's intentional. While the curren= t=20 RFC 7489 definitions aren't ideal, as an extension to that work, I don't th= ink=20 it make sense to try and fix it here. That's work for 7489bis. Scott K From nobody Fri Apr 10 08:21: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 BA22D3A0825 for ; Fri, 10 Apr 2020 08:21:39 -0700 (PDT) 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 gX83UBSEk_mR for ; Fri, 10 Apr 2020 08:21:38 -0700 (PDT) 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 0A54C3A0822 for ; Fri, 10 Apr 2020 08:21:37 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id i75so2073904ild.13 for ; Fri, 10 Apr 2020 08:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zxVe4HbWa6tSrU7mumBHxS3duPeUdbVCfdrrn+huhjI=; b=XRa1o/sdPI4XRgzKqhpUHbIwS4gQCoP1ZFAMDb6hhhKFGqfR51KQ5YuIQf+ROkv09S 5wFKHE9CRO6hVJYerKT+XL5chISvVSaGnwIO/NvFI5L18M5AgwZ/mxyR6VDllh0M9L6f ekHzaQbs/8SnYv8qlQIZbq0mBBtn3lzi3caIA= 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=zxVe4HbWa6tSrU7mumBHxS3duPeUdbVCfdrrn+huhjI=; b=DC4sCCsP4h8CNEoHtHlIbvloRHYKLxWpZMzFppNDLM28Pb04wffgTFtuBi1Q3RMcdU UUlqoYpYtC+Z0LcALgdSzLFeho2aHtXgSAusW+y+dDVraMS1yWfTGk7fotCNbepkC9SU 67DV/6Js9bPbmmUCDrO5PgTiA2BRlnYrDVOBWYLQ6tSab3r/cEhPlEtziMSrlC6H/9bm Blvrh1eQDLlct4wmNNjaAxnRpFMaFqImOkwaKl3ZzJkItkhzR7WzhJ2Zm1USMq2RjHdm G479hYAQO8bZZOSF4nLypxW49Zfa1L9zq5oWrBopyT0k5ypP9Fq6qs7hjX1zsFU29xDF s/HA== X-Gm-Message-State: AGi0PuaA4j90cO43MNk9ZDu9z0xroqYStbEEgrmgWAdcoLvUxzJB5jHx yWgYi/ZkAvsfccyCHVRpuK1IcIZS4Cav7AgZ5t7gyrvG+XE= X-Google-Smtp-Source: APiQypLHZye1fkU6j9TIN7dfZ9l3YzeOf9p7q5GHq2bPlmwQe/MKBJIbtcdm+/wzADSTW9piUXYH/FuZmQD/uJPZKQw= X-Received: by 2002:a92:c787:: with SMTP id c7mr1848296ilk.120.1586532096104; Fri, 10 Apr 2020 08:21:36 -0700 (PDT) MIME-Version: 1.0 References: <20200409230933.E0CBD17638B4@ary.qy> <3377169.EuQdDTRyQv@sk-desktop> In-Reply-To: <3377169.EuQdDTRyQv@sk-desktop> From: "Kurt Andersen (b)" Date: Fri, 10 Apr 2020 08:21:21 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000038d1205a2f14ae9" Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 15:21:40 -0000 --000000000000038d1205a2f14ae9 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 10, 2020 at 6:49 AM Scott Kitterman wrote: > On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote: > > > > I don't disagree, but what I was going for here was some level of > > consistency with section 3.2 of RFC 7489. . . > And it needs to stay entirely in RFC7489 :-) > > Dale twice in his comments expresses doubt that it's possible for anyone > to > > know all PSDs; the mention of a specific PSL in the abstract was an > attempt > > to answer those doubts. > > > But how to address Dale's concerns about how one knows all PSDs? > > To the extent this is a problem, it's RFC 7489's problem. This document > leverages it's existing definitions. That's intentional. While the > current > RFC 7489 definitions aren't ideal, as an extension to that work, I don't > think > it make sense to try and fix it here. That's work for 7489bis. Agreed. Dale's concern is a non sequitur. We can always invoke the ghost of DBOUND-past :-D --Kurt --000000000000038d1205a2f14ae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 10, 2020 at 6:49 AM Scott Kit= terman <sklist@kitterman.com= > wrote:
On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr w= rote:
>
> I don't disagree, but what I was going for here was some level of<= br> > consistency with section 3.2 of RFC 7489. . .
And it needs to stay entirely in RFC7489 :-)
=C2=A0
> Dale twice in his comments expresses doubt that it's possible for = anyone to
> know all PSDs; the mention of a specific PSL in the abstract was an at= tempt
> to answer those doubts.

> But how to address Dale's concerns about how one knows all PSDs?
To the extent this is a problem, it's RFC 7489's problem.=C2=A0 Thi= s document
leverages it's existing definitions.=C2=A0 That's intentional.=C2= =A0 While the current
RFC 7489 definitions aren't ideal, as an extension to that work, I don&= #39;t think
it make sense to try and fix it here.=C2=A0 That's work for 7489bis.

Agreed. Dale's concern is a non sequitur.= We can always invoke the ghost of DBOUND-past :-D

--Kurt=C2=A0
--000000000000038d1205a2f14ae9-- From nobody Fri Apr 10 08:50: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 DEA293A02BC for ; Fri, 10 Apr 2020 08:50:25 -0700 (PDT) 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 rv25GNvlQvLW for ; Fri, 10 Apr 2020 08:50:24 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182673A017E for ; Fri, 10 Apr 2020 08:50:23 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id t11so2219644ils.1 for ; Fri, 10 Apr 2020 08:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=joOx824SabF1gQs/A2ZEifdi1z5gxVAAnmbkKXJLFPc=; b=BbpGwNRf0csKkBExu0cuuhzl0owvq0k4o280WrRdtywqsjIaSFBvhL6bSeoiNE5YDy CsSDAOaIaF5xPjkzrnPKHJqPBmoH4dyYgRVx2SS/JDg2xWPuzTUaoEowaRAZP6p7Xvnn MjC6yMJ6lTcmyMxoFjRc7Fx1zORuW8D+qsX4/JvgSmVTuIiBwv3jvrhnn+9taXNMsPje EeCUO14t37vcgxLP69yQV9iQ08GfknwoVURuMYdcfr3BO4C7nSEYwDrZrHe1LXh171Yu gWnfbHce5C8T5PsHnP90Coks9LpLlvB6dLNgN4XwrW0Ydcd2l2xO/vaSPhHHe9hLPJ04 MhuA== 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=joOx824SabF1gQs/A2ZEifdi1z5gxVAAnmbkKXJLFPc=; b=JZN/chcpJJVID6tLR4qI0TtnCSYcH1ddr4K50XrtLBSlH7YoY9neX5zGI9xKrgT6bL JY1FM5AOd6kdhZjH950D+5vgPS0oQdk+8Ie+9zeVOtokJimzwI5KG42n0R6eBghWvjY1 dFHVR1T6Q5AsY1XSSMgXByDUg1E2jsyxULG5p0UYVwtuTiF5cWRTRFxGvdXITN6Zbmi5 P0T5UK8uUUJPPE7oWbqRN/pMXP+LPlargTK2r6vdEuUIKugQ6JoQw3dirLazk9Ukfm0g yvrIHxXUlsUp9T9S0WgRiPcWTg/rh8venoy7BmwcFh6Axwx7DZVueCCQJZ28sYqga/F1 aQFg== X-Gm-Message-State: AGi0PuardGNiLCTh4f2tFVwhjDocBkYrJd8DXW0iUgvwN0Lfx0gqOK2j LaSEMLxZgxjm2tUrmsZD7oLmovqfWEGpvgX0qac= X-Google-Smtp-Source: APiQypKKv+RwvTJU56qxeI5qUrhjsGIqspF/WZ6EcV9uCr6TTLijBxxVfcTwQMiHRTvL672FoRWIhPP/5jFnVxcTJ6Y= X-Received: by 2002:a05:6e02:60f:: with SMTP id t15mr5447130ils.277.1586533823121; Fri, 10 Apr 2020 08:50:23 -0700 (PDT) MIME-Version: 1.0 References: <20200409230933.E0CBD17638B4@ary.qy> <3377169.EuQdDTRyQv@sk-desktop> In-Reply-To: From: Tim Wicinski Date: Fri, 10 Apr 2020 11:50:11 -0400 Message-ID: To: "Kurt Andersen (b)" Cc: Scott Kitterman , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f38e8a05a2f1b0c3" Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 15:50:26 -0000 --000000000000f38e8a05a2f1b0c3 Content-Type: text/plain; charset="UTF-8" Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel word around it for now. I tried to reference 8499 thinking we'd done the right thing in there, and Kurt pointed out the error of my ways. We should take an item to really sort this out in 7489bis. and John has heard me on several occasions appreciating the simplicity in https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt tim On Fri, Apr 10, 2020 at 11:21 AM Kurt Andersen (b) wrote: > On Fri, Apr 10, 2020 at 6:49 AM Scott Kitterman > wrote: > >> On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote: >> > >> > I don't disagree, but what I was going for here was some level of >> > consistency with section 3.2 of RFC 7489. . . >> > > And it needs to stay entirely in RFC7489 :-) > > >> > Dale twice in his comments expresses doubt that it's possible for >> anyone to >> > know all PSDs; the mention of a specific PSL in the abstract was an >> attempt >> > to answer those doubts. >> >> > But how to address Dale's concerns about how one knows all PSDs? >> >> To the extent this is a problem, it's RFC 7489's problem. This document >> leverages it's existing definitions. That's intentional. While the >> current >> RFC 7489 definitions aren't ideal, as an extension to that work, I don't >> think >> it make sense to try and fix it here. That's work for 7489bis. > > > Agreed. Dale's concern is a non sequitur. We can always invoke the ghost > of DBOUND-past :-D > > --Kurt > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --000000000000f38e8a05a2f1b0c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with=C2=A0John/Scott/Kurt on keeping this in 7489 and trying to we= asel word around it for now.=C2=A0

I tried to reference 8499 thinking we'd done the= right thing in there, and Kurt pointed
out the error of my ways.=C2=A0

We should take an item t= o really sort this out in 7489bis.=C2=A0

and John has heard me on several occasions=C2= =A0appreciating the simplicity in
https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt

tim
=C2=A0

On Fri, Apr = 10, 2020 at 11:21 AM Kurt Andersen (b) <kboth@drkurt.com> wrote:
On Fri, Apr 10, 2020 = at 6:49 AM Scott Kitterman <sklist@kitterman.com> wrote:
On Friday, Apr= il 10, 2020 9:38:40 AM EDT Todd Herr wrote:
>
> I don't disagree, but what I was going for here was some level of<= br> > consistency with section 3.2 of RFC 7489. . .
And it needs to stay entirely in RFC7489 :-)
=C2=A0
> Dale twice in his comments expresses doubt that it's possible for = anyone to
> know all PSDs; the mention of a specific PSL in the abstract was an at= tempt
> to answer those doubts.

> But how to address Dale's concerns about how one knows all PSDs?
To the extent this is a problem, it's RFC 7489's problem.=C2=A0 Thi= s document
leverages it's existing definitions.=C2=A0 That's intentional.=C2= =A0 While the current
RFC 7489 definitions aren't ideal, as an extension to that work, I don&= #39;t think
it make sense to try and fix it here.=C2=A0 That's work for 7489bis.

Agreed. Dale's concern is a non sequitur.= We can always invoke the ghost of DBOUND-past :-D

--Kurt=C2=A0
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--000000000000f38e8a05a2f1b0c3-- From nobody Fri Apr 10 09:33: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 B2C4B3A0842 for ; Fri, 10 Apr 2020 09:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=P/e+ICn4; dkim=pass (1536-bit key) header.d=taugh.com header.b=KsFKbEng Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzzZNSMxSUfg for ; Fri, 10 Apr 2020 09:33:15 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D913A07A2 for ; Fri, 10 Apr 2020 09:33:15 -0700 (PDT) Received: (qmail 77076 invoked from network); 10 Apr 2020 16:33:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12d10.5e909fc9.k2004; bh=UuN7ldh1NhqHqumbMKVJX3vmqG4nmbKXB2XfrogctmI=; b=P/e+ICn4GTmLBqHmMrU4Q56Hgm2lUZZ0Y9Lryh3HZ8owF8l6HgLjEemj5wDG2qs8jBPki2DB1iziytymoXKMXMfhJNOZcEfF0XLz15s3qBtGLc1YeDjuimCJNfFFhRMBE4cSanVDYK3Cpi11TLn1nPh4VjONSJYc+FwV5zm+HRIZ9jnbl76H05a1qHtw+qKNMB3LqRsGQ807i0SS0PuJTiyPlWK6FCZccmAbVIZgzHYFGc6dGT4/ufnWceig7dyO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12d10.5e909fc9.k2004; bh=UuN7ldh1NhqHqumbMKVJX3vmqG4nmbKXB2XfrogctmI=; b=KsFKbEng5ZQUEN6jAE1mQ+Jm+nQ4Id/ltQ7IUUTuswhdFy9Wk0B+jM9CrBjAKt+EewBh2TNULWXNx8cRxXCwwbzbUtoQMmU+LKQMxQfZ9rip1acU3uxtccHEweoAgm/V8DrAXE68aZUKiVpmk1zP4T0WXKdPj/Kk/Z3mfQd6FlB7HiwfxXKKkcxaE7TflVMZKAQ2G4OQuZaWR9UjnhD792gBttSz+M/uplCWiM6atGHFDKZTa+II6MubXAjZ/yuc Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Apr 2020 16:33:13 -0000 Received: by ary.qy (Postfix, from userid 501) id 850961769BE6; Fri, 10 Apr 2020 12:33:13 -0400 (EDT) Date: 10 Apr 2020 12:33:13 -0400 Message-Id: <20200410163313.850961769BE6@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: toddmherr@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 16:33:18 -0000 >Dale twice in his comments expresses doubt that it's possible for anyone to >know all PSDs; the mention of a specific PSL in the abstract was an attempt >to answer those doubts. This kind of stuff drives me nuts since it suggests the reviewer isn't familiar with all of the other stuff that has the same issue. Plan A: This is essentially the same problem that affects browser supercookies or signing wildcard SSL certificates, both of which have been in production for many years. It's not a new problem, there are approximate solutions and it doesn't have to be perfect to be useful. Plan B: Major rewrite: Define PSD as Policy Super Domain. Say that the PSD is defined as the domain one up from the Org domain, see RFC 7489, full stop. Do not offer any other suggestions about how to find it, do not mention the PSL -- you've already got the org domain, one snip and you're done. Take out all of the public suffix stuff. If you want, you can add another informative paragraph that says that Policy Super Domains often have legal or contractual relationships with their child org domains so this can be useful to express policies intended to apply to all of their org domains, perhaps with shorter versions of the .bank or .gov.uk examples, but don't go very far, since it's not part of the definition and especially don't mention the PSL or use the phrase public suffix. I'd suggest plan B since people will otherwise be complaining about the PSL forever, even though we're already stuck with it for org domains. R's, John From nobody Fri Apr 10 09: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 56FBE3A089C for ; Fri, 10 Apr 2020 09:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=eSjv5ISh; dkim=pass (1536-bit key) header.d=taugh.com header.b=rtrxxqOq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLSivQt5zRDf for ; Fri, 10 Apr 2020 09:34:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069223A087B for ; Fri, 10 Apr 2020 09:34:10 -0700 (PDT) Received: (qmail 77247 invoked from network); 10 Apr 2020 16:34:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12dbd.5e90a002.k2004; bh=90DVv1qWcPHsPmW00IiyjKskFNPXKxRpkLirJQ2xm8c=; b=eSjv5IShTyfh0kSgyaZIjejSt98npbLrdHoTCyO0sA8V+VacGDpn9REQKbcmJXRJmvZg0wttquSk8vZ7bKnP7wwqvrO59LY+cJgROzeVnwzjp7MLHZwk+fYJ8cE1XcFoKHsn8EPZ1ESVmKztmLPNgMHmfpFBMAkAOSdidhB5QHr6aTqWl5Xy5o25xAPD71XTmSITE8pSeSFUer7DlQ4sfPwkEjBkpQmnBBosAohkr14fFAbO0syR7fI9wAj62FMc DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12dbd.5e90a002.k2004; bh=90DVv1qWcPHsPmW00IiyjKskFNPXKxRpkLirJQ2xm8c=; b=rtrxxqOqhMF47LAZYSG2+/E2hhLz4xVeO/sdtbjNQ9Zq7GyPuYtDK/nfnklmfwSoM7EhAipeKMN+PZuAsJh9mh/VaMyIQedvmhU8GYK8PN1ziP9qcqgz93ws+rTRwCKAPrUQjfOoKA5Z7lbMvwkf4s9bTAco0GN6SUb8cK94GNjhu2+g9N6BaigAZclWPJxomMQOsCKwHnnG11FO4HLYU0hWWy3rdpHo4iyvqWIIOe+Ezz995yF9eqLw7osnY46d Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 10 Apr 2020 16:34:09 -0000 Received: by ary.qy (Postfix, from userid 501) id B0AE81769C14; Fri, 10 Apr 2020 12:34:09 -0400 (EDT) Date: 10 Apr 2020 12:34:09 -0400 Message-Id: <20200410163409.B0AE81769C14@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: tjw.ietf@gmail.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 16:34:12 -0000 In article you write: >-=-=-=-=-=- > >Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel >word around it for now. So how about renaming it Policy Super Domain (PSD)? R's, John From nobody Fri Apr 10 09:45: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 A949F3A08EC for ; Fri, 10 Apr 2020 09:45:16 -0700 (PDT) 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 xrCe5aJoYYJL for ; Fri, 10 Apr 2020 09:45:15 -0700 (PDT) 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 7883C3A08E8 for ; Fri, 10 Apr 2020 09:45:15 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id d2so1962618ilc.0 for ; Fri, 10 Apr 2020 09:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bOKHEVYFAV0dU5qVTNNxa4Xj5587+/+nmzMohpxOjs4=; b=CQc/bBuz/p6qL8ZpgMqCuqloXhmbWqeN9IPOhswbhtLzG8Uiv37KDuW4X3i5SzPdcL cz3o1humV0pRtaxVlTPSjdRIFfXTMRLCwhU6+05f/690tGVM0uIGY4JrOmeX8mRfXanP TaotrvLV0Js53oK08EggtUNO/bkNm6knpfKbqAw/A4b/GClH/Qz8veWdpLOgSmUvNq2G z/vLbpCdQxRH4cpi+kwpJmwiX9BxXbBXaB/0AMZC8H0hvqiIiFff/5lyVXAHuYuRBI9I /1kycrsYIScUzH2/zqqCjk0aMGxGVlRA0fuBLSOHhq7vUTvgvofu9NU4E+oJRRKHXGWp /0pA== 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=bOKHEVYFAV0dU5qVTNNxa4Xj5587+/+nmzMohpxOjs4=; b=cx/9fg7OSP8I/JzYw7eddedU+91x63BFLWX2OI5+4/OOS7QiL+4utjasL1TcfIx9/R tlKg1PdsavheGEK+IDdkQLl/g8B7GOoPdVL4zawNlLz5m3tPPzwPjWP3pnbYVLS7FS48 qrKQidMyvefK4eHMNXsU4z0tgPAHiOyiJOl07SyWC6eqv1dm9ePOtF9u6C3ka12xLgKU yU0PUIBVflM2l28W2c1xyEBsk1uY1KZdWfVU4h1+lI6S71w4f2kT7kSwXCaBwoeuwgZr fx3TfgTbSIJQemqxWniIkKOxSrYltTq03MnrPPPfd6/gdSO7+hRwOuaTx0qSqw0Qq6Zt s2LQ== X-Gm-Message-State: AGi0PuaqQimwWpp2345S7BHfhTQSYRU/wYd3LURskp5s6lSoooXwaxIv fGP6tFJchP0KRmBxTZ7EP06TQk0+EC8oos6BU88= X-Google-Smtp-Source: APiQypIHkGQuN4W57jMSATme4vzcsszwFDtfZmnOEbGKdfyaQofSUd1rxukIeOliQ7/y1IegL9DkawSvA29kk2e+OjI= X-Received: by 2002:a92:bbc4:: with SMTP id x65mr6262112ilk.82.1586537114687; Fri, 10 Apr 2020 09:45:14 -0700 (PDT) MIME-Version: 1.0 References: <20200410163409.B0AE81769C14@ary.qy> In-Reply-To: <20200410163409.B0AE81769C14@ary.qy> From: Tim Wicinski Date: Fri, 10 Apr 2020 12:45:03 -0400 Message-ID: To: John Levine Cc: IETF DMARC WG Content-Type: multipart/alternative; boundary="00000000000024dcbd05a2f27574" Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 16:45:17 -0000 --00000000000024dcbd05a2f27574 Content-Type: text/plain; charset="UTF-8" That works for me. I noticed Wikipedia has an entry for https://en.wikipedia.org/wiki/Second-level_domain and I remember seeing a spreadsheet of all the second level domains that ccTLD registries offer, and it was quite lengthy. (Longer than the list in Wikipedia) tim On Fri, Apr 10, 2020 at 12:34 PM John Levine wrote: > In article skKOHN-j+QicCser1rTg1anwPwonw@mail.gmail.com> you write: > >-=-=-=-=-=- > > > >Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel > >word around it for now. > > So how about renaming it Policy Super Domain (PSD)? > > R's, > John > --00000000000024dcbd05a2f27574 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

T= hat works for me.=C2=A0 I noticed Wikipedia has an entry for=C2=A0
https://en.wikipedia.org/wiki/= Second-level_domain

and I remember seeing a spreadsheet of all the second level = domains that ccTLD registries offer,
and it was quite lengthy. (Longer than the list= in Wikipedia)

tim

On Fri, Apr 10, 2020 at 12:34 PM John Levine <johnl@taugh.com> wrote:
In article <CADyWQ+EXPAMWXNQrgkbx=3DskKOHN-j+QicCser1rTg1anwPwonw@mail.gmail.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel=
>word around it for now.

So how about renaming it Policy Super Domain (PSD)?

R's,
John
--00000000000024dcbd05a2f27574-- From nobody Fri Apr 10 09: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 7CF183A0927 for ; Fri, 10 Apr 2020 09:57:09 -0700 (PDT) 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 nYpnfBya1xZn for ; Fri, 10 Apr 2020 09:57:07 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0E83A090D for ; Fri, 10 Apr 2020 09:57:07 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id f16so2356740ilj.9 for ; Fri, 10 Apr 2020 09:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mXwrhAsi9juWoW/xzIAMFnihKqKf0Kjs1JDW2A5w19k=; b=JqeVmWeFK3fnSPF2TjPWOJAMz5OkYsXdCdSsYWPatHctrzDk1r+RY8YwEt9hZFCn7r WZ2K9H6rRiRKG1uNOHykU6tXxeXaK/Mdedw7UDO4vGgNVIXs9FnPbPGSuRWEGpNeWiWB 2bZolAO+z2oMCLWhdNOeopP6chXqYenZda89c= 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=mXwrhAsi9juWoW/xzIAMFnihKqKf0Kjs1JDW2A5w19k=; b=H3VwFYAAsZePm+86s8nFaCaDYF3GUmMDmVZYVRkbbA8mSNoP3/+yfvin0n+ZxSGmVL dxRWz4Wkg7W/3cplvcftB89rHn81TscXNX3tknz5G5K7YxfZ4BtMD70FLDcMm7ULN2Hc jetR26t8m4F/6R7RTHU4bCtat33hzRjKQUWnPXUFMowSvK0iZRwOQrBcX2Iw8xAjVFwX DX2PI1+vkSRE9h31ZIVRJQzk362CRQD7O8XiIsHng2DddzfjyUSVb/vxaAI8E8q2h/n9 1RWShM9E6DhrL0ff6iGgBAUG3pG5OPYzBPdnLq7Zv0Z9aZY1r3mYrxTgNL9tCYSJyDK/ tjwg== X-Gm-Message-State: AGi0Pua7y+ql2+5rUQkdqF6PqG+MdZqQ7TeI+lrFhSC1Vj4ZT7NKpQn4 v172l9Gf4J0qjkAA0CEm8mvnJOel+eugiW2M14bjZQ== X-Google-Smtp-Source: APiQypLukpjIrgZWBzJx4hTzbQ0ChLzkLtIePBvCMEZ5xVtDlaLN4Mg+UdBnXo95opa5OcpeFRRmjnDjvyIdgf4dHfY= X-Received: by 2002:a92:d20e:: with SMTP id y14mr6152533ily.104.1586537826840; Fri, 10 Apr 2020 09:57:06 -0700 (PDT) MIME-Version: 1.0 References: <20200410163409.B0AE81769C14@ary.qy> In-Reply-To: <20200410163409.B0AE81769C14@ary.qy> From: "Kurt Andersen (b)" Date: Fri, 10 Apr 2020 09:56:52 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , tjw ietf Content-Type: multipart/alternative; boundary="000000000000978dd305a2f29fc9" Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 16:57:10 -0000 --000000000000978dd305a2f29fc9 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 10, 2020 at 9:34 AM John Levine wrote: > In article skKOHN-j+QicCser1rTg1anwPwonw@mail.gmail.com> you write: > >-=-=-=-=-=- > > > >Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel > >word around it for now. > > So how about renaming it Policy Super Domain (PSD)? > Works for me. --Kurt --000000000000978dd305a2f29fc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 10, 2020 at 9:34 AM John Levi= ne <johnl@taugh.com> wrote:
In article <CADyWQ+EXPAMWXNQrgkbx=3DskKOHN-j+QicCser= 1rTg1anwPwonw@mail.gmail.com> you write:
>-=3D-=3D-=3D-=3D-=3D-
>
>Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel=
>word around it for now.

So how about renaming it Policy Super Domain (PSD)?
Works for me.

--Kurt=C2=A0
--000000000000978dd305a2f29fc9-- From nobody Fri Apr 10 11:21: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 6E4393A0CD8 for ; Fri, 10 Apr 2020 11:21:15 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=hWsT6dNw; dkim=pass (1536-bit key) header.d=taugh.com header.b=kGrXH5cY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRcL52kR4BLd for ; Fri, 10 Apr 2020 11:21:13 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005133A0C74 for ; Fri, 10 Apr 2020 11:21:09 -0700 (PDT) Received: (qmail 96025 invoked from network); 10 Apr 2020 18:21:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17717.5e90b914.k2004; i=johnl-iecc.com@submit.iecc.com; bh=+uOvN5Cn9qMRBd/Oc41mUO70naz3kyAT50oXfrNBHP4=; b=hWsT6dNwRP71yXugkDWppFWLKAA1LhBtVJKibhUqt0bBc6FrtRLcoyLVLHDIxdymdnXAN3zmgkbFKiDFdT4uoV/69m0Bwaq0iKI44beIAyY2OmtM57Sy29SLytffDmgW9E1pUdtuweY12hyl5DrF4BK4XCmcDnUVaIxnDzyGolpGBeaJhZF7K516SX5eqcwB4WKud5qYWw1IgeRfaWZUs3Mv3xcqnwxwrlahcndh7Cjh2UvWUJHkXt0JY92AnwSL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17717.5e90b914.k2004; olt=johnl-iecc.com@submit.iecc.com; bh=+uOvN5Cn9qMRBd/Oc41mUO70naz3kyAT50oXfrNBHP4=; b=kGrXH5cYlj+7eP0viHBsNEvVj1zlRL+kdaF9i5CtBQDW5aUIMzWS/NJrX7jx17VA4knxq8WlM/8Wj+GDTBmnsU7AysCiQWoEJ9Uzw3ScrQSZZ7JCFZJ7QM25bV6RKDg2CxsY5xyfamOneE2fAjjngpdUOJH7owCTmIIvzAVLj7gvA4to8ffN0PLCLjzf9gESHN43vjphKoMesPEzmVykVvHxlpllGT1hVo49dw/qFzE9oZpOvr7Qf/o3qj1Hv2QU 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; 10 Apr 2020 18:21:08 -0000 Date: 10 Apr 2020 14:21:07 -0400 Message-ID: From: "John R Levine" To: "Tim Wicinski" Cc: "IETF DMARC WG" In-Reply-To: References: <20200410163409.B0AE81769C14@ary.qy> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dmarc-ietf] 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: Fri, 10 Apr 2020 18:21:22 -0000 > and I remember seeing a spreadsheet of all the second level domains that > ccTLD registries offer, > and it was quite lengthy. (Longer than the list in Wikipedia) Per the PSL, there's at over 5800, there are ccTLDs including AU US CA JP that have second and third level and a few fourth level registration points. The less we say about this mess, the better. I realize it's late in the process but I think the draft would benefit by moving the examples in sec 1 to an appendix and replace it with something bland that just says PSD == Org-1. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly PS: pvt.k12.ma.us From nobody Fri Apr 10 19:34: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 681AF3A15A1 for ; Fri, 10 Apr 2020 19:34:09 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=cQqcdk9B; dkim=pass (1536-bit key) header.d=taugh.com header.b=rP0cwvV5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs4tl-cM3UHe for ; Fri, 10 Apr 2020 19:34:06 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750DA3A15A0 for ; Fri, 10 Apr 2020 19:34:06 -0700 (PDT) Received: (qmail 31735 invoked from network); 11 Apr 2020 02:34:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:user-agent; s=7bf5.5e912c9c.k2004; i=johnl-iecc.com@submit.iecc.com; bh=oeWwFAEsN99VJASyZOi3bAklrXrKFnpjPMS93m1viVU=; b=cQqcdk9BHzco9FW5WnPr7r/26b8cCQ/UxqynrJvyNB+TfaElZmL2a6gZsamHXPPJLh8dObpgRIjNOM8rCt8nKWhxAcMjDtfeV5T8C6hZ7DH3qP6xQ6jIpJ5lkS/IQa4oO7V0t9bqLymMpAr0LBbDfytox7M2P6Ai1wfQh3PplP277AumYWnLrmHSfKFOXpX1HvUaeXwf4YkACrFwaiT7PcqW1BGg07IdRAowfuBemcSC4CtPrWCT1S6wa/21NUvj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:user-agent; s=7bf5.5e912c9c.k2004; olt=johnl-iecc.com@submit.iecc.com; bh=oeWwFAEsN99VJASyZOi3bAklrXrKFnpjPMS93m1viVU=; b=rP0cwvV5LWK+/xLhhzDUTx055Y1xS47vhlACAeAJoy06iQDa2c55ZAa8TzmBZYMTYelF5kp1W69A/MYjN1sYZeZ7FlX/TeauG81DrMqQnxlOIoXrQHFhVCYGnZtNnnOMIfVPJIihtZRGTOqS8s527OhoOX35qDAnzJJ1O851qQnDNSVaDHg9p17h8JCgiPIoXdh5j+bzql5OPJyUFPjtMeywNjvThgcFF/dQT96zuBpdXi2Txhp1R02Af/6B4E5j 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 Apr 2020 02:34:04 -0000 Date: 10 Apr 2020 22:34:04 -0400 Message-ID: From: "John R Levine" To: "IETF DMARC WG" , dnsop@ietf.org Cc: "Tim Wicinski" User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [dmarc-ietf] Refreshed DNS dbound draft and code X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 11 Apr 2020 02:34:09 -0000 I made some twiddles to my dbound-in-dns library and updated the I-D to match. Code: https://github.com/jrlevine/bound I-D: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/ I added some more records to the DNS zone so now I believe that by careful abuse of DNS wildcards, in most cases it will find the closest boundary (aka public suffic) and DMARC orgznizational domain for a domain with one or two DNS queries no matter how far down the tree the name is and how many intermediate boundaries may exist. A zone that describes all the boundaries in the Mozilla PSL uses 16,000 DNS records which 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 Tue Apr 14 02:55: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 884F23A0953 for ; Tue, 14 Apr 2020 02:55:18 -0700 (PDT) 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 XJHhu-JS4nI0 for ; Tue, 14 Apr 2020 02:55:16 -0700 (PDT) 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 9F1543A0952 for ; Tue, 14 Apr 2020 02:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1586858113; bh=mcIueDMLl3PH5hE2h7bOy0GTdiZF81fI3RyPPQjLuxs=; l=2298; h=To:References:From:Date:In-Reply-To; b=ArTLD8SL2+SkSVjdLfGgeHNHsk/EgOMVA/QBo/Xs0VNgvuteKnR3ACvlKS7clzuYK +WLVALROiUN0LH17lYKiBNlINLLgqqwnyrrcBtMf0Geaq2GcNJzLHyGXNM8xE2fvYl /92Iugo70mLbniZvSiDQhSE9Et2+Ao2iaJNmeTyv8aenIfTDabgQhy+0wfXQ5 Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005E958880.00001D25; Tue, 14 Apr 2020 11:55:12 +0200 To: dmarc@ietf.org References: <20200409230933.E0CBD17638B4@ary.qy> From: Alessandro Vesely Message-ID: <38319f95-e5a5-476f-f029-86315ed655f2@tana.it> Date: Tue, 14 Apr 2020 11:55:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] 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, 14 Apr 2020 09:55:18 -0000 On Fri 10/Apr/2020 15:38:40 +0200 Todd Herr wrote: > On Thu, Apr 9, 2020 at 7:09 PM John Levine wrote: >> In article you write: >>> 1. ".co.uk" is not a TLD. TLDs are single label domains - there are >>> ccTLDs and gTLDs. >> >> Right. >> > > I don't disagree, but what I was going for here was some level of > consistency with section 3.2 of RFC 7489, which reads in part: > > 1. Acquire a "public suffix" list, i.e., a list of DNS domain names > reserved for registrations. Some country Top-Level Domains > (TLDs) make specific registration requirements, e.g., the United > Kingdom places company registrations under ".co.uk"; That text says TLD .uk made decision so and so. It doesn't imply that .co.uk is somehow to be considered a TLD. That wikipedia page is questionable. https://en.wikipedia.org/wiki/Talk:Second-level_domain > The point of the paragraph in question wasn't to define TLDs (or PSDs) but > rather to better define "domain names reserved for registration". Right. >>> 2. The invocation of the PSL compounds the issue that was raised by >>> Dave Crocker. How DMARC (RFC 7489) determines the organizational domain >>> is orthogonal to this proposal which simply calls for a conditional >>> additional check at the "org - 1" level. I recommend striking the >>> penultimate paragraph in the proposal.>> >> I'd suggest weasel wording it to say that the domain above an org >> domain is often known as a public suffix domain, which typically >> delegates the org domains below it to a unrelated parties. This spec >> allows public suffix domains to publish policies to supplant those of >> their child org domains ... +1 >> I agree we should stay as far from mentioning the PSL and its specific >> implementation as possible. Who knows, someday people might get >> around to trying my dbound in DNS implementation instead. Nevertheless, the concept of *Public Suffix* is independent of its only known implementation (and of some acceptations of the term "public"). It is the concept that 7489bis is going to craft. I propose to stick to the term Public Suffix, whatever its future definition is going to be. jm2c Ale -- From nobody Wed Apr 15 19:32: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 DA3CE3A0973 for ; Wed, 15 Apr 2020 19:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 jM0VJZ5Uu8mZ for ; Wed, 15 Apr 2020 19:32:36 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 6A75C3A095C for ; Wed, 15 Apr 2020 19:32:36 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id Ou68jPuVy9yxwOuKRj9iQo; Thu, 16 Apr 2020 02:32:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1587004355; bh=brH5qSPbLLHZ016EMbKbw5yKMAu9ClbLe8dg3449ARw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Hmv/xb3bYwbHb7I554Kr3It+TZGkBW5SVLNoQM3Mp6eYEB+bb5FmjdEOE3yzVgbtX MDhWz5VaDto990oWNFpyizGeWsXA94oYsbWu5ypwpEOtcwjS3RC3OQguQHf7hE0MB0 NZZ65tSeQB+lcfyYDaQZPnGOS/mFGwg1KAPwx0UuRcPYT2ihcApL1ize94qi/iHojM 7SuzfETxxONptj7QEJP5HDa4ra+h4PwX4rI/PamX1U386L/EpxlSrQCpxjEK8HFcLq CnqxPglWTStJ2QZYyrqIeHpic2NMrtc3xFBhL29OATDdFkp+0l2riv2YJ1wGKnq4AW BGVwhh6Mi5bdw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-11v.sys.comcast.net with ESMTPA id OuKPjjxshByhMOuKQjhuMB; Thu, 16 Apr 2020 02:32:35 +0000 X-Xfinity-VMeta: sc=-100.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 03G2WXIV012486; Wed, 15 Apr 2020 22:32:33 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 03G2WWQb012483; Wed, 15 Apr 2020 22:32:32 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Todd Herr Cc: gen-art@ietf.org, last-call@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org In-Reply-To: (toddmherr@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 15 Apr 2020 22:32:32 -0400 Message-ID: <873694nosf.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 16 Apr 2020 02:32:47 -0000 Todd Herr writes: > Having reviewed the comments, I'm wondering if perhaps the following draft > rewrite of the Abstract section might be a first step to address many of > the points raised? I heartily endorse the sentiment behind this. I think there are some minor improvements that could be made, as I've noted below. One point is that much of this information might be better put into the Introduction, and only a skeleton of it put into the Abstract. But as they say, you write the Introduction after you've written the body of the work, and you write the Abstract after you write the Introduction. > *AbstractDMARC (Domain-based Message Authentication, Reporting, and > Conformance) is a scalable mechanism by which a mail-originating > organization can express domain-level policies and preferences for message > validation, disposition, and reporting, that a mail-receiving organization > can use to improve mail handling. * > > *The original design of DMARC applies only to domains that are registered > with a domain name registrar (called "Organizational Domains" in RFC 7489) > and nodes in the tree below Organizational Domains. Organizational Domains > are themselves nodes in the tree below domain names reserved for > registration, with the latter commonly referred to as "Top Level Domains" > (TLDs) (e.g., '.com', '.co.uk ', etc.), although in this > document they will be referred to as Public Suffix Domains (PSDs).* In some way it would be useful to flag that RFC 7489 is the base DMARC RFC. Otherwise, the reader must just infer that, or look up the RFC. There's also a point which seems to be very general, as it shows up in RFC 7489 section 3.2: all the text refers to a "domain" without explaining *what* domain is extracted from the message under consideration to determine the policy that applies to the message. My belief is that this is the From header in the message, but I've never seen this stated. So e.g. "The original design of DMARC applies only to messages with From addresses containing domain names that are registered ..." This paragraph uses the phrase "domain names reserved for registration", but I've not heard that term used in descriptions of the DNS. And I would expect say that "ietf.org" is "reserved for registration", not "org" -- though I've never heard the phrase "reserved for registration". The phrase that seems obvious to me is "domain names under which domain names are registered, commonly referred to as 'Top Level Domains'...", but that's somewhat awkward. And Kurt Andersen notes that while .co.uk is clearly intended as one of these domain names, it isn't, strictly speaking, a TLD. > *Since its deployment in 2015, use of DMARC has shown a clear need for the > ability to express policy for PSDs. This document describes an extension to > DMARC to enable DMARC functionality for PSDs.* I'm not sure, but I suspect this could be clarified as "policy for PSDs, and by inheritance, for domains under PSDs for which no explicit policy is published." -- My belief is that nobody cares about mail claiming to come from "person@org", but it's important to have a policy that applies to "person@areallylongstringoflettersfoobarbaz.org", inherited from "org". > *RFC 7489 describes an algorithm for a mail-receiving organization to use > in determining the Organizational Domain of an inbound mail message, and > this algorithm recommends the use of a "public suffix list" (PSL), with the > most common one maintained by the Mozilla Foundation and made public at > >. Use of such a PSL by > a mail-receiving organization will be required in order to discover and > apply any DMARC policy declared by a PSD.* I don't know if this is useful, but I would suggest changing "determining the Organizational Domain of an inbound mail message" to "deriving from the domain name of the From address of an inbound mail message the Organizational Domain to be used for DMARC processing". > *This document also seeks to address implementations that consider a domain > on a public Suffix list to be ineligible for DMARC* I think you are very close to an Abstract/Introduction that is clearly comprehensible to people who are not familiar with DMARC. Dale From nobody Wed Apr 15 19:45: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 957E63A09B9; Wed, 15 Apr 2020 19:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=QlnrUgqo; dkim=pass (2048-bit key) header.d=kitterman.com header.b=EhTmCFyb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGmGLhGNQPrB; Wed, 15 Apr 2020 19:45:04 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C213A09B4; Wed, 15 Apr 2020 19:45:03 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CF068F80279; Wed, 15 Apr 2020 22:44:57 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1587005097; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=3UYc+yYx1V1F9UVavHPKXBPQw8mgshHuDzZyMoNJck8=; b=QlnrUgqomzB8VWE2i1kYP994wl43gBk+I6Uqw1isoWKFzym5IW3WaW2H4ElyLCZADTwxx E0KC9kYHxCA2fuTAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1587005097; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=3UYc+yYx1V1F9UVavHPKXBPQw8mgshHuDzZyMoNJck8=; b=EhTmCFybN7KzTOH0LuT4lHH7S737PUb7lOwX02KVTYX7eswCNp0PPlFbfZrPB9q/+4BFO 8KuORynsiTn+U0PBUpLdhI1A3XFzjAKSKvttxKj5jWllVfzjaXPD/10QUT1k/rOtF4bIOoK QAhFYdMCwk8Hz0v0W64haCGZEPrd8nUqptyKHlzCQgIatJkXnEH57CCI4qXkf92ArkvKjEB er1CvHeRFjTXj2L/2RSHGwvFxFzsbFffXjdmUJ9ksZYN9qsTgsVk1eoaNyMZnz5n6UKFz3N wLmX/A1YzT12RLSug8TYstEhr5dkJQG7jGUS74HKP0x6dQz+XaBkt2e7soBA== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id 9902EF80024; Wed, 15 Apr 2020 22:44:57 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org, last-call@ietf.org Cc: gen-art@ietf.org, draft-ietf-dmarc-psd.all@ietf.org Date: Wed, 15 Apr 2020 22:44:57 -0400 Message-ID: <5104491.njhNTWfIiN@sk-desktop> In-Reply-To: <873694nosf.fsf@hobgoblin.ariadne.com> References: <873694nosf.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 16 Apr 2020 02:45:11 -0000 On Wednesday, April 15, 2020 10:32:32 PM EDT Dale R. Worley wrote: > Todd Herr writes: > > Having reviewed the comments, I'm wondering if perhaps the following draft > > rewrite of the Abstract section might be a first step to address many of > > the points raised? > > I heartily endorse the sentiment behind this. I think there are some > minor improvements that could be made, as I've noted below. > > One point is that much of this information might be better put into the > Introduction, and only a skeleton of it put into the Abstract. But as > they say, you write the Introduction after you've written the body of > the work, and you write the Abstract after you write the Introduction. > > > *AbstractDMARC (Domain-based Message Authentication, Reporting, and > > Conformance) is a scalable mechanism by which a mail-originating > > organization can express domain-level policies and preferences for message > > validation, disposition, and reporting, that a mail-receiving organization > > can use to improve mail handling. * > > > > *The original design of DMARC applies only to domains that are registered > > with a domain name registrar (called "Organizational Domains" in RFC 7489) > > and nodes in the tree below Organizational Domains. Organizational Domains > > are themselves nodes in the tree below domain names reserved for > > registration, with the latter commonly referred to as "Top Level Domains" > > (TLDs) (e.g., '.com', '.co.uk ', etc.), although in this > > document they will be referred to as Public Suffix Domains (PSDs).* > > In some way it would be useful to flag that RFC 7489 is the base DMARC > RFC. Otherwise, the reader must just infer that, or look up the RFC. > > There's also a point which seems to be very general, as it shows up in > RFC 7489 section 3.2: all the text refers to a "domain" without > explaining *what* domain is extracted from the message under > consideration to determine the policy that applies to the message. My > belief is that this is the From header in the message, but I've never > seen this stated. So e.g. > > "The original design of DMARC applies only to messages with From > addresses containing domain names that are registered ..." > > This paragraph uses the phrase "domain names reserved for registration", > but I've not heard that term used in descriptions of the DNS. And I > would expect say that "ietf.org" is "reserved for registration", not > "org" -- though I've never heard the phrase "reserved for registration". > The phrase that seems obvious to me is "domain names under which domain > names are registered, commonly referred to as 'Top Level Domains'...", > but that's somewhat awkward. > > And Kurt Andersen notes that while .co.uk is clearly intended as one of > these domain names, it isn't, strictly speaking, a TLD. > > > *Since its deployment in 2015, use of DMARC has shown a clear need for the > > ability to express policy for PSDs. This document describes an extension > > to > > DMARC to enable DMARC functionality for PSDs.* > > I'm not sure, but I suspect this could be clarified as "policy for PSDs, > and by inheritance, for domains under PSDs for which no explicit policy > is published." -- My belief is that nobody cares about mail claiming to > come from "person@org", but it's important to have a policy that > applies to "person@areallylongstringoflettersfoobarbaz.org", inherited > from "org". > > > *RFC 7489 describes an algorithm for a mail-receiving organization to use > > in determining the Organizational Domain of an inbound mail message, and > > this algorithm recommends the use of a "public suffix list" (PSL), with > > the > > most common one maintained by the Mozilla Foundation and made public at > > >. Use of such a PSL > > by > > a mail-receiving organization will be required in order to discover and > > apply any DMARC policy declared by a PSD.* > > I don't know if this is useful, but I would suggest changing > "determining the Organizational Domain of an inbound mail message" to > "deriving from the domain name of the From address of an inbound mail > message the Organizational Domain to be used for DMARC processing". > > > *This document also seeks to address implementations that consider a > > domain > > on a public Suffix list to be ineligible for DMARC* > > I think you are very close to an Abstract/Introduction that is clearly > comprehensible to people who are not familiar with DMARC. Considering this is an extension to DMARC, I don't think that's the target audience. Scott K From nobody Wed Apr 15 20:31: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 2C9AC3A0B3F for ; Wed, 15 Apr 2020 20:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=sethblank-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcKvs7PeCgYh for ; Wed, 15 Apr 2020 20:31:17 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5069C3A08E5 for ; Wed, 15 Apr 2020 20:31:15 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id j16so15486066oih.10 for ; Wed, 15 Apr 2020 20:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sethblank-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RXWj/NXSCYxgGvlTPqLqriVWnSpcf619P3GDaaXos6o=; b=mnuu3Kv5HCuupUw2XRxdSzQvKzuswT9jjXt20/kcd+Y7BL/ZRyuvJuX+5BvRJvfhU4 sUp7dcRuWcISCvnbQvUZUd7P0V/t+v8xAXCrQIiP91UVVe0erp7jfCQsNZW2k6s/b14m uz4xSg1DRZfTiyRdMTvLNNJXW2UW71uV1/0K22qRjARvG7S9Y8DIe5jC022ucZ4/lsza 1Kpx+D64rRVsU4Uwgcmp2/M34/NVo+LDIPWHB/3+P2myjsQFxpB9fRaYVnP3Wh4OA9eE rkO9zbgbnYAeRcoedJ4iakngc0JBMhVqc+UQLx/W/cIysnsgwaHpF3YyaXJsfNDuGhVh KFwQ== 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=RXWj/NXSCYxgGvlTPqLqriVWnSpcf619P3GDaaXos6o=; b=Bl2t+j3iJayuFZ9+ildrnMoxftqU3QseQ2yHQFsVNXWtUK9wfMTqYsgnQPmBEvzn2R FceF5iRLbloK0jxjADayaABciZddBdc/PnrSdYu/k76q+/CvXfOIZ4WUZUkFg97sXBG8 vah54Mw95o43xXKIQOP0PKjLpDkBCnwQpmyEssUW6SKXHRONi/OG+gOz7mBjUuATkECj xmer9wqtH7PAzVnRebNy7VrHy6a2Em/fcGoCzy09cNFBYJz5O0S3wYm3yTYobEWRX0e/ DeBVRouLKXbnI33v/d/4sYWtqxDktunFh8d9bhu90MwNreTTcqKyOaJDd9bLNSNcxvEV oYsQ== X-Gm-Message-State: AGi0PuYxpPSHZvZKGmZVRJlNQ7v453fRSAOCOOzk3r+4K6QCHDmfYy+s sRRUgUwFTMdbmWQRO61o7B3FxpXdIi1R3SJSjXtGNQ== X-Google-Smtp-Source: APiQypIiwmmDqYNtmNVNNlAkrDfcJ3uN5kuPmrRsBk4lRBcUeqVYN277ScftKHQ7YOrMWE80/+j5WDh+CMiqMdTHOKc= X-Received: by 2002:aca:31ce:: with SMTP id x197mr1687269oix.157.1587007875049; Wed, 15 Apr 2020 20:31:15 -0700 (PDT) MIME-Version: 1.0 References: <873694nosf.fsf@hobgoblin.ariadne.com> <5104491.njhNTWfIiN@sk-desktop> In-Reply-To: <5104491.njhNTWfIiN@sk-desktop> From: Seth Blank Date: Wed, 15 Apr 2020 20:30:59 -0700 Message-ID: To: Scott Kitterman , IETF DMARC WG Cc: last-call@ietf.org, gen-art@ietf.org, draft-ietf-dmarc-psd.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000a6008705a36010ab" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 16 Apr 2020 03:31:23 -0000 --000000000000a6008705a36010ab Content-Type: text/plain; charset="UTF-8" On Wed, Apr 15, 2020 at 7:45 PM Scott Kitterman wrote: > > I think you are very close to an Abstract/Introduction that is clearly > > comprehensible to people who are not familiar with DMARC. > > Considering this is an extension to DMARC, I don't think that's the target > audience. > As an individual: everyone who reads the document stand-alone gets confused by this lack of clarity (it's the common thread through all the last call reviews so far), and a concise summary up top feels valuable both for this evaluation process, and for any future consumers of the document. Whether someone's familiar with DMARC or not, if they're reading this document, what's the harm in spelling it out very clearly, especially if we have text that we believe accomplishes this? Seth --000000000000a6008705a36010ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2020 at 7:45 PM Scott Kitterm= an <scott@kitterman.com> w= rote:
> I think you are very close to an Abstract/Introduction that is clearly=
> comprehensible to people who are not familiar with DMARC.

Considering this is an extension to DMARC, I don't think that's the= target
audience.

As an individual: everyone wh= o reads the document stand-alone gets confused by this lack of clarity (it&= #39;s the common thread through all the last call reviews so far), and a co= ncise summary up top feels valuable both for this evaluation process, and f= or any future consumers of the document. Whether someone's familiar wit= h DMARC or not, if they're reading this document, what's the harm i= n spelling it out very clearly, especially if we have text that we believe = accomplishes this?=C2=A0

Seth
--000000000000a6008705a36010ab-- From nobody Wed Apr 15 20:39: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 F127A3A0B9D; Wed, 15 Apr 2020 20:39:24 -0700 (PDT) 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 lBAQGGbSj0vR; Wed, 15 Apr 2020 20:39:23 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 26BDD3A0B9B; Wed, 15 Apr 2020 20:39:23 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id s195so1527979vkb.11; Wed, 15 Apr 2020 20:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2FD1KxDuquNkLhr3kr61HFLoMa/Dqp6S+mjBcP6sT2o=; b=f5tNjn3eaMjK89/jjkS94zVkbw5H5XRrDlvgI0ykhkOjYYL+aB4WSBey7COaIRPPcl uY6eF03dRIJI0aW75PJMwmmgK+wl8qh8l9RTVb8vjTA9BawnALHSaYJF3nxc7u/WJxxO XT8k+9WKo8qaOeKNV/l/DKV5XuuFKS5qfKmSxPebuQB4IACiXASoZ7/1NWI5hvx7B4+J 6BDYH90zgqZwLip+eYwlX2XgpGrRz/vV3QafBU6OYbi1wxdoVcy7DvVbR65kMUD4YuXH Ww+F1MEtp2Bd7DMFwkY+1T+YEpAEw/5c57iWxKuzkilflDgnBY7M8aok5Zcj99SsOizb r8gA== 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=2FD1KxDuquNkLhr3kr61HFLoMa/Dqp6S+mjBcP6sT2o=; b=A+o8XR25QFuRM0XHiTGkM2+tDZeSrpFoBOc93iB08xWL4g8IlOgNhlASmxNawFBaIR tZd9XhKHtbdGtezMM8bYNhZqOrTc27baHabse/aOVVW6xDhaBo2tweoqywTFyYqusTdd NCZE5pyyB9OF3jM1jx1PUiXuYpMBMMha+IpymOqAVFgMmj1M79xmoVyIRXbb6+md69vH aBGATLLqCmdmlDf6RKc4a1nIiJSFJtB23p3SUYzT812sefB/3D9U+SZANLfmTgZbYAJC /Rfc81qkUHg7092h6rxbMw+D+xmuRZLoBklXQ05pApjviBue2VEzvjVVO/a9XtcKvbVZ inew== X-Gm-Message-State: AGi0Puaivc9CH3ntKi345UDrWNg20NbMcC67W5biOnQyv/3eTo0uGG5k 1WzSZry0jT01kNVCadFi5fK3VLRrmgmiB00fVIU= X-Google-Smtp-Source: APiQypJELLpZD2j+Hxj7qb92tzxAwpw6bxHCdTs4slU3IZiv5v1RIywwNbvxeMZiNuI3MsL3dec+jSFA75uT9/7pgtk= X-Received: by 2002:ac5:c3ce:: with SMTP id t14mr11823197vkk.60.1587008361893; Wed, 15 Apr 2020 20:39:21 -0700 (PDT) MIME-Version: 1.0 References: <873694nosf.fsf@hobgoblin.ariadne.com> <5104491.njhNTWfIiN@sk-desktop> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 15 Apr 2020 20:39:11 -0700 Message-ID: To: Seth Blank Cc: Scott Kitterman , IETF DMARC WG , last-call@ietf.org, General Area Review Team , draft-ietf-dmarc-psd.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa926605a3602ddc" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 16 Apr 2020 03:39:25 -0000 --000000000000aa926605a3602ddc Content-Type: text/plain; charset="UTF-8" On Wed, Apr 15, 2020 at 8:31 PM Seth Blank wrote: > On Wed, Apr 15, 2020 at 7:45 PM Scott Kitterman > wrote: > >> > I think you are very close to an Abstract/Introduction that is clearly >> > comprehensible to people who are not familiar with DMARC. >> >> Considering this is an extension to DMARC, I don't think that's the >> target >> audience. >> > > As an individual: everyone who reads the document stand-alone gets > confused by this lack of clarity (it's the common thread through all the > last call reviews so far), and a concise summary up top feels valuable both > for this evaluation process, and for any future consumers of the document. > Whether someone's familiar with DMARC or not, if they're reading this > document, what's the harm in spelling it out very clearly, especially if we > have text that we believe accomplishes this? > +1. If even a small number of people (and the GenART review itself might be enough) thinks it's in need of this kind of improvement, I would be surprised if the IESG sends it back to the working group for revision. If the goal is to get this thing published so people can start conducting the experiment, putting the work in now can only help you. -MSK --000000000000aa926605a3602ddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Apr 15, 2020 at 8:31 PM Seth Blan= k <seth@sethblank.com> wrot= e:
On Wed, Apr 15, 2020 at 7:45 PM Scott Kitterman <scott@kitterman.com<= /a>> wrote:
> I think you are very close to an Abstract/Introduction that is clearly=
> comprehensible to people who are not familiar with DMARC.

Considering this is an extension to DMARC, I don't think that's the= target
audience.

As an individual: everyone wh= o reads the document stand-alone gets confused by this lack of clarity (it&= #39;s the common thread through all the last call reviews so far), and a co= ncise summary up top feels valuable both for this evaluation process, and f= or any future consumers of the document. Whether someone's familiar wit= h DMARC or not, if they're reading this document, what's the harm i= n spelling it out very clearly, especially if we have text that we believe = accomplishes this?

+1.=C2= =A0 If even a small number of people (and the GenART review itself might be= enough) thinks it's in need of this kind of improvement, I would be su= rprised if the IESG sends it back to the working group for revision.=C2=A0 = If the goal is to get this thing published so people can start conducting t= he experiment, putting the work in now can only help you.

-MSK
--000000000000aa926605a3602ddc-- From nobody Wed Apr 15 20: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 DC2D23A0BB0; Wed, 15 Apr 2020 20:42:40 -0700 (PDT) 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 4LO4XK5GYD5L; Wed, 15 Apr 2020 20:42:39 -0700 (PDT) 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 7CB7A3A0B9B; Wed, 15 Apr 2020 20:42:39 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id g24so1517987vsp.8; Wed, 15 Apr 2020 20:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ywLx5HsYQ+HvOAIghQfjc3K4xpP8kuBOlpNDQmxIDac=; b=BuoIAkfB2Rh6Y3cKUPO9Oz4PSDexf2wSQjhDct8K4K4NnZh/E6lgxJrQRMm41L9mOH 4q6d4LdXm1o4P8P5aqMkM/rckZAdoypGDKUbB8DaKoQgSyvWjAQDE4zWQ43JXMQ3wZaP jq2Q6bdirlJ4liO6LdDcs4UE+G1ZkMJHwipt8W7Kbp6ARI4dySxwe/gLvTFBDKn/LIFw kMov3Zhdb9QTyNuC3CUKKt8pF6x4yXq5hYqfbaWXfzvNyQxIkyuiZuVrBbGNYXp8Bm8Y NJ04wIFkA7utAyIZSSAS0vtyUJWL6Vr9o2QtNREFO/TkWhplmWXCX2+HLaZvLaGo6uba WYVw== 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=ywLx5HsYQ+HvOAIghQfjc3K4xpP8kuBOlpNDQmxIDac=; b=IdQdJd7nsdxZ8wfwvrvZaEdoD18oyCnPdd8IaQpZz2SWbZHBvVUjvuFBAc1QOe4oLL QX6mm03VZjNBHN/GFgXu2KTB0lEz9nMvX81vriIOvGfdAGT8hF6bt4v5VRvMYV056VLZ QJ91HMFFnrnVKDEf96wWSmPu9iiRp1HcfSz46tn0J/uBZ9b4QU0erfmE9FJx0s8eL9bp Yqqcr/3P6sKVanueDSOsfOkCcmpc0B9SItVcXi0QYi6/OI9XRcGp+XHUMtHyk8Vcrr+5 AUIWSD9SVrdr/5sd41yNL8aTnFICrDUtJpmmZxbxVKkhczVjCMcAlNhpk3/CY5ZQKrev DVrg== X-Gm-Message-State: AGi0PuZTUGgeclpjLgKNd9UQEiF99QgaT5I9ulsseYkBeTK18515gIU9 Bn2Smi7AdEnvJXoQP1R8h9++7kH7OLXKYZCUYYY= X-Google-Smtp-Source: APiQypIz5UhFXb+OTQ2TJbWh3c7x2RhF3b6AAT+KnhrODagSh5V8uKBGh5CghQ8PD1faN3oPyR9QQXM0H95IkYn5Tbw= X-Received: by 2002:a67:7c44:: with SMTP id x65mr7379773vsc.52.1587008558343; Wed, 15 Apr 2020 20:42:38 -0700 (PDT) MIME-Version: 1.0 References: <873694nosf.fsf@hobgoblin.ariadne.com> <5104491.njhNTWfIiN@sk-desktop> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 15 Apr 2020 20:42:26 -0700 Message-ID: To: Seth Blank Cc: Scott Kitterman , IETF DMARC WG , last-call@ietf.org, General Area Review Team , draft-ietf-dmarc-psd.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000602d8705a3603985" Archived-At: Subject: Re: [dmarc-ietf] 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: Thu, 16 Apr 2020 03:42:41 -0000 --000000000000602d8705a3603985 Content-Type: text/plain; charset="UTF-8" Apologies: On Wed, Apr 15, 2020 at 8:39 PM Murray S. Kucherawy wrote: > +1. If even a small number of people (and the GenART review itself might > be enough) thinks it's in need of this kind of improvement, I would be > surprised if the IESG sends it back to the working group for revision. If > the goal is to get this thing published so people can start conducting the > experiment, putting the work in now can only help you. > *wouldn't -MSK --000000000000602d8705a3603985 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies:

On Wed, Apr 15, 2020 at= 8:39 PM Murray S. Kucherawy <sup= eruser@gmail.com> wrote:
+1.=C2=A0 If ev= en a small number of people (and the GenART review itself might be enough) = thinks it's in need of this kind of improvement, I would be surprised i= f the IESG sends it back to the working group for revision.=C2=A0 If the go= al is to get this thing published so people can start conducting the experi= ment, putting the work in now can only help you.

*wouldn't

-MSK
<= /div>
--000000000000602d8705a3603985-- From nobody Wed Apr 15 20:43: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 861E93A0BB5; Wed, 15 Apr 2020 20:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ZXz0cR6n; dkim=pass (2048-bit key) header.d=kitterman.com header.b=HTdvVxrs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-B1Rdr9ttCd; Wed, 15 Apr 2020 20:43:53 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7843A0D16; Wed, 15 Apr 2020 20:43:44 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id CAC8CF80279; Wed, 15 Apr 2020 23:43:43 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1587008623; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : from; bh=AGeEE1pZPW/Lnb23YZ6BfuoIRc/NUNOTptzsq8VeG3c=; b=ZXz0cR6nbVVnqcKjPJ+shIRprk8EFJ1GhrGSrr8Z3xe5RytRuonAdn5tCJLiFlMO58rSx DI1V/M3SlmklEqXAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1587008623; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : from; bh=AGeEE1pZPW/Lnb23YZ6BfuoIRc/NUNOTptzsq8VeG3c=; b=HTdvVxrsVq5GJhH1y8Gsnf9NdPm/drvIPiBo2Q23a7Ry8aUW2BU3tjoET+nqZ7I7qxPmL Aq5Hg0Ou234uZ+zP7fn97fkxvMIdCx5Jo3cvfdH1Z+bhZ7ZpEUTr3KUqk+djwIqux4W+FMe 6V782dSBAtNODi6nGhuHUZPejaNYT3Fayq+R6Gi8ojghPFwjGupDZecq7KlBkBwunOJFuAc Es1uy8aPEmi1JVCrm8zdYJL4p5czh4BSrDS/+urKyMAFkGp1ftQRVPPtYraEGy9o/z0ltIC WUx+dOJQeOIIsjIoZoY95oZ07pwrniMaTr0fxQ3AXM4XnILY77B9b+ce8blQ== Received: from [192.168.1.184] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTPSA id 74457F80024; Wed, 15 Apr 2020 23:43:43 -0400 (EDT) Date: Thu, 16 Apr 2020 03:43:41 +0000 In-Reply-To: References: <873694nosf.fsf@hobgoblin.ariadne.com> <5104491.njhNTWfIiN@sk-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: last-call@ietf.org,IETF DMARC WG CC: gen-art@ietf.org,draft-ietf-dmarc-psd.all@ietf.org From: Scott Kitterman Message-ID: <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] [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: Thu, 16 Apr 2020 03:43:55 -0000 On April 16, 2020 3:30:59 AM UTC, Seth Blank wrote: >On Wed, Apr 15, 2020 at 7:45 PM Scott Kitterman >wrote: > >> > I think you are very close to an Abstract/Introduction that is >clearly >> > comprehensible to people who are not familiar with DMARC=2E >> >> Considering this is an extension to DMARC, I don't think that's the >target >> audience=2E >> > >As an individual: everyone who reads the document stand-alone gets >confused >by this lack of clarity (it's the common thread through all the last >call >reviews so far), and a concise summary up top feels valuable both for >this >evaluation process, and for any future consumers of the document=2E >Whether >someone's familiar with DMARC or not, if they're reading this document, >what's the harm in spelling it out very clearly, especially if we have >text >that we believe accomplishes this? Perhaps I'm too pessimistic, but I don't think it's possible to actually m= ake this clear to anyone that isn't familiar with RFC 7489 without essentia= lly turning this into a proto 7489bis=2E If you want to add it and are confident we aren't diving into a deep, deep= hole, I don't strongly object=2E Just let me know what to add=2E Scott K From nobody Thu Apr 16 07:29: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 057463A09A3 for ; Thu, 16 Apr 2020 07:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 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.248, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=ntCGjTDQ; dkim=pass (1536-bit key) header.d=taugh.com header.b=op9r1dfr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1LFC24Dk100 for ; Thu, 16 Apr 2020 07:29:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5153A09A2 for ; Thu, 16 Apr 2020 07:29:40 -0700 (PDT) Received: (qmail 7696 invoked from network); 16 Apr 2020 14:29:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1e0e.5e986bd3.k2004; bh=LcPTSSwxfKMAlAxk3rR66G8sw0hrr5s4qaGTxzZR6WE=; b=ntCGjTDQWAzBsYz4CR63jHwqdl7h1NDEOrULD5Os1/1mSTbjH3tieZbJZj0/W+Cr891Qv03lNcNZStFMmvbI6plsV018gwfupLpONSjVrAF40YqOoYzGLc71cz6E9P3B2E3Rtk8Z+fFUOCiQEyNJvUfwSgse99Vz71qPlZ1BtmhH8/gcd8ZF1IBUlUOA4Em+nC83jooAsN4tdBx8hr4Ulw7WOEjCJyxgEp2uTXB70ZNQatZKBjLNuMdKZviO5aAO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1e0e.5e986bd3.k2004; bh=LcPTSSwxfKMAlAxk3rR66G8sw0hrr5s4qaGTxzZR6WE=; b=op9r1dfrZJP1RamxmIYGyvrZ4zJNLmmGGrb+iOzpWs7IN9awnIkODq1PHg3UpedL7pW0hbrlXja7hZx1XVSRK94G1mgx8soWS+VNfukSeR1RnDumkVwMw0zk5gJQ+sOQzw96e3e54jU99SFmiwAPokBwik9e01M2OxAi+15+9BC+nH1cEe8MwtoWrv4eh5SigFW1klymETjcyCZKlqB/mH4594xCzB2b81Rv8UXW1nIXHaC6VNY9wDdefBv0JrJF Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 16 Apr 2020 14:29:38 -0000 Received: by ary.qy (Postfix, from userid 501) id CCD9517E8F5E; Thu, 16 Apr 2020 10:29:38 -0400 (EDT) Date: 16 Apr 2020 10:29:38 -0400 Message-Id: <20200416142938.CCD9517E8F5E@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: scott@kitterman.com In-Reply-To: <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [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: Thu, 16 Apr 2020 14:29:42 -0000 In article <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> you write: >Perhaps I'm too pessimistic, but I don't think it's possible to actually make this clear to anyone that isn't familiar >with RFC 7489 without essentially turning this into a proto 7489bis. I agree. Hence my suggestion last week to tear out all of the TLD stuff or move it into an appendix and just say this is the name above the Organizational domain which you can find into RFC 7489. The reality is that any of the 8000 domains in the PSL could publish a PSD record, and I would not want to try to explain to anyone in the IESG why most of them are there. So let's stay as far away from that as possible. Policy Super Domain, remember? R's, John From nobody Thu Apr 16 12:21: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 699E63A0EE2 for ; Thu, 16 Apr 2020 12:21:17 -0700 (PDT) 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 Fdblkn0UDQIz for ; Thu, 16 Apr 2020 12:21:10 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950F63A0ED9 for ; Thu, 16 Apr 2020 12:21:10 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id z12so8023388ilb.10 for ; Thu, 16 Apr 2020 12:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IOEq/3mCN1AitjqaDqxr19Pdjy08edrAuqu8dNlG+3M=; b=UE1u0M82+KyktBnmDjfduTxkJqphgjR6vxodBSi5IQdCyaaAm53t2/QH9vbc+OdrJE GOiFt0HSvOWLkg+cNt0mU+e/sO3yqkYgUOBz0UsCf+ZIhcgxgJAzTWDdn0rH/vm9FGWn Svt/pzp2ho3hV5+e5Fvv7Zt39/qSODU4+H4fk= 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=IOEq/3mCN1AitjqaDqxr19Pdjy08edrAuqu8dNlG+3M=; b=pCu9n4EcV6CYGChrX8WYyzPhtt23GapOvK1FObMWLXeTGRLT0UEoHCijRUzqKletn0 n3oBuV1EV6NWxgwaSrtyEZYh8r5Xdl+aCZ5kwBprM00proYchR4SkelPQCNuWOO/7wPa zdlSS6O2dXeSAHrxv8l72NinAGuON7MX011LtF0OGASWS7RWonq/j98IQ6IUKe7deso1 wVFaxUli12TuClJm3v3DQPEGl8P2Dpkh0BUH9IkKnnYpM4L9Wpi2NjLOaSNLTmWm1l1A 4KW1kVeImZItaYnXDNRdFHFJDT9+sxt6l2jVxfJ8Rpoi/OCWcRtVP9WmzIljdTrXWcfb kdvQ== X-Gm-Message-State: AGi0PuYu1blnR7+4Gw5veAwgObsFksdlNjTSycJTrHGA+Zr8NhFuYx8U mW+h0+vVdMBZMfe2GZaTnYyt6zQnkh9AyuWHoZudbgijBew= X-Google-Smtp-Source: APiQypLWXpOiuhN39MwuFZQ7+tCJdyv+0fOLQtoJCjenedJjs+ZuzP3mfl6huB5xa2kVX3D4PEcHN5hLcdwqYMreKIA= X-Received: by 2002:a92:7301:: with SMTP id o1mr12528152ilc.104.1587064869509; Thu, 16 Apr 2020 12:21:09 -0700 (PDT) MIME-Version: 1.0 References: <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> <20200416142938.CCD9517E8F5E@ary.qy> In-Reply-To: <20200416142938.CCD9517E8F5E@ary.qy> From: "Kurt Andersen (b)" Date: Thu, 16 Apr 2020 12:20:51 -0700 Message-ID: To: John Levine Cc: "dmarc@ietf.org" , Scott Kitterman Content-Type: multipart/alternative; boundary="000000000000c875a405a36d55ea" Archived-At: Subject: Re: [dmarc-ietf] [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: Thu, 16 Apr 2020 19:21:18 -0000 --000000000000c875a405a36d55ea Content-Type: text/plain; charset="UTF-8" On Thu, Apr 16, 2020 at 7:29 AM John Levine wrote: > In article <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> you write: > >Perhaps I'm too pessimistic, but I don't think it's possible to actually > make this clear to anyone that isn't familiar > >with RFC 7489 without essentially turning this into a proto 7489bis. > > I agree. Hence my suggestion last week to tear out all of the TLD > stuff or move it into an appendix and just say this is the name above > the Organizational domain which you can find into RFC 7489. > > The reality is that any of the 8000 domains in the PSL could publish a > PSD record, and I would not want to try to explain to anyone in the > IESG why most of them are there. So let's stay as far away from that > as possible. Policy Super Domain, remember? After an initial "that's too cutesy" reaction, I'm becoming more convinced that John's suggestion ("policy super domain") might indeed be the right sort of solution - along with clearly citing 7489 in the intro and abstract ("If you don't know what DMARC is, go read RFC 7489 before coming back here." or similar). --Kurt --000000000000c875a405a36d55ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 16, 2020 at 7:29 AM John Levi= ne <johnl@taugh.com> wrote:
In article <4666D39F-85F5-4AD2-A754-11FED0A5C169= @kitterman.com> you write:
>Perhaps I'm too pessimistic, but I don't think it's possibl= e to actually make this clear to anyone that isn't familiar
>with RFC 7489 without essentially turning this into a proto 7489bis.
I agree.=C2=A0 Hence my suggestion last week to tear out all of the TLD
stuff or move it into an appendix and just say this is the name above
the Organizational domain which you can find into RFC 7489.

The reality is that any of the 8000 domains in the PSL could publish a
PSD record, and I would not want to try to explain to anyone in the
IESG why most of them are there.=C2=A0 So let's stay as far away from t= hat
as possible.=C2=A0 Policy Super Domain, remember?

=C2=A0After an initial "that's too cutesy" reaction, I= 'm becoming more convinced that John's suggestion ("policy sup= er domain") might indeed be the right sort of solution - along with cl= early citing 7489 in the intro and abstract ("If you don't know wh= at DMARC is, go read RFC 7489 before coming back here." or similar).

--Kurt=C2=A0
--000000000000c875a405a36d55ea-- From nobody Tue Apr 21 09:11: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 BC3E63A0D2D for ; Tue, 21 Apr 2020 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=ccqhmneG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=pGorNkeu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDqivp9P23w4 for ; Tue, 21 Apr 2020 09:11:11 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BD03A0D41 for ; Tue, 21 Apr 2020 09:11:02 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id 04D33F80308 for ; Tue, 21 Apr 2020 12:11:01 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1587485460; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=Zaw6TawD13DFS//fWxtmYwE74rRZflnKFHuGIXAywUk=; b=ccqhmneG7JYeeezmmswz5F5km1UhMGQxvHrV2PWkUV8AEuPVQhoorNEezWchU9gVD3sQ+ D70uHpFZCzOZPBNDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1587485460; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : content-type : from; bh=Zaw6TawD13DFS//fWxtmYwE74rRZflnKFHuGIXAywUk=; b=pGorNkeuPpd6QMB8nI+6i3Q163gOwrXAoLUZbocG6kE2/NYb5ZmU48PjZO3/9xX9gag38 Ez1vVA4RaoInLBYXjsVJXT2V0UeUFh7mmW87Z4L8v80Krf17KronLgAr9Wowi/t7gfk4QVS W34ERs0U9Up0OW4bvIJBRyKcgZxhjb83l3yCQAN5B/l45LHeJiK6g0jv/I1IdadYDJ1uady alXcUymMi13fwIs/w86GWgCqAYAMlhLySrDgatBYgnOj9h28oh83ZvLr6OijZCk1i6e9UgC pIyHu20FbwssOSwYGpC5P7kDc+leV/OEXHoqfzy8TeyjJAjzMsUNfeSNiKlg== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id CD11BF800E7 for ; Tue, 21 Apr 2020 12:11:00 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 21 Apr 2020 12:11:00 -0400 Message-ID: <2656238.kvSPeydUtl@sk-desktop> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Apr 2020 16:11:14 -0000 There is probably protocol improvement work that should be done based on: https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf Scott K From nobody Tue Apr 21 11:12: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 98B943A0949 for ; Tue, 21 Apr 2020 11:12:10 -0700 (PDT) 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 29NNfaMpkz30 for ; Tue, 21 Apr 2020 11:12:08 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800A83A0942 for ; Tue, 21 Apr 2020 11:12:07 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id w6so9943773ilg.1 for ; Tue, 21 Apr 2020 11:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PPRUD0Rsy17eLdouzK/wKCCGN8abaOLGf9QKLCZJMno=; b=Huw7oni4726rarb9r7x9kVDeTMv2/cQN9iar4xnrMXVkm7kqQnRfZ5H1K+fQMxCKL4 9Xe/RDncXKS7toK3wVunGHhq839EcIIzwNqeURzOj4Oi+nknkpbzKJOd4XKGJVb07B9W Pd07KRK9p06npBsufachg4HPn4Yzy6Tz3+mZE= 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=PPRUD0Rsy17eLdouzK/wKCCGN8abaOLGf9QKLCZJMno=; b=EcOzGSpcj4lE4r6N0TrHjVEkQXsB2tvMPNvrBxJAAemFwp7ZB35DLhM2ZHkjIPf+GC yUtyTiHpxCXLhcnKsMJDw5JVpvHn1x6SdDc7kkTNeZ4frMm9Umkk3/KHc8tDKOpTyYpy dSqJA0SGpAUPvbYMsPmWrBFVWZGGtZCQKKyHfkCP1kBgUVZLduJq+XOg6PSpQSDYdo7M 6RKrBkfDGobk+sHuE99tsCUqSUaSTmfXeNFa699lqbF/7Hw+8naPcrBHmXEPq2MDEAeu TAKlRsOpxzLiJys4uPvshqclFVTeuVWblEAu/iL8vxUcBIud79/UPpUirHMDGiPX7yc6 JYwA== X-Gm-Message-State: AGi0PuYEgGm2w4O9ZAj9ZMYDhQswa/SW3cRfeFOr0mwTlC+mrXwELapO i86Sl8pl8wfOC9wz1RB1H2GpxYfiw4fDD3YVRTP1oCAO/Rwhyw== X-Google-Smtp-Source: APiQypJlPGCN2RArMazBLXcYjESQzdOwUvFBlcibgGO85grK0J/ZE+iUZ8+DksZxgEf3wz9K/zulIlFJ8z/QwaWfIJI= X-Received: by 2002:a92:d44b:: with SMTP id r11mr21818222ilm.120.1587492726276; Tue, 21 Apr 2020 11:12:06 -0700 (PDT) MIME-Version: 1.0 References: <2656238.kvSPeydUtl@sk-desktop> In-Reply-To: <2656238.kvSPeydUtl@sk-desktop> From: "Kurt Andersen (b)" Date: Tue, 21 Apr 2020 11:11:47 -0700 Message-ID: To: Scott Kitterman Cc: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary="00000000000008b3a505a3d0f406" Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Apr 2020 18:12:12 -0000 --00000000000008b3a505a3d0f406 Content-Type: text/plain; charset="UTF-8" Extracting from the abstract of a paper in process by Casey Deccio (now researching SPF at BYU, formerly at Cisco): Our techniques elicit SPF and DMARC validation activity of the servers, > while minimizing spam and perceived abuse. We find that only 25% of mail > servers and less than half of domains deploy SPF validation. Of domains > that perform SPF validation, 7.6% exhibit inconsistent validation behavior > across mail servers. We also find that 75% of organizations with mail > servers for popular domains share DNS infrastructure with up to tens of > thousands of others. Most of his focus has been on SPF but it would be useful to loop him into the DMARCbis discussions. --Kurt On Tue, Apr 21, 2020 at 9:11 AM Scott Kitterman wrote: > There is probably protocol improvement work that should be done based on: > > https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --00000000000008b3a505a3d0f406 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Extracting from the abstract of a paper in process by Case= y Deccio (now researching SPF at BYU, formerly at Cisco):

Our techniques elicit SPF an= d DMARC validation activity of the servers, while minimizing spam and perce= ived abuse. We find that only 25% of mail servers and less than half of dom= ains deploy SPF validation. Of domains that perform SPF validation, 7.6% ex= hibit inconsistent validation behavior across mail servers. We also find th= at 75% of organizations with mail servers for popular domains share DNS inf= rastructure with up to tens of thousands of others.

Most of his focus has been on SPF but it would be useful to loop h= im into the DMARCbis discussions.

--Kurt

On T= ue, Apr 21, 2020 at 9:11 AM Scott Kitterman <scott@kitterman.com> wrote:
There is probably protocol improvement wor= k that should be done based on:

https://www.usenix.org/system= /files/sec20fall_chen-jianjun_prepub_0.pdf

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--00000000000008b3a505a3d0f406-- From nobody Tue Apr 21 11:23: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 982D13A0988 for ; Tue, 21 Apr 2020 11:23:46 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=PjcQTJvb; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZbaXuEjT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqkOzBQ4VVfQ for ; Tue, 21 Apr 2020 11:23:44 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F27A3A0C19 for ; Tue, 21 Apr 2020 11:22:44 -0700 (PDT) Received: (qmail 50436 invoked from network); 21 Apr 2020 18:22: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:mime-version:content-type:content-transfer-encoding; s=c502.5e9f39f2.k2004; bh=Ki6kFOZU1oTr9qc9AwW8Lb/vvNxVsZCB+o0/+/kd2A8=; b=PjcQTJvbkPk15ivokqV1bjV0WunyERWnzPXsmfHRRqowE6Ntxi91Fvj9GyXRPXljmUOkZkBIpo32w6krmXQhrt2qQh18tgjLCXfNxgdLqmDtHLofNOFeMuVf71Z4u97zcYLIGccDyAaYnLdPRkWyakD8Tlk71R78YIL/sroN/DseL7/BGiRNPHTUoywk7c8EzVQxQDgbWZSY7fApchmOyggS5aBt93w/pZLuM7W7I8AJkWXIWj1RjdCCm5Rfv/g7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=c502.5e9f39f2.k2004; bh=Ki6kFOZU1oTr9qc9AwW8Lb/vvNxVsZCB+o0/+/kd2A8=; b=ZbaXuEjTNGZnhbNUnk5dY94kpuVczbEQ6ksNb0RVR0QlMmjSBxQP2fjcTC7ztpvjEYuD5N7o6tK0DaGA+vIIqsDHg4I+EPIyX9CQ/6HFrI/VaBqb0Peksc1uAlPVmHehdchRT3pBSNWFX9LX3vTaCU3GrqAw0fV8lyruPaqj21IgC2/Ag+kO8qWZcZCn1BrgnnodK7Z7J1MLQYj2DoJ1Rt+3lgBxymCWwW8PBsTphGLSiPZrJdCz8brlr8G+lk5b Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 21 Apr 2020 18:22:42 -0000 Received: by ary.qy (Postfix, from userid 501) id 15AEB181144D; Tue, 21 Apr 2020 14:22:41 -0400 (EDT) Date: 21 Apr 2020 14:22:41 -0400 Message-Id: <20200421182242.15AEB181144D@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: scott@kitterman.com In-Reply-To: <2656238.kvSPeydUtl@sk-desktop> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 21 Apr 2020 18:23:47 -0000 In article <2656238.kvSPeydUtl@sk-desktop> you write: >There is probably protocol improvement work that should be done based on: > >https://www.usenix.org/system/files/sec20fall_chen-jianjun_prepub_0.pdf I didn't see any protocol issues other than the well known DKIM multiple From: headers (the Doug Otis feature) and l=. They certainly did find a lot of implementation bugs, some of which I found pretty surprising, like Gmail allowing and misinterpreting NUL characters in DKIM signature headers. This sounds like we need more test suites and perhaps more reminders that when you're writing security software, being forgiving of other people's bugs will backfire on you. R's, John From nobody Tue Apr 21 18:22: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 D00C13A090C for ; Tue, 21 Apr 2020 18:22:00 -0700 (PDT) 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 cVo0DH7bms8o for ; Tue, 21 Apr 2020 18:21:59 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 583473A0902 for ; Tue, 21 Apr 2020 18:21:58 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id R3t3jB4HND4wER45OjWs7r; Wed, 22 Apr 2020 01:21:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1587518518; bh=nVKfE6iwmi0q2OHWXdTyXfQpzpSnw5GPOHcqSzrKl3c=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=AnRPpNjMCaaywn98hTBelAav/Gt0H35tWeNCblnViEbhJIBMVf1OpqpyfNxZ7EZru TFP7MVtk6xsZ+ARDhFryF8apqBG3fu2SDnqjli/61fLgWjB0MOBY2/hI5p25x/Kbvs k+SSCMQtEaJQr14Cjg5hxaWoHPuee4qsmX6OUIy5wv3f8o5mLLh9Ndo1UIE3xjGikY ZNNgWR9KuusdxYHIjgePhiZGq6KJWAmFeS23BkBIOqZaxbeOmMwyMdb9M2k6s18K0J 53iYwXO4oxTlyub3oF9FTVTf+biUSySmHst6s2xGNz2MtPUhLgvy5yP7aWN+1rG+1/ cxQ2qUXpOi2jg== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-11v.sys.comcast.net with ESMTPA id R45JjkMHVvcxUR45MjIrCj; Wed, 22 Apr 2020 01:21:57 +0000 X-Xfinity-VMeta: sc=-100.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 03M1Lq0r017103; Tue, 21 Apr 2020 21:21:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 03M1LpC2017092; Tue, 21 Apr 2020 21:21:51 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Scott Kitterman Cc: last-call@ietf.org, dmarc@ietf.org, gen-art@ietf.org, draft-ietf-dmarc-psd.all@ietf.org In-Reply-To: <4666D39F-85F5-4AD2-A754-11FED0A5C169@kitterman.com> (scott@kitterman.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Apr 2020 21:21:50 -0400 Message-ID: <871rogwc0h.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: Wed, 22 Apr 2020 01:22:01 -0000 Scott Kitterman writes: > [important discussion clipped for brevity] > If you want to add it and are confident we aren't diving into a deep, > deep hole, I don't strongly object. Just let me know what to add. Well, my review amounted to about 5 pages of ordinary text, and my follow-up e-mail about a page and a half. If I was unclear regarding what I thought should be done to make the document clearer to the unsophisticated reader, please get back to me so that I can improve my review style. Dale From nobody Wed Apr 22 13:28: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 5BF413A0915 for ; Wed, 22 Apr 2020 13:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 w3oZbJVeUwXM for ; Wed, 22 Apr 2020 13:28:50 -0700 (PDT) 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 D1CD13A090E for ; Wed, 22 Apr 2020 13:28:50 -0700 (PDT) Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 03MKUcNc022887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Apr 2020 13:30:38 -0700 From: Dave Crocker Reply-To: dcrocker@bbiw.net To: dmarc@ietf.org References: <2656238.kvSPeydUtl@sk-desktop> Organization: Brandenburg InternetWorking Message-ID: <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> Date: Wed, 22 Apr 2020 13:28:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <2656238.kvSPeydUtl@sk-desktop> Content-Type: multipart/alternative; boundary="------------0DF52F749A3E4F34FCD241FF" Content-Language: en-US Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Apr 2020 20:28:56 -0000 This is a multi-part message in MIME format. --------------0DF52F749A3E4F34FCD241FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The paper concerns valid authentication and effective use of authenticated information.  That's an excellent goal.  The paper offers extensive technical analyses and empirical demonstrations of operational failures. Exercises like these are valuable and too infrequent.  Besides prompting specific repairs, work like this should motivate careful industry review of systems-level issues and standards-based documentation. The paper does not adequately distinguish between claims of protocol design/specification errors, versus implementation errors, yet that distinction is essential. The paper has a simplistic model of email anti-abuse processing and this distorts some of its analysis.  At the least, the paper needs to distinguish between theory and practice. The paper has a flawed model of the role of recipient users in anti-abuse work and therefore the paper makes a basic error in its assessment of the importance of From: field validation. The paper identifies a number of significant implementation deficiencies in various system. Detailed comments: > to authenticate the sender’s purported identity, as the basis for > displaying in email clients assurances of validity to userswhen they > read messages That's a rather basic misunderstanding of how these mechanisms are actually used. > In practice, attackers usually exploit SMTPby running their own email > servers or clients. This is largely a non-sequitur.  It has built-in assumptions that aren't explained and are wrong with respect to any of the domain name-based protection mechanisms.  (And it isn't SMTP that is being exploited, per se. That's like saying that if I send a postal letter purporting to be the president of the United States, I've exploited the postal system. ) > SMTP’s design includes multiple “identities” when handling messages. Since this has been documented, they should cite it, for background. > Both theMAIL FROMandFromheadersidentify the email sender, but they > have different meaningsin an SMTP conversation. The first represents > the user whotransmittedthe message, and is usually not displayed to > therecipient. It would be clearer and more helpful to say 'operator' or 'service provider' rather than 'user'.  A separate issue is whether their characterization of the differences between the two identifiers is valid in practice... The paper uses sender in a way that encourages confusion in the reader.  Especially since this is a technical paper, it should use language that carefully distinguishes roles, especially since terminology for making these distinctions is readily available. > In addition, SMTP introduces multiple other sender identi-ties, such > as theHELOcommand,SenderandResent-Fromheaders. I suspect that the failure to cite DKIM's d= field , until later, is a significant oversight. > http://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt heh.  the URL isn't valid.  Should be: https://www.ietf.org/archive/id/draft-blank-ietf-bimi-00.txt > DKIM.DomainKeys Identified Mail (DKIM) uses cryp-tography to > authenticate senders... I'm being too picky, right?  Formal DKIM semantics don't produce exactly that result. > The general idea behind DKIM is to let senders sign parts ofmessages > so that receivers can validate them. This is poorly written, wrong, or both.  'them' is ambiguous.  And the signing is to affix the d= value, not to validate any of the data that is part of the signature. > it only need to have the same registered domain Will typical readers understand what this means, in the context of this paper, since all of the domain name's components are 'registered'? It's not obvious what language would make the meaning clearer. > If the email passes theDMARC verification, it enters the user’s inbox. This is simply wrong.  It needs to place this phase of processing inside a complex filtering engine, which is the primary venue for using any of the mechanisms discussed in the paper. > usually the MUA only displays theFromheader as the message sender. These days, this isn't true either.  Most users only see the un-validated Display-Name. > Thus, theFromheaderprovides the key identity relevant for gaining the > user’s trust On its face, this seems a reasonable view.  In practice, it isn't.  Mail with obviously bogus email addresses in the rfc5322.From field are still effective for phishing, because what real users actually pay attention to is the body of the message and the identification information in it.  That's why assertions about the display of validated source/author information to the end user are demonstrably wrong. > Malicious usersof legitimate email providers exploit thefailure of > some email providers to perform sufficient valida-tion of emails > received from local MUAs. These attackers cansend emails with > spoofedFromheaders. The exploited emailproviders may automatically > attach DKIM signatures to theiroutgoing emails, enabling the attackers > to impersonate otherusers of the email provider The writing of the paragraph's conclusion seems to be fundamentally misleading or wrong.  It seems to be saying that the DKIM signature will be for the domain in the From: field, which it won't. > Security requirement.To achieve this goal, I'm not sure exactly what goal they are referring to. > (1) TheFromheader of the email thatSsends matches theauthenticated > username (other users ofScannot spoof Alice’saddress); This requirement applies only in the presence of DMARC. > (3) SPF/DKIM and DMARCcomponents inRconsistently authenticate the same > identifier Except that SPF and DKIM are permitted to validate other identifiers, not just the one in the rfc5322.From field. > This require-ment, although intuitive, implies a set of semantic > bindingrelations that every component in the email processing > chainmust respect. This is imposing a requirement for deep, internal systems knowledge about features that are not, in fact, deeply embedded in email history or processing.  Arguably, the demand for having every component enforce this model is a basic mistake. Rather the requirement is to prevent assumptions inside the system that serve to violate the policies needed at evaluation points. > robust principle robustness https://en.wikipedia.org/wiki/Robustness_principle > be permissive in how they process malformed inputs No, Postel did not direct accepting 'malformed' inputs. And RFC 1122, Section 1.2.2 elaborated on this issue very helpfully: > Software should be written to deal with every conceivable > error, no matter how unlikely; > 4.1 HELO/MAIL FROM confusion This seems to imply that tightening is needed in DMARC, so that it uses an SPF domain that SPF has actually been validated? I think the issue is that SPF validation needs to inform DMARC what domain it has validated, rather than have DMARC decide which domain to fetch. > SPF implementations treat “(any@legitimate.com” as anempty MAIL FROM > address, and thus forward the resultsof checking HELO to the DMARC > component, because thestring in the parentheses can be parsed as a > comment ac-cording to RFC 5322 [10]. Some DMARC > implementations,however, may take it as a normal non-empty address, 1. This issues goes away if SPF supplies DMARC the domain name, rather than DMARC having to fetch it 2. I doubt this otherwise needs changes to language in the DMARC spec, but it's worth making sure. > 4.3 Authentication results injection Another focus on what results are communicated and how. The paper asserts that AR is used as DMARC input.  I suspect that is rarely, if ever, true.  Yes? No? > Generally, we can divideFromheader-relatedprocessing into two phases: > 1) parsing a MIME message to extract the Fromheader; The rfc5322.From: field is independent of MIME. MIME pertains only to the body. > Microsoft:disregarded our report (which included our pa-per and a > video5demoing theA10attack) because the threatsrely on social > engineering, which they view as outside thescope of security > vulnerabilities. That's oddly impressive. > Improving MUA display ... > We note however that experiences with suchapproaches for promoting > HTTPS (via browsers displayingtrusted icons for websites with valid > TLS certificates) havedemonstrated the challenges of ensuring that > users correctlyinterpret the icons and do not get fooled by imposters "Challenges" is incorrect.  "Failure to be useful" is more appropriate language. -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------0DF52F749A3E4F34FCD241FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
The paper concerns valid authentication and effective use of authenticated information.  That's an excellent goal.  The paper offers extensive technical analyses and empirical demonstrations of operational failures. Exercises like these are valuable and too infrequent.  Besides prompting specific repairs, work like this should motivate careful industry review of systems-level issues and standards-based documentation.

The paper does not adequately distinguish between claims of protocol design/specification errors, versus implementation errors, yet that distinction is essential.

The paper has a simplistic model of email anti-abuse processing and this distorts some of its analysis.  At the least, the paper needs to distinguish between theory and practice. 

The paper has a flawed model of the role of recipient users in anti-abuse work and therefore the paper makes a basic error in its assessment of the importance of From: field validation.

The paper identifies a number of significant implementation deficiencies in various system.


Detailed comments:

to authenticate the sender’s purported identity, as the basis for displaying in email clients assurances of validity to users when they read messages

That's a rather basic misunderstanding of how these mechanisms are actually used.


In practice, attackers usually exploit SMTPby running their own email servers or clients.

This is largely a non-sequitur.  It has built-in assumptions that aren't explained and are wrong with respect to any of the domain name-based protection mechanisms.  (And it isn't SMTP that is being exploited, per se. That's like saying that if I send a postal letter purporting to be the president of the United States, I've exploited the postal system. )


SMTP’s design includes multiple “identities” when handling messages.
Since this has been documented, they should cite it, for background.


Both theMAIL FROMandFromheadersidentify the email sender, but they have different meaningsin an SMTP conversation. The first represents the user whotransmittedthe message, and is usually not displayed to therecipient.
It would be clearer and more helpful to say 'operator' or 'service provider' rather than 'user'.  A separate issue is whether their characterization of the differences between the two identifiers is valid in practice... The paper uses sender in a way that encourages confusion in the reader.  Especially since this is a technical paper, it should use language that carefully distinguishes roles, especially since terminology for making these distinctions is readily available.


In addition, SMTP introduces multiple other sender identi-ties, such as theHELOcommand,SenderandResent-Fromheaders.

I suspect that the failure to cite DKIM's d= field , until later, is a significant oversight.


http://www.ietf.org/internet-drafts/draft-blank-ietf-bimi-00.txt

heh.  the URL isn't valid.  Should be:

   https://www.ietf.org/archive/id/draft-blank-ietf-bimi-00.txt


DKIM.DomainKeys Identified Mail (DKIM) uses cryp-tography to authenticate senders...

I'm being too picky, right?  Formal DKIM semantics don't produce exactly that result.


The general idea behind DKIM is to let senders sign parts ofmessages so that receivers can validate them.
This is poorly written, wrong, or both.  'them' is ambiguous.  And the signing is to affix the d= value, not to validate any of the data that is part of the signature.


it only need to have the same registered domain

Will typical readers understand what this means, in the context of this paper, since all of the domain name's components are 'registered'? It's not obvious what language would make the meaning clearer.


If the email passes theDMARC verification, it enters the user’s inbox.

This is simply wrong.  It needs to place this phase of processing inside a complex filtering engine, which is the primary venue for using any of the mechanisms discussed in the paper.

usually the MUA only displays theFromheader as the message sender.

These days, this isn't true either.  Most users only see the un-validated Display-Name.


Thus, the From header provides the key identity relevant for gaining the user’s trust

On its face, this seems a reasonable view.  In practice, it isn't.  Mail with obviously bogus email addresses in the rfc5322.From field are still effective for phishing, because what real users actually pay attention to is the body of the message and the identification information in it.  That's why assertions about the display of validated source/author information to the end user are demonstrably wrong.


Malicious usersof legitimate email providers exploit thefailure of some email providers to perform sufficient valida-tion of emails received from local MUAs. These attackers cansend emails with spoofedFromheaders. The exploited emailproviders may automatically attach DKIM signatures to theiroutgoing emails, enabling the attackers to impersonate otherusers of the email provider

The writing of the paragraph's conclusion seems to be fundamentally misleading or wrong.  It seems to be saying that the DKIM signature will be for the domain in the From: field, which it won't.


Security requirement.To achieve this goal,

I'm not sure exactly what goal they are referring to.


(1) TheFromheader of the email thatSsends matches theauthenticated username (other users ofScannot spoof Alice’saddress);


This requirement applies only in the presence of DMARC.


(3) SPF/DKIM and DMARCcomponents inRconsistently authenticate the same identifier


Except that SPF and DKIM are permitted to validate other identifiers, not just the one in the rfc5322.From field.


This require-ment, although intuitive, implies a set of semantic bindingrelations that every component in the email processing chainmust respect.


This is imposing a requirement for deep, internal systems knowledge about features that are not, in fact, deeply embedded in email history or processing.  Arguably, the demand for having every component enforce this model is a basic mistake.

Rather the requirement is to prevent assumptions inside the system that serve to violate the policies needed at evaluation points.


> robust principle

robustness

https://en.wikipedia.org/wiki/Robustness_principle


be permissive in how they process malformed inputs


No, Postel did not direct accepting 'malformed' inputs.

And RFC 1122, Section 1.2.2 elaborated on this issue very helpfully:

Software should be written to deal with every conceivable
error, no matter how unlikely;


4.1 HELO/MAIL FROM confusion
This seems to imply that tightening is needed in DMARC, so that it uses an SPF domain that SPF has actually been validated? I think the issue is that SPF validation needs to inform DMARC what domain it has validated, rather than have DMARC decide which domain to fetch.


SPF implementations treat “(any@legitimate.com” as anempty MAIL FROM address, and thus forward the resultsof checking HELO to the DMARC component, because thestring in the parentheses can be parsed as a comment ac-cording to RFC 5322 [10]. Some DMARC implementations,however, may take it as a normal non-empty address,


1. This issues goes away if SPF supplies DMARC the domain name, rather than DMARC having to fetch it

2. I doubt this otherwise needs changes to language in the DMARC spec, but it's worth making sure.


4.3 Authentication results injection


Another focus on what results are communicated and how.

The paper asserts that AR is used as DMARC input.  I suspect that is rarely, if ever, true.  Yes? No?


Generally, we can divideFromheader-relatedprocessing into two phases: 1) parsing a MIME message to extract the From header;


The rfc5322.From: field is independent of MIME. MIME pertains only to the body.


Microsoft:disregarded our report (which included our pa-per and a video5demoing theA10attack) because the threatsrely on social engineering, which they view as outside thescope of security vulnerabilities.


That's oddly impressive.


Improving MUA display
...

We note however that experiences with suchapproaches for promoting HTTPS (via browsers displayingtrusted icons for websites with valid TLS certificates) havedemonstrated the challenges of ensuring that users correctlyinterpret the icons and do not get fooled by imposters


"Challenges" is incorrect.  "Failure to be useful" is more appropriate language.















-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--------------0DF52F749A3E4F34FCD241FF-- From nobody Wed Apr 22 15:08: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 C26663A0C06 for ; Wed, 22 Apr 2020 15:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=p0pJjaeJ; dkim=pass (2048-bit key) header.d=kitterman.com header.b=buX/k+by Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnE4Xyned8di for ; Wed, 22 Apr 2020 15:08:40 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E753A0BFA for ; Wed, 22 Apr 2020 15:08:40 -0700 (PDT) Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) by interserver.kitterman.com (Postfix) with ESMTPS id 2660EF802BF for ; Wed, 22 Apr 2020 18:08:38 -0400 (EDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1587593318; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=WiiJEeK5WQ341n9KOmM6B5zvPLovpymC7EOdK4skl7M=; b=p0pJjaeJB5tlFWlTb2r2D9Za9LCb6Mk1qKcl8FnfPpTt+uIbDq3ffa/kUO+Pz57lZrIho 3PeJFIcuPbsXwGwDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1587593318; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=WiiJEeK5WQ341n9KOmM6B5zvPLovpymC7EOdK4skl7M=; b=buX/k+by/x32umpWUPNeZbE3PHq2HV3JVkKP7WtAOOxI1kHCQZdsJNGoTq7R7wc1uzXDo 8lgqo0j2nAa5tbOdH9j4ys4TJC/F6dMWx102c0eCp2WpxjQKPrbB0wLWBhO216d9V4x164m mQfe04NX2/2XQEKWBLOvExgKR11X0nzEQAqbB7F5+GAc29Ok0GpmeWcMzw3lt+JJf35zx8F xZnnyzG59imZL87V2TifB3XnASy0hH79v5WWhNhga4lAdmkNBfaYDpHll621uIawKhlHax/ esuEGlUSipjuFC3CvDH76vR+kiW8AZIGuHeTPN4gbwxxGKj0ryF281+/0jog== Received: from sk-desktop.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by interserver.kitterman.com (Postfix) with ESMTP id E80C5F800E7 for ; Wed, 22 Apr 2020 18:08:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 22 Apr 2020 18:08:37 -0400 Message-ID: <5816941.mf8d9O40cs@sk-desktop> In-Reply-To: <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> References: <2656238.kvSPeydUtl@sk-desktop> <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 22 Apr 2020 22:08:48 -0000 On Wednesday, April 22, 2020 4:28:44 PM EDT Dave Crocker wrote: > > 4.1 HELO/MAIL FROM confusion >=20 > This seems to imply that tightening is needed in DMARC, so that it uses > an SPF domain that SPF has actually been validated? I think the issue is > that SPF validation needs to inform DMARC what domain it has validated, > rather than have DMARC decide which domain to fetch. The standard authentication results header field will do this in the form o= f: Authentication-Results: mx.example.org; spf=3Dpass smtp.mailfrom=3Dexample.= com > > SPF implementations treat =E2=80=9C(any@legitimate.com=E2=80=9D as anem= pty MAIL FROM > > address, and thus forward the resultsof checking HELO to the DMARC > > component, because thestring in the parentheses can be parsed as a > > comment ac-cording to RFC 5322 [10]. Some DMARC > > implementations,however, may take it as a normal non-empty address, >=20 > 1. This issues goes away if SPF supplies DMARC the domain name, rather > than DMARC having to fetch it >=20 > 2. I doubt this otherwise needs changes to language in the DMARC spec, > but it's worth making sure. I agree it's worth making sure. The input for DMARC from SPF/DKIM should a= =20 both a result and a domain. There is some inconsistency in how SPF verifiers report SPF results when us= ing=20 HELO as a fallback for an null Mail From. RFC 7208 section 2.4 is, IMO,=20 reasonably clear that for a null Mail From, the SPF 'Mail From' identity is= =20 postmaster@[HELO], so it should be reported as an smtp.mailfrom=3D result, = which=20 the paper claims is the threat vector. I think they are wrong. As long as= =20 the input domain is checked and is in alignment for DMARC, there's no issue= =20 there. I tried their exact scenario with two of my domains and here's what the SPF= =20 verifier reported: Authentication-Results: mx.example.org; spf=3Dpass (sender SPF authorized)= =20 smtp.mailfrom=3Dkitterman.com (client-ip=3D72.81.252.18; helo=3Dkitterman.o= rg;=20 envelope-from=3D(scott@kitterman.com; receiver=3Dbogus1@kitterman.org) While this is not ideal (for envelope-from=3D(scott@kitterman.com. The str= ing=20 should be quoted [per the 5322 CFWS definition], it shouldn't lead to any=20 confusion about the identity. I figured out this is wrong and the example below is right per various RFCs= ,=20 but it took some investigation to dig it all back up. A more thorough revi= ew=20 by someone that knows more than me would surely be a good idea. > > 4.3 Authentication results injection >=20 > Another focus on what results are communicated and how. >=20 > The paper asserts that AR is used as DMARC input. I suspect that is > rarely, if ever, true. Yes? No? =46or integration of open source components such as opendkim and opendmarc,= this=20 is the standard method of communicating results data between components (al= so=20 true for communicating SPF results to opendmarc is you don't use its intern= al=20 SPF implementation). =46or what it's worth, I invested some time yesterday and today testing the= =20 various open source components I maintain (pyspf, pyspf-milter, policyd-spf- python, dkimpy, dkimpy-milter, and authres) and found some behaviors in the= =20 cases they describe that is sub-optimal, I could not replicate any of the=20 security relevant issues they describe. I did get some new test cases. ... As an example, if the example they used is presented to the authres module = as=20 the d=3D domain in for a DKIM verification, d=3Dlegitimate.com(.attacker.co= m, it=20 returns d=3D"legitimate.com(.attacker.com" [note the quoting, which is corr= ect=20 per the 5322 CFWS definition]. If it's parsing that, it fails to return a= =20 domain at all, which is a bug, but doesn't cause the reported problem. Scott K From nobody Wed Apr 22 17:20: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 6E2E93A0EB7 for ; Wed, 22 Apr 2020 17:20:26 -0700 (PDT) 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 (1536-bit key) header.d=iecc.com header.b=bqijfj9P; dkim=pass (1536-bit key) header.d=taugh.com header.b=dj21EiDU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3VIvrFcZpAM for ; Wed, 22 Apr 2020 17:20:23 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F10D3A0EB5 for ; Wed, 22 Apr 2020 17:20:23 -0700 (PDT) Received: (qmail 13196 invoked from network); 23 Apr 2020 00:20: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; s=3389.5ea0df45.k2004; bh=Rb0Vho0eeN8qUfL3iMhTsf+A6uCsjoUROu2lwJDcr2k=; b=bqijfj9PmsjQHUTjP5aEUk3ozIBgMkbFuCo6vPcZrTNdh6B7QAjQixWm+hX1ILOXrzM3gj2Jjysq0hWHhHTwmIdERbHOEhD88hsBkHoirKTpZThiH1A6M0bABKJJmF0Y3xys+bOHLFGvqP0DlCHzI45L4jthYFtQmhJRkmL3Aqt8dpJ4LmpPdT6W2eCrXyPL4Cci0kgAq/+KjqDrSfG7EjFoQbJ4JkoWAAIUXW8VNY3htEqBbrOIt0fvhtsispu/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3389.5ea0df45.k2004; bh=Rb0Vho0eeN8qUfL3iMhTsf+A6uCsjoUROu2lwJDcr2k=; b=dj21EiDUU/GG4s11VcYiDeoSRZnWyFnZsyirjvrnynDkFSOnhzi39SLiVch5VozWo7mF3Q93JUXoZxhS2FoCOQ3J7OgjvfF/8U7SxXwZpSbfQWfZy/tkcTnCvg8jJ1QrVYIJ0uT+FkqnLY3XRH3ETHQi7hFB3wWXLcVrKsqioCHXRcc2RvhTTwM1HY/22ukB8raF3Ro2gj2EkFwQADCCuUs4xNuZte+gc6angItCfjo37lu2hankP6t08QL+VVI5 Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 23 Apr 2020 00:20:20 -0000 Received: by ary.qy (Postfix, from userid 501) id BAB07181BB09; Wed, 22 Apr 2020 20:20:20 -0400 (EDT) Date: 22 Apr 2020 20:20:20 -0400 Message-Id: <20200423002020.BAB07181BB09@ary.qy> From: "John Levine" To: dmarc@ietf.org Cc: dcrocker@bbiw.net In-Reply-To: <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Apr 2020 00:20:26 -0000 In article <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> you write: >The paper has a simplistic model of email anti-abuse processing and this >distorts some of its analysis.  At the least, the paper needs to >distinguish between theory and practice. Yup. >> SPF implementations treat “(any@legitimate.com” as anempty MAIL FROM >> address, and thus forward the resultsof checking HELO to the DMARC >> component, because thestring in the parentheses can be parsed as a >> comment ac-cording to RFC 5322 [10]. Some DMARC >> implementations,however, may take it as a normal non-empty address, > >1. This issues goes away if SPF supplies DMARC the domain name, rather >than DMARC having to fetch it Their assumptions about DMARC validators may be true in some cases but not in general. In OpenDMARC which is pretty widely used, the caller tells the DMARC library what domain SPF checked, whether it was the mail_from or helo, and what the result was. >The paper asserts that AR is used as DMARC input.  I suspect that is >rarely, if ever, true.  Yes? No? I'd say never. To do DMARC rejects you have to do all of the validation in the SMTP daemon, which is before anything has a chance to create an A-R header. >The rfc5322.From: field is independent of MIME. MIME pertains only to >the body. The display name can be a MIME encoded word, but that has nothing to do with parsing the MIME parts in the body of the message. I'm still impressed at some of the really simple bugs they exploited, like NUL characters in header fields. R's, John From nobody Thu Apr 23 00:38: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 EC1EB3A164A for ; Thu, 23 Apr 2020 00:38:23 -0700 (PDT) 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=sapienti-sat.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFWNA6fzG6k7 for ; Thu, 23 Apr 2020 00:38:22 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [88.198.49.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 1A5293A1648 for ; Thu, 23 Apr 2020 00:38:21 -0700 (PDT) Authentication-Results: batleth.sapienti-sat.org; arc=none; dkim=pass (2048-bit key; unprotected) header.d=sapienti-sat.org header.i=@sapienti-sat.org header.b=kGjTxwnz; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sapienti-sat.org; h=user-agent:message-id:references:in-reply-to:subject:subject :to:from:from:date:date:content-transfer-encoding:content-type :content-type:mime-version; s=dkim20170413; t=1587627499; bh=91Q JCjZfDPrxQbeLbLrXOc8VhwjNcpMz61PgqsqVxF4=; b=kGjTxwnzzekzwRVbk8q b046juDe9jVvZvmc9Jnp5PKa1iv2BaNTBG/JKcwsaoE89GTorJnZcx+EjAkcjrVw 5FYKLbvhpzvj51E8uEzUh3zWWwVAVf9NkQvmgZh/nWG06I/B8forXQAd/MjFyguQ ogWso0PFt+6GAnnKFJmBrDORIue3bDsFlHEBNy8w8UonqiCVVWwOwb3tD/e2sXO9 6Ei5p+S41JKH45zBBrQfJCXFmJLFpAkANuu2SfndtCpPAiBeHj27Gc+Ka+bifvMj aXbH9yJPEMZ1EzCWExoRU8rx/3Gkw7fBeU3KwWLKQol6P1YKKL8eJVHpFPZkRuqV qaw== X-Virus-Scanned: Debian amavisd-new at sapienti-sat.org Received: from www.sapienti-sat.org (localhost.localdomain [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with ESMTP id F015133E011B for ; Thu, 23 Apr 2020 09:38:18 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 23 Apr 2020 09:38:18 +0200 From: Juri Haberland To: dmarc@ietf.org In-Reply-To: <20200423002020.BAB07181BB09@ary.qy> References: <20200423002020.BAB07181BB09@ary.qy> Message-ID: <74a807f52a59fa87053fcc76aaa28a73@sapienti-sat.org> X-Sender: juri@sapienti-sat.org User-Agent: Roundcube Webmail/1.3.6 Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Apr 2020 07:38:24 -0000 On 2020-04-23 02:20, John Levine wrote: > In article <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> you > write: >> The paper asserts that AR is used as DMARC input.  I suspect that is >> rarely, if ever, true.  Yes? No? > > I'd say never. To do DMARC rejects you have to do all of the > validation in the SMTP daemon, which is before anything has a chance > to create an A-R header. Of course this is possible with the Milter protocol introduced by Sendmail and used also by Postfix. The mail traverses during the SMTP phase through different milters, e.g. a SPF milter, followed by a DKIM milter, and every milter injects an AR header with its results. The last milter is a DMARC milter that processes the AR headers and signals the SMTP daemon do either accept or reject the message. This is how OpenDKIM & OpenDMARC work together. Other projects do it all in one milter (rspamd?)... Juri From nobody Thu Apr 23 07:40: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 1B5E73A092F for ; Thu, 23 Apr 2020 07:40:32 -0700 (PDT) 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 wXTjFgfmIeyG for ; Thu, 23 Apr 2020 07:40:31 -0700 (PDT) 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 0F3463A0934 for ; Thu, 23 Apr 2020 07:40:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RK1EJPMIGW00452K@mauve.mrochek.com> for dmarc@ietf.org; Thu, 23 Apr 2020 07:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1587652527; bh=44AK+E4lMbuecGwcT7c7s9v7zj5H2bkGbxf3FA1P9pc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=pAOPRB18uMEyZAAtincot8Zim6luw1FRC6lcx0EzSP+me65qx7V/MxToFsSyEjw+F 3xni6bZelaQJp0Yu05KjyhYVs1K+KVt3HZQX7mZA0WMBNPhbSwF9mIpahxjRJUHUy8 P1Sw+i4w0zpjQFLMBB0m0Q+5gAcL2xxAdNkPg/1Y= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RK1DNIKXK0000059@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 23 Apr 2020 07:35:25 -0700 (PDT) From: ned+dmarc@mrochek.com Cc: dmarc@ietf.org Message-id: <01RK1EJO2TAW000059@mauve.mrochek.com> Date: Thu, 23 Apr 2020 07:34:06 -0700 (PDT) In-reply-to: "Your message dated Thu, 23 Apr 2020 09:38:18 +0200" <74a807f52a59fa87053fcc76aaa28a73@sapienti-sat.org> References: <20200423002020.BAB07181BB09@ary.qy> <74a807f52a59fa87053fcc76aaa28a73@sapienti-sat.org> To: Juri Haberland Archived-At: Subject: Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 23 Apr 2020 14:40:33 -0000 > On 2020-04-23 02:20, John Levine wrote: > > In article <51be5654-94c4-38c6-8f6b-dca403d6680a@dcrocker.net> you > > write: > >> The paper asserts that AR is used as DMARC input.  I suspect that is > >> rarely, if ever, true.  Yes? No? > > > > I'd say never. To do DMARC rejects you have to do all of the > > validation in the SMTP daemon, which is before anything has a chance > > to create an A-R header. > Of course this is possible with the Milter protocol introduced by > Sendmail and used also by Postfix. The mail traverses during the SMTP > phase through different milters, e.g. a SPF milter, followed by a DKIM > milter, and every milter injects an AR header with its results. The last > milter is a DMARC milter that processes the AR headers and signals the > SMTP daemon do either accept or reject the message. This is how OpenDKIM > & OpenDMARC work together. This is done all the time, and not just by Sendmail and Postfix. > Other projects do it all in one milter (rspamd?)... Yes, but when you do it all in one go it's more difficult to customize. Ned