Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

"Murray S. Kucherawy" <> Sun, 22 November 2020 05:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACFAE3A10AA for <>; Sat, 21 Nov 2020 21:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h3nEp8zP42nX for <>; Sat, 21 Nov 2020 21:59:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A835D3A10A9 for <>; Sat, 21 Nov 2020 21:59:20 -0800 (PST)
Received: by with SMTP id r23so4612432uak.0 for <>; Sat, 21 Nov 2020 21:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C/APZWUr2y8trYeAByArDvlouGrJAP7/HMtE585x4QA=; b=DVRRfY9sQB2+ZWSCsB5pbSOHaUCSrHc0h5ANVz0SKjy1jrifUJ0V3Qi9RyyjA0PYed xEfPzW2knYCLQnoki2ZVIIKmmBk26n1whmBRwLPsK6Tt7BzGzB9cx16v+579VI/aH0SV tjE6n76pbBOqy+sk6ELfvXQYM4IgoDVC2m6F7mkaksqOOJMcHafKmxwKKAd9/cQNLddt bUIlfvWStegCxb9o2VcAg7aqJrb0b8rmWLFYRmQtnRBEzyrz4zlsmCcYxp7fTyoRDkr3 KebTOP6J/ONww664wvhcZV0P+/+4gzT6BBNWciX37I5KAb/vFi6cRQ77yTmmxrtMxgcp HRgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C/APZWUr2y8trYeAByArDvlouGrJAP7/HMtE585x4QA=; b=ozd0fBpVeQoasYAcb/R9pPU0G9YsCUCvMJ8KRo6HIr4wevCi5Tbdaf0sOgSDsMYFCV WaFoBDRsA5g4HHDFiOJ6OdF/FjZTSlkTtp7XHguKW84koOe41412laEX/5PsXopxaFx9 DbYAmQNH9xnwE7MZIgf5M3bFz0gLQdtdPpyO8idrtEvbTYVShtMYqobGboV7l3ReTsHA BvxLdVWqiM7ykNS2Io6Ka/hiQD0SmfFbMuq0k2yWye8fd7AouWlhbz5/8zmz4RdSxXG7 x0Wx0ZI5bZUAaR6Mu938RnH1j7G7h5FGw8R/y5KzBF/eKROXfvNXx1ou44RZq7CCLucQ 059A==
X-Gm-Message-State: AOAM5304leIgiMLFfJqBV9hsyVxfF+9H2vYPZ/KVueRIUUHEYbkpFH7q PyVHz/khCYy+dI+li+nHVPFL7f2ScaQ10S1F4acal+Nr
X-Google-Smtp-Source: ABdhPJy9BbPXYWlh2JyPMXfC+nTSscLJKfxuNL1WEJGmDFn2+qcS4oRUEExasGfPlAb4BIInb4qyNlPphEBq9GyooI4=
X-Received: by 2002:ab0:2e9:: with SMTP id 96mr4909829uah.87.1606024759415; Sat, 21 Nov 2020 21:59:19 -0800 (PST)
MIME-Version: 1.0
References: <> <20201120040420.B3F4727A02FB@ary.qy> <> <000001d6bf45$0f62cc30$2e286490$> <> <> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Sat, 21 Nov 2020 21:59:06 -0800
Message-ID: <>
To: Doug Foster <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000491af205b4abc772"
Archived-At: <>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Nov 2020 05:59:23 -0000

On Sat, Nov 21, 2020 at 5:32 PM Douglas E. Foster <fosterd=> wrote:

> On tree walk, I was working from John Levine's proposal, which assumes
> that a tree walk has to be distance limited for performance reasons.   He
> tentatively proposed four levels.   If you walk up the tree and find no
> DMARC entry, the walk stops with the conclusion that no policy has been
> issued.   This approach works if (and only if) the tree exists, so that the
> organization can place a policy at every fourth level.   The approach
> cannot work if the tree can be extended with non-existent domains.    It
> also conflicts with the PSD proposal which requires checking the top of the
> tree structure.

What does "extended with non-existent domains" mean in the context of a
tree walk?  You're going to have to give an example.

I had considered the top-down approach also, for the same reasons as you
> mentioned.   I assumed that it would be rejected because of the load placed
> on upper levels of the DNS hierarchy.

It strikes me that the infrastructure near the root of the tree is likely
very robust compared to that at many leaf nodes.

For the moment, it is a DMARC issue to me because DMARC has accepted the
> notion that unregistered domains are acceptable by default.   If that can
> be changed, I agree that there are other documents that need to be updated
> as well.

I think that assertion goes too far.  As I recall, DMARC doesn't claim that
unregistered domains are acceptable by default.  Rather, it cannot make an
assertion about a domain for which a policy cannot be found.  That's
certainly true of an unregistered domain.  DMARC follows DKIM and SPF in
this regard; they can only make assertions about a message when the parts
fall into place.  When they don't, none of those protocols can form a
conclusion.  That's different from deciding something is "acceptable".

In any case, it's unclear to me whether "bounce/discard anything from a
domain that appears not to exist" fits inside DMARC.  If you believe the
entire ecosystem should be doing this, not just DMARC-aware operators, then
I suggest these are the wrong documents in which to push for it.