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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FA05120089 for <>; Fri, 19 Jul 2019 05:04:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dIf2Rrxy3qNv for <>; Fri, 19 Jul 2019 05:04:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFE0F120019 for <>; Fri, 19 Jul 2019 05:04:33 -0700 (PDT)
Received: by with SMTP id y4so32036010wrm.2 for <>; Fri, 19 Jul 2019 05:04:33 -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=7XToM1EPxSERtMO8b+M9t4J/eZofKEqBYGhp9xykCpw=; b=l3PBVWtdIgJ32tyFdyepRfngRJmZtem3lusL7URZ6Uj2/s1hm5Jbp3Jcxgv73nvw5x FHo3B+wdrRCHJhehhC0K6KKBjcTDAhs5DuYZzZLNuqZ3t7ygJpLWwW2XjUKD10/YvsZC VI77dc1RkpFgv/+WwI31PmxxE6XScSwUFoip33bdjS//GiYAKcO6CHE4x7fyZoct0epZ 2zjx8hwDazEIpE+29xdHNx9c9J0cBALzCWZBca+eWC4u1mZC6crcg+JjctTqEKK45sJi OUoEPzYo9nSpG+OtIy2JPbY5j1kOoH1Ea5Y2tl9MOS3LuKE/ZEs4u7m75E2jMY3JJtjZ dbzw==
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=7XToM1EPxSERtMO8b+M9t4J/eZofKEqBYGhp9xykCpw=; b=Ubg32yMzG+JgND6WkxflAOuungxuEEJRSBceNg4qpoSNDsBWfQR4+E2WuqCEOlzRlE avqep7g/WxtvXkOdARkpkoL4uLGBer8d1bEg6j137T6drAPPSolU08JjQDOzM8LCmsrb hY2HXTx+iq1GGF57lTuYuItj5dfktqousUxg9hQqy7lEXGNv3Wfb1tpW/UXuSy1CxhXH PNYPv6W6kOFRduL1DaHN+LI/JR5UkM6Pnk8AvFmq13j/LxATPZdmNsHALg2aAVI5einO Ha1/GEob/LijvKIg741UILbyAV2Ha1t/ZIIPvt1Axwq1czoKJ2LxPIfGiGX9eRFUl317 DBDg==
X-Gm-Message-State: APjAAAWKBHz2eIxmNJIa0q7jvpxKdibACW0MbeiqD+YYU6PeDYs0/Wkg 2sL75/JZx9WwhjbssAANdnhs2vQePg3DePB6Op7rng==
X-Google-Smtp-Source: APXvYqwHoSzOS+DDK63Uabhj0QX0USzfOc23uH0wrMvTX8qQtJwE7Oh4xq3Yk+B/gy7imRsFxNqZnXj4lmRbdqX+OxU=
X-Received: by 2002:a5d:4484:: with SMTP id j4mr56280342wrq.143.1563537872336; Fri, 19 Jul 2019 05:04:32 -0700 (PDT)
MIME-Version: 1.0
References: <> <4249121.lBB2AW0kmB@l5580> <> <3280991.vD5HP6B0ME@l5580> <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
In-Reply-To: <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
From: Dotzero <>
Date: Fri, 19 Jul 2019 08:04:20 -0400
Message-ID: <>
To: Ian Levy <>
Cc: Scott Kitterman <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000793cb9058e07874a"
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, 19 Jul 2019 12:04:37 -0000

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.

Just a few thoughts.

Michael Hammer