Re: [dmarc-ietf] Rethinking DMARC for PSDs

Scott Kitterman <> Tue, 09 April 2019 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F356120162 for <>; Mon, 8 Apr 2019 17:37:56 -0700 (PDT)
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, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=GlYETMyE; dkim=pass (2048-bit key) header.b=Q5Hse2P4
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hK0oeESk0ahp for <>; Mon, 8 Apr 2019 17:37:54 -0700 (PDT)
Received: from ( [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1603B12014D for <>; Mon, 8 Apr 2019 17:37:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 27C9BF80920; Mon, 8 Apr 2019 20:37:53 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=GlYETMyEgn+mqXdrHhoEcrf3DPDTv8avRXeFRRzv7tbUbikZkyEt8mGQ 94AmC/k8bE+GEr5WKQJPbDiXNJXFCQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1554770272; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : from; bh=LPw/tv3BFolt3cd8ASY3NyW5zzJwVuIb6wpKnvmTiew=; b=Q5Hse2P4xgSvAN3eYIuY2h/UKhfG77H1v4I9HY+10BmIJ2046b7Pe5eM gXKS3gLLC1RYNNXvcXz4VS1HghIEHThOJVIOb+uwrgImUUjpfg5km8aEcr 8DktpVV206BAoz+h3Z7aHPXf/q/Nwc5VhZJwSajEKbslZhwSXgpsB8fOUk FgiCo0NNOe+O2sOHzCyRBgZ+8NrepnFl5jcL+TI+kVoq582qGyWS30Oi8u dRGYAlEBsQ9PLzIDuTlKvBbgOBfZoho/Lxo8TEMQJttfumBRuHZ/7epRg3 aK9cZPCsyWvbNmWCb267TsdH2N0Ab75bqZjjw4Q3tpqjEOhFvwrpOQ==
Received: from [] ( []) by (Postfix) with ESMTPSA id 99F36F807D4; Mon, 8 Apr 2019 20:37:52 -0400 (EDT)
Date: Tue, 09 Apr 2019 00:37:51 +0000
In-Reply-To: <>
References: <> <> <> <>
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] Rethinking DMARC for PSDs
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: Tue, 09 Apr 2019 00:37:56 -0000

No, I think you seriously misunderstand what the IETF does.  It doesn't do product specifications, it does interoperability specifications.

This is seriously off-topic for the DMARC working group list anyway.

Scott K
P.S. There are open source components to accomplish all the requirements you listed, some assembly required.  Discussion though should happen somewhere else.

On April 9, 2019 12:27:06 AM UTC, "Douglas E. Foster" <> wrote:
>Scott, you misunderstand what this type of standard would look like.  
>would defines Use Cases that the device should address, with some 
>acknowledgement to the tradeoffs between perceived risk and perceived 
>difficulty of implementation. 
>Implementation suggestions may be part of the use case.  It would be
>to implement SPF-like capability without using SPF data, but there are
>ways that SPF data could be utilized.   
>There are also fundamental security principles that everyone should be 
>	"Trusted communication (whitelist) should not occur until and unless
>identity of the correspondent is confirmed."
>	  	Escalation of privilege (in this context, bypassing integrity
>should be limited to the minimum necessary set of privileges to achieve
>business requirement. 
> Mr. O'Driscoll's comments seemed to make the same mistake.   The 
>configuration of email defenses will be different between a residential
>ISP, a large bank, and the US Army.   However, the principles and use
>will be similar because any threat actor could take aim at any target. 
>What differs is the perceived risk and the perceived complications from
>mitigating the risk, matched to each organizatoin's tolerance for risk.
> Nothing in this standard could be an absolute mandate, because only 
>government has the legal authority to say "This product cannot be sold
>purpose X because it does not have feature Y,"   It could say, "You
>implement this feature to claim compliance with RFC xxxx"   This type
>standard can and would pressure vendors to move in the right direction.
> It 
>would also help purchases know how to be more intelligent shoppers. 
> There is plenty of difficulty in reaching a consensus statement on 
>something like this, not least because each vendor wants to look 
>acceptable, no matter how inferior his current product may be.   Just 
>because a topic is difficult does not mean there is no reason to
>it.   Working Groups exist because these issues take time and effort to
>flesh out.   It is hard to argue that spam-getting-through is not an 
>important topic, but I suppose some people may try to do so.
> From: "Scott Kitterman" <>
>Sent: Monday, April 8, 2019 7:13 PM
>Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
>On April 8, 2019 11:08:30 PM UTC, "Kurt Andersen (b)"
>>On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster <
>>> wrote:
>>> I don't know how to express my shock at today's conversations. One
>>> the shocks comes from this:
>>> We have consensus that the better email filters do not need the
>>> PSDs standard, because they are already blocking non-existent
>>This neglects the benefit to the domain operators of receiving the
>>about abuse of their domain space. For the end recipient of the bogus
>>traffic, there is no difference.
>>> The inferior email filters are not expected to implement this
>>> because they are inferior products.
>>Somewhat tautological, but most likely true.
>>> Therefore the new standard has no expected benefit, but we need to
>>> it anyway.
>>Incorrect - see my first point.
>The entire thing is further premised on the false premise that because
>small mail operators find one filtering technique appropriate for their
>situation and scale, anyone that has a different design is inferior.
>Scott K
>dmarc mailing list