Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd

Alessandro Vesely <> Sun, 14 July 2019 10:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8ED1D1200F4 for <>; Sun, 14 Jul 2019 03:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uA0lPpGMKvAU for <>; Sun, 14 Jul 2019 03:19:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30FA81200E5 for <>; Sun, 14 Jul 2019 03:19:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1563099593; bh=ffJWAe78xm7Dw+7WkJ6fUPH/LB2J7B6jH9N3Wjjekq0=; l=2383; h=To:References:From:Date:In-Reply-To; b=DKpj3c7a7KR7yWJzAvdWYQJx/UtugbIFrDLyeJdpGs1jJSMuuxB/xY/+B09WJmfHH AEkm5T5Kso/KfMAUNC9zmfKwHt3PbnCtCx1IJjBZQG0fhrGtYLiOSGq9qb9gOFY0jI zd+ddQI7oedlJaE4rcRCVHzqqEpotryaZfKKRegS7LaM+Ny89/0w2IMzUxzJ3
Authentication-Results:; auth=pass (details omitted)
Received: from [] ([]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1.2, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by with ESMTPSA id 00000000005DC050.000000005D2B01C8.000046E9; Sun, 14 Jul 2019 12:19:52 +0200
References: <> <1851683.DtEN5jD5Wj@l5580> <> <1834844.gVztEOuzS9@l5580>
From: Alessandro Vesely <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Sun, 14 Jul 2019 12:19:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <1834844.gVztEOuzS9@l5580>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd
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: Sun, 14 Jul 2019 10:19:57 -0000

On Sat 13/Jul/2019 21:06:00 +0200 Scott Kitterman wrote:
> On Saturday, July 13, 2019 1:22:15 PM EDT Alessandro Vesely wrote:
>> On Fri 12/Jul/2019 19:30:35 +0200 Scott Kitterman wrote:
>>> On Thursday, July 11, 2019 6:07:50 AM EDT Alessandro Vesely wrote:
>>>> Appendix B.1 lacks a criterion to establish enlisting.  Couldn't we
>>>> require an explicit statement about seizing DMARC reports in, say, the
>>>> delegation report?  Alternatively, that policy can be stated in a
>>>> well-known place under the delegation services URL, so that
>>>> registrants know what they do.
>>> It's in the appendix because we don't have a clear path forward.  This is
>>> part of the experiment.  We need to be careful though since different
>>> PSDs operate under different authorities and controls, so there is a
>>> point beyond which it's not the IETF that decides.
>> I hypothesized that all what is needed to gran enlistment to a
>> PSO is that its policy to seize DMARC at PSD level be published, 
>> so that registrant can learn about is before registering.  Is
>> that correct?  I mean does a public statement suffice?>>
> In my view the challenge around which PSDs receivers should check for a PSD 
> DMARC record needs to be external to the PSD (i.e. not a self-assertion).

Agreed.  However, even if it were written in the delegation record at
IANA, it would still have to have been initiated by the PSO.  So the
requirement is a sort of validated/ agreed upon self-assertion.

> Some options are presented in Appendix A.  If, as a result of the experiment, 
> it's concluded that self-assertion is acceptable, then all that's needed is to 
> publish the record.  I don't think we need a second place to look up to tell 
> receivers to do the record lookup.

>From an implementer's POV, having a short list to complement the PSL,
to be updated not very often, sounds convenient.  For the algorithm, a
few extra string comparisons are still quicker than one more DNS lookup.

In addition, the organization who publishes that list qualifies as an
authority for monitoring those self-assertions.  It can tell when a
PSO first published its policy, and hence which registrants could have
operated their 2nd or 3rd level domain without being aware of that.
If it's important to preserve mail site operators' rights, that is.