Re: [dmarc-ietf] Rethinking DMARC for PSDs

"Douglas E. Foster" <> Tue, 09 April 2019 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54BCD1200C7 for <>; Mon, 8 Apr 2019 17:27:17 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RCs3OqstEr9p for <>; Mon, 8 Apr 2019 17:27:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D2071200B2 for <>; Mon, 8 Apr 2019 17:27:15 -0700 (PDT)
X-ASG-Debug-ID: 1554769633-0990573e6360850001-K2EkT1
Received: from ( []) by with ESMTP id NHNXGqYbPz42CBDn (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 20:27:14 -0400 (EDT)
X-ASG-Whitelist: Client
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1025; h= content-type:mime-version:message-id:reply-to:date:subject:to:from; bh=9L1ekYxDnMx8JLRPafoLwe3xaINn88f4RzoI58666Qk=; b=LAqcto5YhnjWKCNd6xipWdOl20NkrvESi3coyJ8fm75iF1cPeumEi4S4q1WRT3eaE W4riMxn6k3YYTbRinxOpFfBZTG0+w+YEWIUYCGPuECYRBEp90TGY9Pgds4M2Rt2AH tlWTwYPSX7OT7NaKMfm26wpCHtDg3k/Zb0hpO9UTs=
Received: by via HTTP; Mon, 8 Apr 2019 20:27:06 -0400
From: "Douglas E. Foster" <>
To: <>, "Scott Kitterman" <>
Date: Mon, 8 Apr 2019 20:27:06 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=497f17404f554734b20b27435daf6fa2
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <>
X-Exim-Id: 3e3a5997f71544f1a29fca8845fcbf60
X-Barracuda-Start-Time: 1554769634
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Scan-Msg-Size: 9214
X-Barracuda-BRTS-Status: 1
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:27:17 -0000

Scott, you misunderstand what this type of standard would look like.   It 
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 hard 
to implement SPF-like capability without using SPF data, but there are many 
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 the 
identity of the correspondent is confirmed."
	  	Escalation of privilege (in this context, bypassing integrity tests) 
should be limited to the minimum necessary set of privileges to achieve the 
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 cases 
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 for 
purpose X because it does not have feature Y,"   It could say, "You must 
implement this feature to claim compliance with RFC xxxx"   This type of 
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 discuss 
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 DMARC
>> 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 two 
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