[dmarc-discuss] multiple from
sklist at kitterman.com
Tue Jul 16 21:33:21 PDT 2013
On Wednesday, July 17, 2013 11:31:18 AM Roland Turner wrote:
> 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?
It sounds reasonable to me. There is even the concept of a precedence
hierarchy already established in the pct value where the policy that's one
less strict is used for some fraction of the mail, so "pick the strictest" can
be defined based on a hierarchy that's already in the spec.
More information about the dmarc-discuss