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

Dotzero <> Fri, 12 July 2019 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCA931200D7 for <>; Fri, 12 Jul 2019 12:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U7vVkiQKYx9u for <>; Fri, 12 Jul 2019 12:34:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 333F71207D2 for <>; Fri, 12 Jul 2019 12:34:00 -0700 (PDT)
Received: by with SMTP id a15so9874911wmj.5 for <>; Fri, 12 Jul 2019 12:34:00 -0700 (PDT)
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=+XloU0weJ83y651vQY2ewFoWIbMepy7ahB+JYJjSKMo=; b=qP1yz6sA3+mqolJcDYrKYdgsK7KRXY0pLYRbPbO1nHPtspXjB/mJaK9KQJAwlMu5Pq bcjT4cxKtluMA2QoPENxwXihQwVez3xlI573Xnl9UALez/UjFAFmxILvK2Vbvyr06Utz RwgsOKdmDWGgC9Gi/OvC+cyQLfAeLjofZE3X4oGi4oEzKZLeVWafK62sFtEA2SJT6tP6 1LomP63GpUgQgSgJG299WuFz6NPMODBm0HAc4+3CeyNyZPhfiko6vkA8i7X07njfDQTL E7ULXva+xJJiZsE2Y3MeA/LOi80U6j7I/jSFiuY4aIEA/WIXn/AQg1u9a8I4tnTou3V6 9XwA==
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=+XloU0weJ83y651vQY2ewFoWIbMepy7ahB+JYJjSKMo=; b=EEYIlymw5f20K28CnDc8MG3HHY17VSzk5gV57ldmFJpzazIDc7XV66uOpRefYDPYYq ockZhkau9qF+LaJSd1rK+oH3PpHyUSzCtlDGcfJnH9V7N178h1EQT4Ipokruq0aCaMvv uZasvY9U5Y0fFuU2mmGi66pOUcsi6479zDM8pCtIerNJVrHF0DtU4pO8wpA9If6vJF7V pHVSd1uzkBh3nHDzzPFZRfq4aFqrFWfYq1Zv24H0VcgWOIbQR2d8hoD2PvpOmrhuKq5m oCz5giK/jJymxjLmwa6nBZK2bOS+hnC/1MoYzUBOtVwYAIcDoNyhitUrKaJCcunHZIMd G6Vw==
X-Gm-Message-State: APjAAAU4xuhx2QgDTp6zy8C9dRMUTIpzLRUK52zkGWR/l20x3r+svlqZ kaR3vGvhNl9BVpW8oSmCKDdootTBd3n8HFeIJB0=
X-Google-Smtp-Source: APXvYqwdK9eCNL3kUrWl6uTp3wpvZE27d6A0a/a3lThDt5aMuhMkHGPCdg80XkLa1YCB1E6LlvxGkM2bgmVKfkq1l40=
X-Received: by 2002:a1c:35c2:: with SMTP id c185mr10793137wma.58.1562960038605; Fri, 12 Jul 2019 12:33:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <1893230.9INSBCnb99@l5580> <> <>
In-Reply-To: <>
From: Dotzero <>
Date: Fri, 12 Jul 2019 15:33:46 -0400
Message-ID: <>
To: Seth Blank <>
Cc: "Kurt Andersen (b)" <>, "" <>, Scott Kitterman <>
Content-Type: multipart/alternative; boundary="000000000000e63a21058d80fd88"
Archived-At: <>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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: Fri, 12 Jul 2019 19:34:03 -0000

On Fri, Jul 12, 2019 at 2:16 PM Seth Blank <>; wrote:

> On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) <>;
> wrote:
>> I am much more concerned with adding another tag that can only be used in
>> a PSD-DMARC record. I would be much more open to make a "normative" change
>> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC
>> record, than to make this a special case for PSD-DMARC records.
> I am also concerned with adding any new policy-related tags, due to the
> confusion they create that limits adoption. However, a very clear case for
> an NXDOMAIN policy has been made by UK NCSC for, and both .gov
> and .mil have stated they also want this behavior. Others have shared
> similar opinions privately.
> Since PSD is an experiment, I think this is a fine place to test an np=
> tag. If it gets usage, then we have a clear argument for it being a normal
> tag for DMARCbis. If not, then it can be jettisoned altogether.
> Adding this tag for PSD will simply need explanatory text in the
> Experimental Considerations outlining this..
> Seth

I agree with the concern expressed and the approach outline. I do have a
concern as to the number of validators which will consider implementing
this. Will it be added to OpenDMARC?

Michael Hammer