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

Scott Kitterman <sklist@kitterman.com> Thu, 18 July 2019 02:34 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9534312062A for <dmarc@ietfa.amsl.com>; Wed, 17 Jul 2019 19:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=5SgwYxR2; dkim=pass (2048-bit key) header.d=kitterman.com header.b=CeX1MTmW
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86BcnRmWDajE for <dmarc@ietfa.amsl.com>; Wed, 17 Jul 2019 19:34:48 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [64.20.48.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24D912060B for <dmarc@ietf.org>; Wed, 17 Jul 2019 19:34:47 -0700 (PDT)
Received: from interserver.kitterman.com (interserver.kitterman.com [IPv6:2604:a00:6:1039:225:90ff:feaa:b169]) by interserver.kitterman.com (Postfix) with ESMTPS id EBDC3F805D5 for <dmarc@ietf.org>; Wed, 17 Jul 2019 22:34:46 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903e; t=1563417286; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=m15bpI1qoRUuT9SD8XsL9O1lTFUw3hevyNC6ih/94OM=; b=5SgwYxR2t9WPCtlU/CjHH2W5athbKGEUlITjTId6atPrf/JSo0+n292x 9kVA/O6rK2WzP84RxJkNX0+kazp8Dg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201903r; t=1563417286; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=m15bpI1qoRUuT9SD8XsL9O1lTFUw3hevyNC6ih/94OM=; b=CeX1MTmWKK4RjEejrkwI8ybam7EftGPPGF+gAUN19R/XvLlL8u+FLfiC F2ViX48j8JAkc9m+te6NvB8b7WrzUTgqWBMO7RLckoPstw8BlGoOIaEhnM dPXivPgnfhaPO9mc3aqZ2fnNy5VqdNOEC2oZiX72HqYLdaA+Mwuhypbpat 9/7pYqtFqGJiYS+sfyhBugecDhxBWfDSWMyw6NqIJtGtHoqmHSAKV7bxtV uAnB5amhjAN7tyoovHfiqvmOSEXHXhd+ZgSVT64Hn9f8ndGnsdbAnmy6lx YYCDasEh8cLiFXh3J316O9jRYkRHitJisyHGif4GpEPm1PHYxUQWFw==
Received: from l5580.localnet (wsip-68-224-171-140.sd.sd.cox.net [68.224.171.140]) by interserver.kitterman.com (Postfix) with ESMTPSA id 52DE9F80042 for <dmarc@ietf.org>; Wed, 17 Jul 2019 22:34:45 -0400 (EDT)
From: Scott Kitterman <sklist@kitterman.com>
To: dmarc@ietf.org
Date: Wed, 17 Jul 2019 22:34:43 -0400
Message-ID: <4249121.lBB2AW0kmB@l5580>
In-Reply-To: <E272FCC0-1616-4172-9B2D-D397EC2024FB@kitterman.com>
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <CABuGu1rSyifv0B9RtD3_R2ex-sh+nVrh4Q3H=kU=ZsDWzVRAgQ@mail.gmail.com> <E272FCC0-1616-4172-9B2D-D397EC2024FB@kitterman.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/fRMi5govIxB3GVix36gLnxVRH5Y>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 02:34:50 -0000

> On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" <kboth@drkurt.com>
> wrote:
> >Firstly, I'm a little concerned with the sentence which says 'Note that
> >"np" will be ignored for DMARC records published on subdomains of
> >Organizational Domains and PSDs due to the effect of the DMARC policy
> >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I
> >don't
> >think that is an accurate portrayal. When DMARC evaluation libraries
> >are
> >updated to do both PSD lookups and handle the np tag, I would expect
> >the
> >presence of np tags below the PSD level would be processed exactly the
> >way
> >that any other tag in a DMARC record is processed. np will only be
> >ignored
> >(per the terms of the DMARC spec) when it is an "unrecognized" tag. I
> >realized that this text is sort of picked up from the current
> >description
> >of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't
> >publish an np record on a non-existent Org domain or any subdomain
> >thereof

At first, I thought Kurt was right, but after further thought, I don't think 
so.

To review the 'sp' definition that I took this from:

Imagine sub.sub.example.com where example.com is the org domain.  If 
sub.sub.example.com has no DMARC record, then the next lookup is for a DMARC 
record at the org domain (example.com).  If sub.example.com has a DMARC record 
with an 'sp' tag, it's never retrieved.

The same thing would apply to 'np' when used in a non--PSD context.  No 
different.

Keeping in mind that our definition of non-existent is a domain that has none 
of A, AAAA, or MX.  It could have other types.  It could also have subdomains 
called "_dmarc" that have TXT records.  Non-existent domains (in our context) 
can have DMARC records, so I think the description is correct, but narrowly 
focused.

Modifying the example I used above slightly:

Imagine sub2.sub1.org.example where example has a PSD DMARC record with 'np', 
org.example has no DMARC record, sub1.org.example also has a DMARC record with 
'np', and sub2.sub1.org.example has no DMARC record.  In this case, the policy 
lookup is for sub2.sub1.org.example (exact domain), org.example (org domain), 
and then example (PSD).  Just as with 'sp' and regular DMARC, 'np' (or 'sp') 
in non-org subdomains of PSDs don't get discovered.

Scott K