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

worley@ariadne.com Thu, 16 April 2020 02:32 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: dmarc@ietfa.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 <dmarc@ietfa.amsl.com>; 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 <dmarc@ietfa.amsl.com>; 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 <dmarc@ietf.org>; 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 <toddmherr@gmail.com>
Cc: gen-art@ietf.org, last-call@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org
In-Reply-To: <CA+Wg=gt1SMO0n9pLOY_CKemEHimr+mnWCpNcoJWq+Da9Np7UuA@mail.gmail.com> (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: <https://mailarchive.ietf.org/arch/msg/dmarc/6UzaLkG2ZIzlXFpEvWIwvKPWB3M>
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:32:47 -0000

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.

Dale