Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

[Dave Crocker <[e-mail]>]

Terry,

On 4/1/2013 2:15 PM, Terry Zink wrote:
> I am proposing an extension to DMARC. Whereas today DMARC requires
> one of a DKIM pass or SPF pass, I propose we extend DMARC so that is
> has the*option*  to require both.

The draft working group charter that Murray just circulated would make
this effort out of scope, since it explicitly prohibits protocol 
enhancement.

Are you suggesting a change to the draft charter?

An alternative might be to find a way for this example scenario to
provide the basis for some discussion, in the draft BCP, about the
proper limits of DMARC.  It wouldn't solve your protocol problem, but it 
might provide good pedagogy.

Perhaps there are other alternatives?


> Let's assume that BigBank.com has been dutiful and has published a
> DMARC record. The problem occurs when Learning.edu gets compromised
> and starts sending out spam. If a user starts sending out spam
> [e-mail], we can detect this and shut it down. But what
> happens if they start sending out mail [e-mail]?

I tend to draw a distinction between protection against internal
problems, versus protection against external ones.  Internal means that
the misbehavior is caused by an activity within the administrative scope
of the entity needing protection.  External means that the problem
behavior comes from some other administrative scope.

The usual examples of the distinction are misbehaviors by a department,
within the company owning the domain name, versus misbehavior from a
classic spammer who is using the domain name without authorization. On
the average, the tendency has been to pursue standardization that
protect against external threats rather than internal ones. Internal
ones are thought to be best handled... internally.

> 1. example.com ----+
>                    |
> 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet
>                    |
> 3. Learning.edu ---+


The scenario you give might be considered as internal misbehavior, since 
there is a contractual relationship between Forefront and the sources of 
messages that you list.  That is, the essence of the challenge is for 
Forefront to have mechanisms that distinguish what mail is authorized 
from what source, and what mail isn't.  Per your example, it would 
require that it enforce its /own/ dmarc-ish policy to require that mail 
it is relaying for learning.edu be attributed to learning.edu, and so on.

If I understand your note correctly, the problem that you cite with this 
is that Forefront doesn't know all of the acceptable domains for a given 
customer.  Wouldn't it make more sense to fix this issue, rather than 
change the public standard and burden all recipients with the added 
complexity in software and operations?

Without have thought about it much, I suspect that one approach to 
fixing this is for Forefront to /privately/ assert the type of dmarc-ish 
enhancement that you propose.  That is, impose the requirement on its 
customers, thereby assuring that the mail it is relaying to the public 
Internet is 'safe', at least along this one line of concern.


d/
-- 
  Dave Crocker
  bbiw.net