Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

Hector Santos <> Thu, 06 February 2020 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 045ED12008B for <>; Thu, 6 Feb 2020 10:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=XoTiTuYj; dkim=pass (1024-bit key) header.b=uGGreSr8
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGXJ09KeOccY for <>; Thu, 6 Feb 2020 10:03:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55CC1120077 for <>; Thu, 6 Feb 2020 10:03:32 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2729; t=1581012211;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=7cNvw6Td9pTuF45cUPbb1lKubrA=; b=XoTiTuYjwMXOiDVO3CNtQ1iV7kLDZ9xPrupQP3N3O2zfk8/A3sWm+YlZpSLAf+ NPCbPR6Wjq+bM47j9ry50ZqOuM+CBLaAx3zRVZHhAth9ua0w0wcldm9XB1AobMnL HI8TBwIbeuTob2LLCTqXhLZt5hHXvRYgXaQIEa1OHOGyI=
Received: by (Wildcat! SMTP Router v8.0.454.9) for; Thu, 06 Feb 2020 13:03:30 -0500
Authentication-Results:; dkim=pass header.s=tms1; dmarc=pass policy=reject (atps signer);
Received: from ([]) by (Wildcat! SMTP v8.0.454.9) with ESMTP id 329576691.1402.3780; Thu, 06 Feb 2020 13:03:30 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2729; t=1580964712; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tlkd3TN Cwq8nHIj1XOJ5JJccf7UtWpsNpFl0GkKntC4=; b=uGGreSr8Ab93tP0H38bN0AH rLTerj5yUsZ8NylBQAdUGqtgl8OxEqi2WoHgDU2JfX3FNRTwfongw/ah5TmLUrcK AxrR+AA6DLOg0+5d6178059z4EOUIGrt3yWBitEG0koj5tFt3L82WB+AUdW8xP+H 02HOiXc6TVqKvh38RYIg=
Received: by (Wildcat! SMTP Router v8.0.454.9) for; Wed, 05 Feb 2020 23:51:52 -0500
Received: from [] ([]) by (Wildcat! SMTP v8.0.454.9) with ESMTP id 130352703.4.944; Wed, 05 Feb 2020 23:51:51 -0500
Message-ID: <>
Date: Wed, 05 Feb 2020 23:55:29 -0500
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Comment on 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: Thu, 06 Feb 2020 18:03:35 -0000

 From a software engineering standpoint, we have an "Lookup" black box 
mechanism.  It should be left open-ended so the DMARC-bis can move it. 
  The default mechanism is the existing DMARC one. Consider PSD a 
Lookup extension to DMARCbis.    DMARCbis can describe "Lookup 
Extensions." Remember, we still TPA design issues and we have an 
extended lookup ATPS deployed.  Until we get a valid TPA method more 
systems accept, we will never be done with DKIM Policy modeling.

Can we please move on to completing DMARC as a standard?

On 2/3/2020 10:08 PM, Murray S. Kucherawy wrote:
> On Mon, Feb 3, 2020 at 4:24 PM Craig Schwartz <
> <>> wrote:
>     Hi Murray,
>     <<<The chairs will not accept hearsay replies or opinions, or
>     expressions of needing this work but not knowing how to engage;
>     you either give your feedback on the list or privately to the
>     chairs or Area Directors, or you are along for whatever ride
>     results.  Please indicate, as soon as possible, where your support
>     lies given the above.>>>
>     In my capacity as managing director of fTLD Registry Services
>     (fTLD), registry operator of the .BANK and .INSURANCE TLDs, I
>     believe PSD would provide invaluable threat intelligence to domain
>     registrants and to TLD administrators like ourselves for
>     NXDOMAINs. PSD has tremendous value to specialized TLDs including,
>     but not limited to, .BRANDS, community-based domains,
>     high-security domains, governments, etc. and as such I believe PSD
>     should proceed. I’ve previously posted to this list expressing
>     this view and while fTLD cannot participate in experimentation due
>     to a prohibition by ICANN, we remain committed to supporting and
>     seeing this work continue.
> Craig,
> Thanks for this, and for one other person that sent to the chairs
> privately (it was a list non-member caught in moderation, nothing secret).
> To be clear, however: I think the working group mailing list archive
> has enough of a record that participants think the experiment will be
> useful or even critical to the evolution of DMARC, though people are
> of course welcome to affirm that support for the record.  The question
> being put, however, goes to the form of the experiment and the current
> form of DMARC as a protocol with respect to determining Organizational
> Domains, and whether there are indeed risks to the deployed
> infrastructure that the experiment could become permanent.  That's the
> meaty stuff that would really help to move this along.
> -MSK
> _______________________________________________
> dmarc mailing list