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

Scott Kitterman <> Sat, 20 July 2019 03:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64E561200E7 for <>; Fri, 19 Jul 2019 20:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=Kmoz8cTK; dkim=pass (2048-bit key) header.b=NFOSi0rl
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dvl7rB7HkwUz for <>; Fri, 19 Jul 2019 20:15:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9455C12004E for <>; Fri, 19 Jul 2019 20:15:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id E2534F80499 for <>; Fri, 19 Jul 2019 23:15:06 -0400 (EDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=201903e; t=1563592506; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LG1oAzbOicY3NSY8WKn0KqxmHWk0gCGXoC00NP3Mou4=; b=Kmoz8cTKTC95Wo+eeYuW8KGT1MpG+x2/n25OjxzHMyH6SS3QBiTaszEs 9AX1pbCMzC7z6LRIwUl0gUVDdihiCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=201903r; t=1563592506; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from; bh=LG1oAzbOicY3NSY8WKn0KqxmHWk0gCGXoC00NP3Mou4=; b=NFOSi0rlkOo1kvaeAbyB88WCwO3D3KLKcTRRdEv3sYmXwfX2r9UPZU/E 6NTK0r4RwKlm6LA9XvW9+H7xOfkeA9ZkjB3GuHHmB22Z3b8jQbIDcmFU/g Pnb8MPJ6efpeVrVYTsVDiQLkobnDTJeh4hu5Rcw38y3vgKBJ/qf90Pjp07 0oG+RcFT6tQcvG/wGzltnuaqdYS2St0aePL6QOy8nbc5ordaauiHDORfcB tRNGIPLg3gJffXKj46svYRI4Bj7ubEm+3HP4+tMVI3IzLhp5+IBy7Y6wDq 13UpAXVfbZAgr3S4IDojO2LYUhk4KfHbvy5Aqr8mCZ1CWR27HrxzwA==
Received: from l5580.localnet ( []) by (Postfix) with ESMTPSA id 84255F80042 for <>; Fri, 19 Jul 2019 23:15:06 -0400 (EDT)
From: Scott Kitterman <>
To: "" <>
Date: Fri, 19 Jul 2019 23:15:04 -0400
Message-ID: <2333259.aoXCTIVaPC@l5580>
In-Reply-To: <>
References: <> <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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: Sat, 20 Jul 2019 03:15:40 -0000

On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote:
> I've been following the discussion but haven't contributed anything until
> this point. Comment below.
> On Fri, Jul 19, 2019 at 3:29 AM Ian Levy <ian.levy=
>> wrote:
> > > I think this is one of those "you must be this tall to ride on this
> > > ride"
> > > situations.  DNS comes equipped with multiple footguns and you have to
> > 
> > know a bit about what you're doing to make sure you get the effects you're
> > after.
> > 
> > This. DMARC today allows people to disconnect their outgoing mail from the
> > rest of the world. Admittedly, the PSD-level policies would have a much
> > greater effect, but your PSD/TLD operator can already bork you if they're
> > not competent.
> > There are two different buckets of risk in my view, though :
> > 1) New TLDs are effectively greenfield sites and can enforce appropriate
> > requirements on their customers from the start to minimize the chance of
> > unintended consequences (for example, by requiring domain DMARC labels).
> > 2) Existing TLDs, where there are many subdomains with wildly variable
> > implementations, policies and use and here we are going to have to be
> > really careful. Careful and methodical testing will be necessary to make
> > sure that introduction of the PSD-level policies doesn't break anything
> > important. It took us 6 months to get to synthesizing p=reject for
> > non-existent subdomains of A lot of that was analysing the data
> > we got back and fixing stuff that we never expected (like Kerberos - don't
> > ask!). I don't see why it would be different with the np= tag, but it will
> > hopefully be much more limited in what we could mess up.
> > 
> > I think we're really all worried about the second of these cases. If
> > that's true, then I'm with Scott - if you don't understand this stuff,
> > don't go and set an np tag on your PSD and cross your fingers. It's going
> > to end badly. One of the things about doing the experiment is surely to
> > help us understand how badly these can go wrong, so we can write down a
> > bunch of ways not to do things.
> > 
> > We can write in the document that scissors are sharp and running with
> > sharp things can cause problems. But in the end, someone is going to run
> > with scissors and get hurt. We can't code for every single case here and
> > we
> > surely must assume a level of competence of people implementing something
> > like this.
> The problem, which we know or should know, is that DNS records are
> apparently difficult to get right. We have a large corpus of data points to
> back this up based on decades of experience. Even large, supposedly
> experienced and technically qualified organizations shoot themselves in the
> foot. Speaking as an original participant in the team, I can't
> emphasize enough the education and evangelization effort involved related
> to adoption (and misunderstanding of how it works... or doesn't work).
> I think you are incorrect with your assumption regarding scenario #1. I
> recently had a discussion with an owner/operator of a number of "new" TLDs.
> They have no clue regarding this effort. So even if a TLD is new, that does
> not mean it will implement from day 1. This means scenario #2 is more
> likely the scenario to be dealt with (default) rather than #1. Perhaps
> after some extended period of pain or if ICANN mandates something, #1 will
> become the default, but I wouldn't hold my breath.
> With regard to scenario #2, it is not enough to simply say "don't run with
> scissors". Some group, M3AAWG or ICANN or ISOC, will need to educate and
> evangelize those outside the inner circle, so to speak. I'm sure that
> companies like Agari, Dmarcian, Valimail, etc. will gladly provide
> assistance., That TLD owner/operator I mentioned earlier is not overly
> familiar with the space or those vendors.
> It is not enough for the creators of a proposed standard to state it's
> technical validity. This implies a deployment document based on the
> experiences of early adopters.

I agree, but I think solving that is outside the scope of the current 

Scott K