Sorry for not contributing more to this thread - please don't take it as any 
indication of lack of interest. For UK NCSC specifically, I think we'd prefer 
NXDOMAIN rather than NODATA, given it's more constrained and this is an 
experiment. My view would be that if we've published a name under gov.uk, even 
with no valid (in the eyes of the receiver) associated records, then *someone* 
is responsible for it and we can go find and educate them. They may even 
believe they have a valid reason for doing so that may outweigh any email 
authentication concerns. But there's a conversation to be had. If there's no 
published name, then there's no-one responsible, so it should default to the 
top-level policy. 
 
We've learned a lot running our DMARC processing for gov.uk over the last 
couple of years and a lot about the consistency of how non-existent domains are 
treated, or lack thereof more to the point. If I'm honest, we see a lot of 
inconsistency in how DMARC is processed more generally that makes analysis 
harder than it needs to be. A lot of receivers have obviously made 
optimizations for their own specific circumstances. I'm just a little nervous 
of starting an experiment on a live and (some may argue) quite important PSD in 
anything other than a constrained manner. 

Incidentally, we *should* be publishing on ncsc.gov.uk our 2nd annual report on 
our Active Cyber Defence programme tomorrow (Tuesday). This includes a chapter 
on our DMARC experiences, including a bit of data relevant to this discussion, 
as well as some novel data science work on our DMARC report archive. As a 
preview, from July when we set the 'synthetic DMARC' record to p=reject, we've 
had this many reports : 
Month (2018)    Total reports
July            5,764
August          274,532 
September       127,901 
October         17,553 
November        17,191 
December        105,078 

We'll also publish a couple of examples of where synthesizing DMARC/SPF records 
for non-existent domains has helped stop abuse. However, it's clear that this 
method isn't universally accepted. 
Here's the volume of reports received on our normal DMARC processing chain in 
January 2019 (noting Microsoft are one of the bigger providers in the UK and 
*still* don't generate any reports): 

Reporter        Total Reports 
google.com      61,363,605 
Yahoo! Inc.     18,876,201 
Mail.Ru         699,554 
sercoglobal.com 227,587 
AMAZON-SES      178,262

And here's the volume for the same month for the synthetic DMARC reports : 
Reporter                Total Reports 
google.com              23,745 
Yahoo! Inc.             1,060 
emailsrvr.com           64 
dev.johnlewis.co.uk     37 
bridgend.gov.uk         30

Just from that, it's pretty clear that the synthesized DMARC records are not 
universally processed, which gives weight to completing this work and starting 
to try things out. Given the level of inconsistency we see in receiver 
behaviour, I think it'd be easier to start with NXDOMAIN and see what that 
actually achieves. 

I may well be missing something subtle, so please correct me if I've got this 
wrong. 

Ta.

I.
 
--
Dr Ian Levy
Technical Director
National Cyber Security Centre
[email protected]

Staff Officer : Kate Atkins, [email protected]

(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 <[email protected]> On Behalf Of Scott Kitterman
Sent: 13 July 2019 07:04
To: [email protected]
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last 
Call: draft-ietf-dmarc-psd

On Saturday, July 13, 2019 12:34:09 AM EDT John Levine wrote:
> In article <2902055.CzhLQO0xIX@l5580> you write:
> >Here's the definition we have in the draft now:
> >> 2.6.  Non-existent Domains
> >>
> >>    For DMARC [RFC7489] purposes, a non-existent domain is a domain name
> >>    that publishes none of A, AAAA, or MX records that the receiver is
> >>    willing to accept.  This is a broader definition than that in
> >>    NXDOMAIN [RFC8020].
> >
> >That's what I was expecting this new tag to apply to (and I think 
> >matches their expectation, but they can speak for themselves).
>
> That's OK.
>
> >Another way to say what's in 2.6 now might be:
> >
> >... a domain for which there is a NODATA response for A, AAAA, and MX 
> >records.
> Not so OK -- if there's no records at all at or below a name you 
> really will get NXDOMAIN.

Good point.  Thanks.  I'll leave it as is.

Scott K


_______________________________________________
dmarc mailing list
[email protected]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7C347777d406d8456ee39d08d70758084b%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636985946991033447&amp;sdata=S1HHVXL4ftxSYbFhTgxx1pXVcOT2o0S1PM%2B7sUCL9eo%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 
[email protected]

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to