Re: [dmarc-ietf] PSD simplification

Scott Kitterman <> Sat, 15 December 2018 01:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58F07130EBA for <>; Fri, 14 Dec 2018 17:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=qY5lYeNt; dkim=pass (2048-bit key) header.b=ARqhrzdL
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PcysmNtfA3Ip for <>; Fri, 14 Dec 2018 17:23:41 -0800 (PST)
Received: from ( [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B77F12E036 for <>; Fri, 14 Dec 2018 17:23:41 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201812e; t=1544837019; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WW6HQUCW1PaCJYHL0l6A2fLkTIst1mx8eCd0adgHxUU=; b=qY5lYeNtwIyyB22jR7zzKsgPSziYropblQvC0qjTdneQYBYJ8YP+jT6x tCb5EQNr4zGHLWwyfgNtnPhi/A3VDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201812r; t=1544837019; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=WW6HQUCW1PaCJYHL0l6A2fLkTIst1mx8eCd0adgHxUU=; b=ARqhrzdLLh6g6EjfCOMAoyUvRw6CVgkAmyWf7hrgK3wd4+j1r2kHfwaC 45aEc6hi2rfKRY4Vzfx3ZkSEo5OUFccC9qLdkBqjvhuBKlzXJfOAgMdJI7 ozXmSkr1v8I5DQrFA+YyPWMA5scnyaLS2P6AUjtS1yY4N52shzlENsZQtV igJitf5Zm20+sfBgDNkn2a8/8JSBbraQC1ErtBxnX4OsrDnTCot1QyyJDF HbX858d4jLvAjBpJ0VNBTIZTqgDI4XpJ45r5d2zd4hH1mgwghWOxkeGp6P vAUjxZOiOp8B1KvhbLqnlrY4nV8Gd95GgP1OqEbDzqDl9r5N40FraA==
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 531992D409A1; Fri, 14 Dec 2018 19:23:39 -0600 (CST)
Date: Sat, 15 Dec 2018 01:23:32 +0000
In-Reply-To: <>
References: <> <> <> <2046741.GJeexbxHFF@kitterma-e6430> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Scott Kitterman <>
Message-ID: <>
Archived-At: <>
Subject: Re: [dmarc-ietf] PSD simplification
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Dec 2018 01:23:44 -0000

On December 14, 2018 4:34:35 AM UTC, Dave Crocker <> wrote:
>On 12/13/2018 4:25 PM, Scott Kitterman wrote:
>> It suffers from what is, in my opinion, a fatal flaw: it relies
>entirely on
>> assertions that any PSO can publish with no external review.  Without
>> kind of third-party check on this, I don't believe there's any
>> mitigation at all.
>I think that assessment is misses an essential point.
>Let me back up and say that my suggested alternative is intended to
>the basic concern you are raising seriously.  (I'm not stating a 
>personal opinion about the seriousness of this as a threat vector, but 
>merely looking for a simpler way to satisfy the concern.)
>The alternative requires that the registry's dmarc record be
>by a record that points to the terms and conditions the registry 
>publishes to indicate why their record is acceptable.  (Your draft's 
>specification of those conditions looked to me like a reasonable 
>starting point; there should be a separate wg discussion for the
>details and wording; I don't have a personal opinion about those
>As for the benefits I see in the alternative I've proposed, I'll class 
>them as simplification and robustness.
>First, a new, query-able registry is expensive to run; and difficult to
>ensure quality control for, over the long run.
>Second, the vetting method your draft proposes for the registry relies 
>on a technical expert to make what is frankly a legal assessment of the
>terms and conditions that the registry publishes.  And that assessment 
>is made only one time, when the registry entry is first created.  The 
>registry might change its T&C text and we'd be unaware of it.
>So while you are technically correct that the alternative means that
>registry gets to /publish/ with no external review, it is not true that
>their dmarc record will automatically be used without review.
>In fact what I'm proposing will make widespread and ongoing review 
>likely, IMO, probably in the spirit of ongoing reputation assessment 
>that the email industry already does, although for dmarc default record
>rather than spam.

I see your point.  In addition to complexity, tohe issue that there is no mechanism for removing bad actors from the registry does present a problem.

Let me think it over and see if I can come up with text that both addresses your concerns and also provides guidance that I'd be comfortable with in lieu of the registry.

Scott K