Re: [dmarc-ietf] Genart last call review of draft-ietf-dmarc-psd-08

Scott Kitterman <scott@kitterman.com> Thu, 16 April 2020 02:45 UTC

Return-Path: <scott@kitterman.com>
X-Original-To: dmarc@ietfa.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 <scott@kitterman.com>
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: <https://mailarchive.ietf.org/arch/msg/dmarc/B4ALGXGFaAT1CRV9nqgo4AJ00QE>
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\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=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 <toddmherr@gmail.com> 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 <http://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".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
> > <http://publicsuffix.org/ <http://publicsuffix.org/>>. 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