Re: [dmarc-ietf] PSD simplification

Dave Crocker <> Fri, 14 December 2018 04:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 545CA1277D2 for <>; Thu, 13 Dec 2018 20:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nJ0Imh7XJEra for <>; Thu, 13 Dec 2018 20:34:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B7B212008A for <>; Thu, 13 Dec 2018 20:34:39 -0800 (PST)
Received: by with SMTP id u16so4224090otk.8 for <>; Thu, 13 Dec 2018 20:34:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VyMctYHje2Kf4w7F49XynLXFBdx4Vs/RBylA5jxYbuQ=; b=IIFhOg+X4pSi/D9wercKiG0TxlQjmCDtd9gxi30Hoo3UE9GQoUb6i2XApT9K8BPDB4 yYnjGl78msg+D0VuOOwoZbciTrnJWA/l7TYICY+2pPj2xFhDwVzT7gwE7xyudh1u3vo/ bvaIgu9yXdyTSsDFG+g0hw4wPFohnQAb8e3aRvbrxWCqZPGy3MakqK1yjXyDhEf7Nv8U lWqXb5rDyBYBIxcyWbOHAkLyAgp7rzEOJ3TU3F1V7NRVRO5IGdDhUXOrr4m9gx5zcGpX JKAuHRdy6Ylfv03qQ16OZynjASPbo92jvjfGgODRLjaqu63EDtaXkPvXpt1p3AgYP2n/ aezQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VyMctYHje2Kf4w7F49XynLXFBdx4Vs/RBylA5jxYbuQ=; b=NiAtVE8vOB6RBzeQFDmuL0zMxN3d0yicfNQ6VND0F/0JD1oHqtpR4Ttw127i26UFSB oCjqohhVe7NOYObjwxwF+YgtLdMRYmKnm1IIYwL/i6bM3Q4lWf31fDygNa1ZGnE6GY3H rrCv1Ytjm9qws9XSqgsPRtU2y4/6W8wQNdVW17OWe8vI8+WR+Cc7MUb6NaWnY+w7VrDJ t8DftQsNO4L7rbMajiSXV+sZsZWAvgA4q2OnVDkIfmr7Rd6ocJQ/LO7VuxGDQGYMt27w W20j0DFd7kWrY/xITOPF5/h/kh5rWSKZZ17pZEFlsN1emVhULOmNuAAOWwUvO5lB2n0+ aWyQ==
X-Gm-Message-State: AA+aEWYmnADZ2t2ftCNqd9QTfn7ZLankjvPMyTARKdcPXStplaDSKoFy ZYq//zvpXsZb4M7IK/9ABX3d3uCsmUE=
X-Google-Smtp-Source: AFSGD/UFt+f/1yzNi6FJWp8QtsbzNt5VrRE1JDodi6+ax+x6qw8NEaqGm9GyBf3Qcsl9AmTmWx2Bcg==
X-Received: by 2002:a9d:172e:: with SMTP id i46mr1031061ota.322.1544762077947; Thu, 13 Dec 2018 20:34:37 -0800 (PST)
Received: from ?IPv6:2600:1700:a3a0:870:d167:e3f8:4e3c:c340? ([2600:1700:a3a0:870:d167:e3f8:4e3c:c340]) by with ESMTPSA id m2sm2152976otp.34.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 13 Dec 2018 20:34:37 -0800 (PST)
To: Scott Kitterman <>,
References: <> <> <> <2046741.GJeexbxHFF@kitterma-e6430>
From: Dave Crocker <>
Message-ID: <>
Date: Thu, 13 Dec 2018 20:34:35 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <2046741.GJeexbxHFF@kitterma-e6430>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Fri, 14 Dec 2018 04:34:41 -0000

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 some
> kind of third-party check on this, I don't believe there's any privacy
> 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 take 
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 accompanied 
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 precise 
details and wording; I don't have a personal opinion about those words.)

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 the 
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.


Dave Crocker
Brandenburg InternetWorking