Re: [dmarc-ietf] Rethinking DMARC for PSDs

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5619D1200E5 for <>; Mon, 8 Apr 2019 17:07:51 -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 owGtCRz-gwFd for <>; Mon, 8 Apr 2019 17:07:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DAE31200C7 for <>; Mon, 8 Apr 2019 17:07:49 -0700 (PDT)
X-ASG-Debug-ID: 1554768467-0990573e63604e0001-K2EkT1
Received: from ( []) by with ESMTP id mWr0sjv7TL29mlgZ (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 08 Apr 2019 20:07:47 -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=qf5A5CD7jed6QvDg+WZNZUgDmT99tyhsfooo7K6Mc9Y=; b=N3WbM2sdsJgCIIQv1nL895CLvUBcQ2MSxFQCGsjxxv0B2W0pOLfAhXUn+ujS0KAff I5JSpyoQ+FnMzLJVrzvhtPoowFqcCYzhvRA1+UKwcxu6y+C2wSZvOqbxVxUQsDtbB MfAEz6R0GXmSpvgW9uRgV2uPPgfmVXs32IZ/n+hjo=
Received: by via HTTP; Mon, 8 Apr 2019 20:07:40 -0400
From: "Douglas E. Foster" <>
To: "Kurt Andersen (b)" <>
CC: "" <>
Date: Mon, 8 Apr 2019 20:07:40 -0400
X-ASG-Orig-Subj: Re: [dmarc-ietf] Rethinking DMARC for PSDs
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=8255ebf684b3417ba5e0b73a203d946e
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
X-Exim-Id: 2d4a44dd9a8c43f6871027bf82c27b57
X-Barracuda-Start-Time: 1554768467
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Virus-Scanned: by bsmtpd at
X-Barracuda-Scan-Msg-Size: 6846
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:08:55 -0000

Let's pursue the use cases for this information.   Existing DMARC feedback 
has three uses, after interpretation:
  	Compromised accounts:   "Account <username> appears to be comprised and 
sending spam.   Please shut it down." 	Configuration errors: "We may have 
blocked legitimate mail, indicating that your SPF policy is incorrect or a 
sending entity is not applying DKIM signatures properly" 	Criminal 
activity: "Server <ipaddress> is trying to send email using your identity, 
but failed to trick us." 
 For non-existent domains, the first two use cases are not applicable.   
The last use case is an opportunity for law enforcement, so it may be 
particularly interesting to government PSDs.   Keep in mind, however, that 
for ordinary folks like me, an unsuccessful attempt at electronic crime is 
not interesting to law enforcement, and will not trigger a response because 
there are always bigger problems to chase.
 On the technical side, the feedback to PSOs will only occur f the new 
feature (DMARC for PSDs) is given higher precedence than previous defenses 
(such as blocking non-existent domains or blacklisting bad IP addresses.)   
 So precedence rules need to make it into the specification.

 From: "Kurt Andersen (b)" <>
Sent: Monday, April 8, 2019 7:09 PM
Cc: "" <>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
  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 of 
the shocks comes from this:
 We have consensus that the better email filters do not need the DMARC for 
PSDs standard, because they are already blocking non-existent domains.   
 This neglects the benefit to the domain operators of receiving the reports 
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 feature, 
because they are inferior products.   
 Somewhat tautological, but most likely true.
  Therefore the new standard has no expected benefit, but we need to finish 
it anyway.
 Incorrect - see my first point.