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 <[email protected]>, XYZ Inc <[email protected]>
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
[email protected] | http://www.trustsphere.com/
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
