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

Ian Levy <> Sat, 20 July 2019 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77FBC120134 for <>; Sat, 20 Jul 2019 02:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KleRhleUv2AU for <>; Sat, 20 Jul 2019 02:05:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02081120058 for <>; Sat, 20 Jul 2019 02:04:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=BynThPBcOZvIkAtVqVpLieWzLe+isfvFyFnX2Yshv+9qtIwdoV/wbNjaCgi7Cjlp2BBTR2feStbVciNcG/HEOga4wUTff2E3QCpFMd9qs9ZvU54FukxwVKu9FPusouMhe7oi517zrINK+35ZlBzpfFno1be61tNJJ0YRF7gZG/7ROaBc3mNyf1t5yvS+KhQZ/htPUY7zfsrnDQq+FFvHRGjWlQWQvzUho3I2MDb08bD9z9jrvo9EzOXq+7Y8plS2qroIH1+i7+i6hXgviJa52KrjNW6BPVnZBXi6edmG4gCgqyvKY7eHYTTTe475o0KoxyMuUCx9/BjR25DFPniUqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SPvy9FotbadlXLrl33D90SpicFg4v916kmx07Th8N8k=; b=SuXI337wX6Cv8eYBW8scLYKogqPUE+nDLM8BxpY5Ku/fYz6wZKFAYaXLY5nGqAjRJzUOO5S0FJStvVy72qBiBfXc7bUrVuvONDA8fZ1S1AZ7bI6S4lFnLzeOVga2fPB+X50G1X3Z+bC6DsiFcNEmM8DCa7ljyRqkn1q5vC0J5dzSMxe0wqPB/QQZziXwajjl0wYcuWI4fJxKvJswJ+sBBxZ8TgtyNOCXJcuRZPvblKjyOFiygjpJiAPUOAPs+BPeMVVoTMTprLc58n7ra1dE7kghDUuoGXyJ05WUz+T4v3ec9xTgEfhgImKExdLrX3bhzIF2LS3KLghuRvAqSYHoEw==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SPvy9FotbadlXLrl33D90SpicFg4v916kmx07Th8N8k=; b=C9bT8oE9tyC6uGmjMlRct/FPclGOkg+2OV1cG/5s+i9DI30t9ajY6KmdqzxVocu/r2qFHj0y73t3SVeqHqc4KVbSFDLzWpqOoiqkuiBHjwvFqdquy8SWQ4qUuFBUfiDJc6EnJtQwYHTQpu48pidkSyHApednOoJRdKpmhxmyuFo=
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ( by LO2P123MB2239.GBRP123.PROD.OUTLOOK.COM ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.14; Sat, 20 Jul 2019 09:04:57 +0000
Received: from LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0]) by LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM ([fe80::815e:ea4e:7133:7de0%5]) with mapi id 15.20.2094.013; Sat, 20 Jul 2019 09:04:57 +0000
From: Ian Levy <>
To: Scott Kitterman <>, "" <>
Thread-Topic: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
Date: Sat, 20 Jul 2019 09:04:57 +0000
Message-ID: <LO2P123MB2285EDA7977A5005136FBF21C9CA0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM>
References: <> <LO2P123MB2285D18172BC95D42A968B1CC9CB0@LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM> <> <2333259.aoXCTIVaPC@l5580>
In-Reply-To: <2333259.aoXCTIVaPC@l5580>
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 841ce6fa-a7d6-4fa3-ed1b-08d70cf156af
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LO2P123MB2239;
x-ms-traffictypediagnostic: LO2P123MB2239:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <LO2P123MB223901C038AE2F9D384CE714C9CA0@LO2P123MB2239.GBRP123.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:1201;
x-forefront-prvs: 0104247462
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(396003)(136003)(39850400004)(366004)(189003)(199004)(13464003)(66946007)(76116006)(8676002)(66446008)(68736007)(14454004)(52536014)(33656002)(66476007)(478600001)(66556008)(64756008)(86362001)(25786009)(74316002)(66066001)(966005)(7736002)(305945005)(45080400002)(2906002)(229853002)(256004)(14444005)(44832011)(486006)(81156014)(8936002)(81166006)(55016002)(6306002)(9686003)(6436002)(5660300002)(6246003)(99286004)(316002)(110136005)(53936002)(102836004)(476003)(6506007)(55236004)(53546011)(71190400001)(71200400001)(2501003)(7696005)(76176011)(3846002)(6116002)(26005)(11346002)(446003)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:LO2P123MB2239; H:LO2P123MB2285.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GQztNrE+RhzfMFJHSmc2f+/t8S7TWgqCe0wE0I+H6azzvElufDfPWazWycpSl+o0UfZlFhnymPh4/jNzTaC2kZJVddx/4dXrHXnYt1uSLhFuuCZR618g9iIXd/fdgn5Hg3hwQK0/6NO7PKDa9WvwTw3t4UoJ16oDJBqS0ELMSnMsrzwZGSAfB//7W1N45TZCCJx+4k9mGibz35o2ziu1dgiFusnMJEU9FvSDGcs5NNh0Pm+Q39rP+XAjV83zkBU4DTOXWJqdSd6c4euxQTU3EgbBuuvGpdT7K4hYhezqUVYbTFErAf+cQJpN42tjDcDjZtnxGrm4lu4OkMqcNreVCD/+2rqp6Mg8qnPO+/75tfKBh0Yy+DHxgJayiPcLZkkAS5ZSmu47fpm69stCz5qE0ml3EKlSJIIS1IFlJOJcbg4=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 841ce6fa-a7d6-4fa3-ed1b-08d70cf156af
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2019 09:04:57.6016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB2239
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 09:05:03 -0000

>> 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 document.




Dr Ian Levy
Technical Director
National Cyber Security Centre

Staff Officer : Kate Atkins,

(I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!)

-----Original Message-----
From: dmarc <>; On Behalf Of Scott Kitterman
Sent: 20 July 2019 04:15
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

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 document.

Scott K

dmarc mailing list;;sdata=Ng9fs%2FJa8R9Orm%2BPqtiq7IdLUXz0K%2FyyFLQRtGw%2FlJ4%3D&amp;reserved=0
This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to All material is UK Crown Copyright ©