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)" <kb...@drkurt.com>
Sent: Monday, April 8, 2019 7:09 PM
To: fost...@bayviewphysicians.com
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
  On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster 
<fost...@bayviewphysicians.com> 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.
  
 --Kurt
   


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to