Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Scott Kitterman <[e-mail]>]

On July 17, 2019 5:54:41 AM UTC, Seth Blank <[e-mail]> wrote:
>On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <[e-mail]>
>wrote:
>
>> Yes, the point of 'np' is to allow for a stricter sub-domain policy,
>but
>> that's to support early deployment of strict PSD level policies
>without
>> breaking org domains that are still deploying/have not deployed
>DMARC.
>>
>
>I absolutely agree with this.
>
>
>> Case:
>>
>> PSO mandates all orgs deploy DMARC, but that's not done yet.  PSO
>wants to
>> deploy PSD DMARC for reject at the PSD level and for non-existent
>domains,
>> but
>> leave non-DMARC deployed existing domains at none.  PSO publishes
>these
>> policieis for the PSD:
>>
>> p=reject, sp=none, np=reject
>>
>
>Ah, I see what you're saying here. I honestly couldn't understand why
>you
>were talking about sp=none at all within a PSD context. I thought the
>solution to this scenario was to do as the PSO p=none; np=reject. I
>actually like p=reject; sp=none; better here, because that lets the PSD
>lock itself down as a sending domain. But to me, this also makes it
>clear
>that np= should use the p= not the sp= as its default.

See if you still feel that way after considering backward compatibility ...

>That said, I feel less strongly about this now, and can see merit in
>inheritance from either side (or from a hard default of none, for that
>matter, although I'd strongly argue against that personally...).
>
>
>> Having 'np' fall back to 'p' doesn't actually solve the problem you
>claim
>> to
>> be solving since it only affects non-implementers.
>>
>
>This I don't understand. The results you outlined are exactly what I
>think
>should happen.

I think we agree on the goal, the difference is only about implementation details and impact on non-particpants in the experiment.
>
>> I believe that's the exact requested case and the changeset I've
>provided
>> supports that without creating a situation where every implementer of
>the
>> experiment suddenly starts processing existing DMARC records
>differently
>> (which
>> I think would be very bad).
>>
>
>I don't think I properly understand what you're saying. Can you clarify
>this point?

Keep in mind that senders do send from what we call non-existent domains for reasons that seem good and sufficient to them.  Let's take that as a fact, whether it makes sense to us or not.

Sender (who knows nothing of our experiment) has published a DMARC record that includes:

p=reject, sp=none

When a DMARC compliant receiver receives mail from a subdomain of that organization domain, the policy to apply is none.

If our experiment has 'np' fall back to 'sp', then the non-particpant gets the same result.  An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'sp' (none - 'np' fallback) for a non-existing sub-domain.

If our experiment has 'np' fall back to 'p', then the non-particpant gets a different result.  An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'p' (reject - 'p' fallback) for a non-existing sub-domain.

Keep in mind, this isn't just about receiver processing.  The policy applied is also in the aggregate reports.

I think changing existing defined behavior for non-participants in an experiment is not appropriate.  It's even more unacceptable in a case like this where we absolutely don't need it to achieve the desired behavior within the experiment.

Scott K