Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 8 Apr 2019 18:55:31 -0400

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.   
The inferior email filters are not expected to implement this feature, 
because they are inferior products.   Therefore the new standard has no 
expected benefit, but we need to finish it anyway.
  
 Please explain.

---

From: Dotzero <[email-masked]>
Date: Mon, 8 Apr 2019 18:59:20 -0400

What part of that do you need an explanation for? It seems pretty clear to
me. If you disagree with the statement then you should explain the
rationale for your disagreement.

Michael Hammer

On Mon, Apr 8, 2019 at 6:55 PM Douglas E. Foster <
[email-masked]> wrote:

> I don't know how to express my shock at today's conversations.   One of
> the shocks comes from this:
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 8 Apr 2019 16:08:30 -0700

> 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.

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 08 Apr 2019 23:12:46 +0000

>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

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2019 19:49:30 -0400

>traffic, there is no difference.

I agree that the reports are useful, regardless of the policy.

I just wish we could figure out how to do this without reinventing the PSL.

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 8 Apr 2019 20:07:40 -0400

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)" <[email-masked]>
Sent: Monday, April 8, 2019 7:09 PM
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   
  On Mon, Apr 8, 2019 at 3:55 PM Douglas E. Foster 
<[email-masked]> wrote:
   I don't know how to express my shock at today's conversations.   One of 
the shocks comes from this:

  

   
  
 --Kurt

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 8 Apr 2019 20:27:06 -0400

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 
following.   
  	"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" <[email-masked]>
Sent: Monday, April 8, 2019 7:13 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] Rethinking DMARC for PSDs   

>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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 09 Apr 2019 00:37:51 +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" <[email-masked]> wrote:
>>> We have consensus that the better email filters do not need the
>DMARC
>>for

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Apr 2019 19:26:56 -0700

<chair hat on>

> difficulty of implementation.

If what you're looking to do is drum up interest for working on this and,
if there's critical mass to do the work, getting something published, I
suggest any of the following:

[email-masked] (message format discussions)
[email-masked] (SMTP discussions)
[email-masked] (ART area general discussions)
[email-masked] (once you have an actual proposal for work that needs a
home)

...possibly others, but those spring immediately to mind.  However, I
believe Scott is correct that this work is not currently within our
charter, and thus it's off-topic for this list.  I don't believe there's
any working group currently chartered to produce something like what's
being proposed here; EXTRA probably comes closest, and I think it's
off-topic there too.

Some years ago Dave Crocker and I assembled RFC 6647 about greylisting,
which was an applicability statement over email in general that talked
about how to implement greylisting.  You could follow that model if you
like, which merits standards track publication, though that means you'll
need to convince an AD to sponsor it or form a working group to develop it.

If my co-chair concurs, then it's appropriate that this conversation be
moved elsewhere.

-MSK

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 8 Apr 2019 22:46:25 -0400

+1 on moving the discussion elsewhere

Tim

On Mon, Apr 8, 2019 at 10:27 PM Murray S. Kucherawy <[email-masked]>
wrote:

> ....possibly others, but those spring immediately to mind.  However, I