[dmarc-discuss] multiple from

Roland Turner roland.turner at trustsphere.com
Tue Jul 16 20:31:18 PDT 2013


On 07/16/2013 09:31 PM, Tim Draegen wrote:

> FWIW, allowing multiple "policy keys" adds quite a bit of complexity. 
> Which one takes precedent? Does allowing multiple keys allow a domain 
> to send on behalf of another even though the other domain publishes an 
> explicit reject policy? Big can of worms for no benefit. HTH, =- Tim

Apologies if I've missed this already being done to death, but this 
actually seems like a pretty simple question to resolve, and does 
provide a standards process benefit if not a realistic operational 
security one.

DMARC policies have the useful characteristic that a total ordering 
exists for them (reject always outranks quarantine and none, quarantine 
always outranks none). It is therefore always possible to determine 
which one to apply in situations more than one is potentially 
applicable. For Mail Receivers discovering multiple Author Domains, the 
process becomes to "evaluate DMARC against all identifiers" 
(draft-kucherawy-dmarc-base-01 10.1 already says this) and then to apply 
the strongest resulting policy. So:

    From: PayPal <x at paypal.com>, XYZ Inc <noreply at phisher.example>


requires two independent DMARC evaluations:

  * phisher.example, which will presumably pass and yield p=none
  * paypal.com, which will presumably fail and yield p=reject


The strongest resulting policy is reject, which is therefore the policy 
to apply. This also yields semantics that are a sensible generalisation 
of the existing approach:

  * A Sender wishing to assert a particular Domain Owner's domain in the
    From: header must have that DO's consent and the relevant technical
    measures in place.
  * A Sender wishing to assert multiple Domain Owners' domains in the
    From: header must have _*each*_ DO's consent and the relevant
    technical measures in place.

Stated this way, the "big can of worms" reduces to a question of whether 
the Sender must have the consent of any one of the asserted domains' DOs 
or that of all of them, and the answer becomes obvious: all of them. In 
terms of the spec, it means replacing the third last sentence of 10.1 
with something like:

    If they are not, the Mail Receiver can either:

      * (if there are no identifiers) ignore the message entirely with
        respect to DMARC processing, or
      * (if there are multiple identifiers) evaluate DMARC against all
        identifiers and apply the strongest resulting policy.


A reasonable person might argue that any Mail Receiver who actually 
cares about this will simply reject such abominations out of hand, and 
this would be a perfectly reasonable thing to do, however making this 
change to the spec achieves two things:

  * it ties up this loose end for people who are not willing to be quite
    so peremptory with incoming email, and,
  * perhaps more importantly, it resolves one of the likely causes of
    ...standards process indigestion.


Have I missed something?

- Roland

-- 
   Roland Turner | Director, Labs
   TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
   Mobile: +65 96700022 | Skype: roland.turner
   roland.turner at trustsphere.com | http://www.trustsphere.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.dmarc.org/pipermail/dmarc-discuss/attachments/20130717/a336827e/attachment.htm>


More information about the dmarc-discuss mailing list