Subject: Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd

From: Seth Blank <[email-masked]>
Date: Wed, 10 Jul 2019 13:21:08 -0700

There is one week left before WGLC closes, and the below three items still
need resolution. Please speak up!

-- Seth, as Secretary

On Wed, Jun 26, 2019 at 2:21 PM Seth Blank <[email-masked]> wrote:

> As Secretary, there are three items that have not yet reached consensus
> that must be resolved during WGLC:
>
> 1. What further context is needed in the introduction
> 2. If explicit call outs to ICANN/limited operator capacity to implement
> are needed
> 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs
>
> Seth
>
> On Wed, Jun 26, 2019 at 2:08 PM Murray S. Kucherawy <[email-masked]>
> wrote:
>
>> This message begins Working Group Last Call for draft-ietf-dmarc-psd,
>> which is currently at version 04.  An 05 may appear shortly with some text
>> changes that were previously discussed on the list; these do not include
>> any technical changes (I believe) so the author is free to update with only
>> those changes as planned.
>>
>> Please review the document and submit your feedback by Wednesday, July
>> 17th.  We would ideally like to have enough responses to support our claim
>> to the IESG that the document clearly has working group consensus.
>>
>> Note that we will be in pre-meeting draft embargo at that time so a new
>> version dealing with any feeback cannot appear until IETF 105 begins on the
>> 22nd.
>>
>> I'm planning to do my own review as the document shepherd with an eye
>> toward consumption by readers with only a passing familiarity with DMARC.
>> If anyone wants to join me in looking at it through that lens, you'd be
>> welcome.
>>
>> -MSK, co-chairin'
>> _______________________________________________
>> dmarc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
>
> --

*Seth Blank* | Director, Industry Initiatives
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential

and/or proprietary information intended solely for the use of

individual(s) authorized to receive it. If you are not an intended

and authorized recipient you are hereby notified of any use,

disclosure, copying or distribution of the information included in

this transmission is prohibited and may be unlawful. Please

immediately notify the sender by replying to this email and then

delete it from your system.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 10 Jul 2019 16:10:25 -0700

I, for one, would *really* like to see the rumored "next version" from
Scott and prefer to comment on that one, rather than an at-best penultimate
version.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Jul 2019 04:07:56 +0000

I don't plan any changes except for those in response to last call comments.  Unless I get direction otherwise, I don't plan any updates until after last call is over.

Please review this one.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 11 Jul 2019 12:07:50 +0200

On Wed 10/Jul/2019 22:21:08 +0200 Seth Blank wrote:> There is one week
left before WGLC closes, and the below three items
> still need resolution. Please speak up!
> 
> -- Seth, as Secretary
> 
> On Wed, Jun 26, 2019 at 2:21 PM Seth Blank <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     As Secretary, there are three items that have not yet reached
>     consensus that must be resolved during WGLC:
> 

IMHO, it is clear as is.

>     2. If explicit call outs to ICANN/limited operator capacity to
>     implement are needed

Appendix B.1 lacks a criterion to establish enlisting.  Couldn't we
require an explicit statement about seizing DMARC reports in, say, the
delegation report?  Alternatively, that policy can be stated in a
well-known place under the delegation services URL, so that
registrants know what they do.

>     3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs

Yes, it would allow p=reject; sp=none; (np=reject by default).

Some nits:

   (In the intro)  controls to mitigate
   potential privacy considerations associated with this extension

Don't mitigate considerations.  Mitigate risk, danger, whatever.

2.2.  Public Suffix Domain (PSD)

That paragraph sounds a bit confused.  The concepts of "private" vs.
"public" are not clear after having defined branded PSDs.  Perhaps it
is better to distinguish between single, central admin vs.
multi-organization, distributed responsibility.

The terms of Expert Review,per [RFC5226] (Appendix B.2) refer to a
IANA registry.  So, shouldn't the term "IANA" be stated in the title?
 (And a link to this appendix from the last bullet in Appendix A?)

jm2c
Ale
--

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 11 Jul 2019 10:29:32 +0000

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Scott Kitterman
> Sent: Thursday, July 11, 2019 12:08 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [dmarc-ietf] Working Group Last Call: draft-ietf-
> dmarc-psd
>
> I don't plan any changes except for those in response to last call comments.
> Unless I get direction otherwise, I don't plan any updates until after last call is
> over.
>
> Please review this one.

Repeating what I suggested earlier:

https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk

Scott

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2019 20:54:42 -0400

>https://mailarchive.ietf.org/arch/msg/dmarc/1jAgGtNiyR3YuvJg1dciWVHU2Pk

That seems OK to me.  We don't need to say anything specifically to
ICANN.  Should PSD turn out to be popular, this will be an input to an
ICANN process to allow the PSD record at the top of a TLD zone.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:22:21 -0400

> 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs

It's been a pretty quiet last call.  I think the document itself is probably 
in pretty good shape with these questions as outliers.  Shortly I plan to send 
a separate email on each of these with my perspective on both the issue and my 
read of the discussion so far so we can focus on driving each question to 
closure.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:26:40 -0400

> 1. What further context is needed in the introduction

The only comment on this so far during WGLC is that it is clear as is.

As the document author, this is one I have a hard time assessing.  It's clear 
to me, but I know what I meant when I wrote it.  If anyone is still concerned 
about this issue, I would strong encourage you to provide suggested text.

I think the WG should be pretty open to accepting such changes (as long as 
they are technically accurate).  Even if it makes the document a bit longer, I 
think clarity is worth it.

Standing by for inputs/feedback.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:30:35 -0400

> registrants know what they do.

It's in the appendix because we don't have a clear path forward.  This is part 
of the experiment.  We need to be careful though since different PSDs operate 
under different authorities and controls, so there is a point beyond which it's 
not the IETF that decides.

Scott K

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Jul 2019 17:31:40 +0000

> Sent: Friday, July 12, 2019 1:27 PM
> To: [email-masked]
> Subject: [EXTERNAL] [dmarc-ietf] Introduction context was: Re: Working
> Group Last Call: draft-ietf-dmarc-psd
>

Perhaps you missed this original comment:

Last call version:

https://mailarchive.ietf.org/arch/msg/dmarc/jzEqKAF_OqxBm35QW3rQoAglm_A

Reply from John Levine:

https://mailarchive.ietf.org/arch/msg/dmarc/2AIp6oZmPMeqVxGOHcY1ct_iv7E

> As the document author, this is one I have a hard time assessing.  It's clear to
> me, but I know what I meant when I wrote it.  If anyone is still concerned

I included suggested text in the original note described above.

Scott

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:33:43 -0400

> Perhaps you missed this original comment:

...

That's issue #2 in Seth's email.  I'm writing that one up right now.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:41:17 -0400

> 2. If explicit call outs to ICANN/limited operator capacity to implement

There has been feedback in favor of adding this and none against so far.

The specific proposal is:

"Please note that today's operational and policy reality prevents this 
experiment from being deployed globally.  If the experiment shows that PSD 
solves a real problem at a large scale, the results could prove to be useful 
in the development of policies outside of the IETF that would permit its 
ubiquitous deployment."

Because RFCs are (approximately) forever, I'm concerned about words like 
"today's" in protocol documents, even experimental ones.

How about this instead:

"As of the writing of this document operational and policy constraints prevent 
this experiment from being deployed globally.  If the experiment shows that 
PSD solves a real problem and can be used at a large scale, the results could 
prove to be useful in the development of policies outside of the IETF that 
would permit broader deployment".

Also, since this is about ephemera and not protocol, I think it should go in 
Appendix A.

Comments?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:49:17 -0400

> 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs

The limited feedback during WGLC has been favorable to this.

This will require a rather larger change to the document than the other 
issues, but they are manageable and I believe I have most of the relevant text 
from earlier revisions.

I think we should include this.  As discussed in the previous issue, the PSDs 
that can deploy PSD DMARC today is limited.  One of the few that are engaged 
with this effort that can has specifically requested it as a support to their 
broader DMARC deployment efforts within their PSD.  Additionally, this may have 
utility for regular DMARC and now is a good time to explore the concept.

Unless this is clearly negatively received, I'll propose specific changes to 
support it later today.  I'll also update the existing implementation that's 
mentioned in Appendix C, but probably not today.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 13:50:58 -0400

...

Additionally, if anyone else has code for this, please let me know so I can 
update Appendix C.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 12 Jul 2019 10:54:57 -0700

On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman <[email-masked]>
wrote:

> I think we should include this.
>

I am much more concerned with adding another tag that can only be used in a
PSD-DMARC record. I would be much more open to make a "normative" change to
the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC
record, than to make this a special case for PSD-DMARC records.

--Kurt

---

From: "Stan Kalisch" <[email-masked]>
Date: Fri, 12 Jul 2019 13:59:55 -0400

> would permit broader deployment".

"[D]evelopment of policies outside of the IETF" strikes me as a little odd since IETF isn't setting policy *per se*, although substitute language that is just as succinct is escaping me at the moment.

Thanks,
Stan

---

From: Seth Blank <[email-masked]>
Date: Fri, 12 Jul 2019 11:15:51 -0700

On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) <[email-masked]> wrote:

> I am much more concerned with adding another tag that can only be used in
> a PSD-DMARC record. I would be much more open to make a "normative" change
> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC

I am also concerned with adding any new policy-related tags, due to the
confusion they create that limits adoption. However, a very clear case for
an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov and
.mil have stated they also want this behavior. Others have shared similar
opinions privately.

Since PSD is an experiment, I think this is a fine place to test an np=
tag. If it gets usage, then we have a clear argument for it being a normal
tag for DMARCbis. If not, then it can be jettisoned altogether.

Adding this tag for PSD will simply need explanatory text in the
Experimental Considerations outlining this.

Seth

---

From: Dotzero <[email-masked]>
Date: Fri, 12 Jul 2019 14:25:33 -0400

+1 Your proposed rewording makes sense.

Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 14:27:05 -0400

On Friday, July 12, 2019 1:59:55 PM EDT Stan Kalisch wrote:
> > solves a real problem at a large scale, the results could prove to be
> > useful in the development of policies outside of the IETF that would
> > permit its ubiquitous deployment."
> > 
> > "As of the writing of this document operational and policy constraints
> > prevent this experiment from being deployed globally. If the experiment
> > shows that PSD solves a real problem and can be used at a large scale,
> > the results could prove to be useful in the development of policies
> > outside of the IETF that would permit broader deployment".
> 
> "[D]evelopment of policies outside of the IETF" strikes me as a little odd
> since IETF isn't setting policy *per se*, although substitute language that
> is just as succinct is escaping me at the moment.

... removal of constraints ... ???

"As of the writing of this document operational and policy constraints prevent 
this experiment from being deployed globally. If the experiment shows that PSD 
solves a real problem and can be used at a large scale, the results could 
prove to be useful in the removal of constraints outside of the IETF that 
would permit broader deployment".

Better?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 14:28:39 -0400

> record, than to make this a special case for PSD-DMARC records.

I agree.  My intent is to add the tag to be used experimentally for any DMARC 
record.  Part of the experiment is to see if it's useful beyond PSD.

Scott K

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Jul 2019 18:28:45 +0000

> Sent: Friday, July 12, 2019 2:27 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [dmarc-ietf] Mention ICANN/operational limitations
> was: Re: Working Group Last Call: draft-ietf-dmarc-psd
>
> > > "Please note that today's operational and policy reality prevents
> > > this experiment from being deployed globally. If the experiment
> > > shows that PSD solves a real problem at a large scale, the results
> > > could prove to be useful in the development of policies outside of
> > > the IETF that would permit its ubiquitous deployment."
> > >
> > > Because RFCs are (approximately) forever, I'm concerned about words
> > > like "today's" in protocol documents, even experimental ones.
> > >
> > > How about this instead:
> > >
> > > "As of the writing of this document operational and policy
> > > constraints prevent this experiment from being deployed globally. If
> > > the experiment shows that PSD solves a real problem and can be used
> > > at a large scale, the results could prove to be useful in the
> > > development of policies outside of the IETF that would permit broader
> deployment".
> >
> > "[D]evelopment of policies outside of the IETF" strikes me as a little
> > odd since IETF isn't setting policy *per se*, although substitute
> > language that is just as succinct is escaping me at the moment.
>
> .... removal of constraints ... ???
>
> shows that PSD solves a real problem and can be used at a large scale, the
> results could prove to be useful in the removal of constraints outside of the
> IETF that would permit broader deployment".
>
> Better?

Either one works for me.

Scott

---

From: "Stan Kalisch" <[email-masked]>
Date: Fri, 12 Jul 2019 14:32:33 -0400

> would permit broader deployment".

I think so. "[I]n removing constraints" would flow a little better, but yeah.

Thanks,
Stan

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2019 15:13:48 -0400

In article <CAD2i3WNigYz8vk-FwFCgy0y=[email-masked]> you write:
>-=-=-=-=-=-

How do they feel about NODATA, which is not the same as NXDOMAIN?

R's,
John

---

From: Dotzero <[email-masked]>
Date: Fri, 12 Jul 2019 15:33:46 -0400

On Fri, Jul 12, 2019 at 2:16 PM Seth Blank <[email-masked]> wrote:

> an NXDOMAIN policy has been made by UK NCSC for .gov.uk, and both .gov
> and .mil have stated they also want this behavior. Others have shared
> similar opinions privately.
>
> Experimental Considerations outlining this..
>
> Seth
>

I agree with the concern expressed and the approach outline. I do have a
concern as to the number of validators which will consider implementing
this. Will it be added to OpenDMARC?

Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 16:34:20 -0400

On Friday, July 12, 2019 3:13:48 PM EDT John Levine wrote:
> In article <CAD2i3WNigYz8vk-
> How do they feel about NODATA, which is not the same as NXDOMAIN?

Although Seth said NXDOMAIN, he didn't really mean that DNS rcode.

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

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.

We could then drop the second sentence and swap the informative RFC 8020 
reference for a normative reference to RFC 2308.  The RFC 8020 updates to 2308 
don't seem germane to this issue.

I think that's equivalent to what's in 2.6 now, but states it more clearly in 
actionable DNS terminology.

Comments?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Jul 2019 22:08:18 -0400

On Friday, July 12, 2019 1:26:40 PM EDT Scott Kitterman wrote:
> As the document author, this is one I have a hard time assessing.  It's
> clear to me, but I know what I meant when I wrote it.  If anyone is still
> concerned about this issue, I would strong encourage you to provide
> suggested text.
> 
> they are technically accurate).  Even if it makes the document a bit longer,
> I think clarity is worth it.
> 

I think Tim's suggestions are a good response to this issue:

https://mailarchive.ietf.org/arch/msg/dmarc/e7aDFcxDdJPI2Sj4jMqGLmDhmKc

Unless someone else has other opinions (I know Kurt brought some things up 
that this doesn't cover, but we should address those separately), I think 
these changes should be applied.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 13 Jul 2019 00:34:09 -0400

>their expectation, but they can speak for themselves).

That's OK.

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

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Jul 2019 02:04:04 -0400

> Not so OK -- if there's no records at all at or below a name you really will

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

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Jul 2019 19:21:31 +0200

> would permit broader deployment".

I'm not familiar with operating a TLD.  The above text seems to imply
that TLD operators cannot just edit their zone files as they like.  In
that case, couldn't that statement be more explicit?  In particular,
what does allow the experiment to be deployed locally?

> Also, since this is about ephemera and not protocol, I think it should go in 

Makes sense.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Jul 2019 19:22:15 +0200

> not the IETF that decides.

I should have written more clearly the two issues.  One is the
criterion.  I hypothesized that all what is needed to gran enlistment
to a PSO is that its policy to seize DMARC at PSD level be published,
so that registrant can learn about is before registering.  Is that
correct?  I mean does a public statement suffice?

The second issue is how to publish. In case the answer to the 1st
question is yes, would https://PSO.tld/.well-known/dmarc-psd/policy do?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Jul 2019 18:42:03 +0000

On July 13, 2019 5:21:31 PM UTC, Alessandro Vesely <[email-masked]> wrote:
>constraints prevent 
>shows that 

Some can, some can't.  It's complicated and it's nothing to do with IETF protocol, so I don't think it's on topic to go into any details.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Jul 2019 15:06:00 -0400

On Saturday, July 13, 2019 1:22:15 PM EDT Alessandro Vesely wrote:
> > It's in the appendix because we don't have a clear path forward.  This is
> > part of the experiment.  We need to be careful though since different
> > PSDs operate under different authorities and controls, so there is a
> > point beyond which it's not the IETF that decides.
> 

I don't think we want a novel policy record location for PSD.  We did discuss 
this and concluded _dmarc.PSD is appropriate to remain aligned to DMARC.

In my view the challenge around which PSDs receivers should check for a PSD 
DMARC record needs to be external to the PSD (i.e. not a self-assertion).  
Some options are presented in Appendix A.  If, as a result of the experiment, 
it's concluded that self-assertion is acceptable, then all that's needed is to 
publish the record.  I don't think we need a second place to look up to tell 
receivers to do the record lookup.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Jul 2019 15:34:51 -0400

On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote:
> > > issues, but they are manageable and I believe I have most of the
> > > relevant
> > > text
> > > from earlier revisions.
> > > 
> > a
> I agree.  My intent is to add the tag to be used experimentally for any
> DMARC record.  Part of the experiment is to see if it's useful beyond PSD.

Attached is my proposed text to add the np tag.  Based on the discussion to 
date, I assume I'll be asked to add something like this after last call is 
complete, so please let me know how to make it better.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 14 Jul 2019 12:12:42 +0200

> would permit broader deployment".

I reply here to the other thread,[*] where you said "Some can, some can't."  For the sake of comprehensibility, could that be spelled out a little bit more clearly?  For example like so:

    As of the writing of this document, there are operational
    and policy constraints which prevent this experiment from
    being deployed globally.  While it is beyond the scope of
    this document to delve into the details,  be it enough to
    mention that not all PSOs are actually able to publish
    DMARC records as needed.  Those who are able to do so and
    wish to participate in the experiment should contact
    DMARC-PSD.org in order to have their PSD enlisted.  If the
    experiment shows that DMARC-PSD solves a real problem and
    can be used at a large scale, the results could prove to
    be useful in removing those constraints, so as to permit
    broader deployment.

Best
Ale
-- 

[*] Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/_WjDZj17qySDLcIWlcCIan54s0A>

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 14 Jul 2019 12:19:50 +0200

On Sat 13/Jul/2019 21:06:00 +0200 Scott Kitterman wrote:
>> I hypothesized that all what is needed to gran enlistment to a
>> PSO is that its policy to seize DMARC at PSD level be published, 
>> so that registrant can learn about is before registering.  Is
>> that correct?  I mean does a public statement suffice?>>
> 

Agreed.  However, even if it were written in the delegation record at
IANA, it would still have to have been initiated by the PSO.  So the
requirement is a sort of validated/ agreed upon self-assertion.

>From an implementer's POV, having a short list to complement the PSL,
to be updated not very often, sounds convenient.  For the algorithm, a
few extra string comparisons are still quicker than one more DNS lookup.

In addition, the organization who publishes that list qualifies as an
authority for monitoring those self-assertions.  It can tell when a
PSO first published its policy, and hence which registrants could have
operated their 2nd or 3rd level domain without being aware of that.
If it's important to preserve mail site operators' rights, that is.

Best
Ale
--

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 14 Jul 2019 11:51:40 -0400

I'm good with either of Scott's wordings on this.

I guess I'm making an assumption that the TLD operators know what they can
and can't do
(but that may be a horrible assumption).

Tim
(no hats)

On Sun, Jul 14, 2019 at 6:13 AM Alessandro Vesely <[email-masked]> wrote:

> implement
> like
> odd
> prevent
> I reply here to the other thread,[*] where you said "Some can, some
> can't."  For the sake of comprehensibility, could that be spelled out a
> little bit more clearly?  For example like so:
>
> [*] Archived-At: <
> https://mailarchive.ietf.org/arch/msg/dmarc/_WjDZj17qySDLcIWlcCIan54s0A>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Ian Levy <[email-masked]>
Date: Mon, 15 Jul 2019 07:08:04 +0000

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-masked]

Staff Officer : Kate Atkins, [email-masked]

(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-masked]> On Behalf Of Scott Kitterman
Sent: 13 July 2019 07:04
To: [email-masked]
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:
> >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.
>

Scott K

_______________________________________________
dmarc mailing list
[email-masked]
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-masked]

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 15 Jul 2019 08:30:35 -0400

I totally agree with the logic behind the experiment.

>From a document point of view, should we not document the 'np' part of the
experiment?

"The experiment will also evaluate the effectiveness of the 'np' tag for
non-existent subdomains. "

Tim

On Fri, Jul 12, 2019 at 2:28 PM Scott Kitterman <[email-masked]>
wrote:

> DMARC

---

From: Richard C <[email-masked]>
Date: Tue, 16 Jul 2019 08:20:12 +0000

I'm happy with the proposal but just wanted to flag that you have a typo for the tag name in section 3.3 - you use 'sp' rather than 'np'

Thanks

Richard

| -----Original Message-----
| From: dmarc <[email-masked]> On Behalf Of Scott Kitterman
| Sent: 13 July 2019 20:35
| To: [email-masked]
| Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group
| Last Call: draft-ietf-dmarc-psd
|
| On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote:
| > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote:
| > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman
| > > <[email-masked]>
| > >
| > > wrote:
| > > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
| > > > > 3. If an np= tag is needed to allow PSD functioning for only
| > > > > NXDOMAINs
| > > >
| > > > The limited feedback during WGLC has been favorable to this.
| > > >
| > > > This will require a rather larger change to the document than the
| > > > other issues, but they are manageable and I believe I have most of
| > > > the relevant text from earlier revisions.
| > > >
| > > > I think we should include this.
| > >
| > > I am much more concerned with adding another tag that can only be
| > > used in a PSD-DMARC record. I would be much more open to make a
| > > "normative" change to the DMARC tag list (RFC 7489 section 11.4) to
| > > define np for any DMARC record, than to make this a special case for
| > > PSD-DMARC records.
| >
| > I agree.  My intent is to add the tag to be used experimentally for
| > any DMARC record.  Part of the experiment is to see if it's useful beyond
| PSD.
|
| Attached is my proposed text to add the np tag.  Based on the discussion to
| date, I assume I'll be asked to add something like this after last call is
| complete, so please let me know how to make it better.
|
| Scott K
| 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-masked]
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-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 16 Jul 2019 16:53:05 +0200

> 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 mo…

I agree that np should default to p.  The original wording for sp is also simpler than''If absent, the policy specified by the "sp" (if present) and then the "p" tag, if not, MUST be applied for non-existent subdomains.''  (BTW, mind that "sp" instead of "np" in the new tag's definition.)

> [...] 

That is at odds with the order reported by dmarcian:

NetEase (163.com, 126.com, yeah.net)
Google *
Yahoo!
Microsoft
AOL
cisco Systems
DHL
Comcast *
Tencent (qq.com)
Mail.ru
... https://dmarc.org/stats/dmarc-reporting/
(That used to be on dmarcian, but couldn't find it any more)

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

Hmm...  Mail.ru reports seem to be missing from non-existing domains.  My experience differs slightly.  Yesterday I sent a few messages to mail.ru.  Five of them from a nonext domain (IP 5.170.8.66), all of which were rejected, two of which were reported in the aggregate report attached.  However risible these numbers may sound when compared to yours, it is clear that not all messages are reported.

It is possible that some cases of non-existent domain are treated as a short-cut, skipping message registration and DMARC verification altogether, even if the reject always came after DATA...  Just mumbling.  Considering that most DMARC packages work as mail filters, I'd expect messages filtered out before will never make their way to aggregate reports.  Is that a DMARC violation?

Best
Ale
-- 

Subject: Report Domain: tana.it; Submitter: Mail.Ru; Report-ID: 68064799912189070641563148800
From: [email-masked]
To: [email-masked]
Date: Tue, 16 Jul 2019 02:55:02 +0300

Feedback from
Mail.Ru

Id: 68064799912189070641563148800; begin: 2019-07-15T00:00:00Z; end: 2019-07-16T00:00:00Z
Domain: tana.it; DKIM: relaxed; SPF: relaxed; policy published: none none 100

Relaying IP

message count

reason and disposition

From header

(opt. envelope)

SPF

DKIM

5.170.8.66

1

nonext.tana.it

me

5.170.8.66

1

nonext.tana.it

tana.it

82.195.75.100

7

tana.it

lists.debian.org

tana.it

62.94.243.226

1

tana.it

tana.it

tana.it

Legend

disposition: quarantine,
reject.
spf: pass,
fail,
softfail,
temperror or permerror.
dkim: pass,
fail,
policy.

This is an aggregate report from Mail.Ru.

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Tue, 16 Jul 2019 16:14:54 +0000

I recently joined this working group from the United States Department of Defense (DoD), which runs the .mil TLD. We appreciate all the work that has been done so far on DMARC and are currently investing significant efforts to implement DMARC broadly across DoD domains.  We value and support this PSD DMARC draft and experiment and see how it will complement the existing DMARC effort for us and many others by being able to broadly apply DMARC at TLDs and PSDs when subdomains are missing their own DMARC records and for non-existent subdomains, which are significant gaps today.

I agree with the suggestion below that the default policy for non-existent sub-domains should be the domain's policy if the "np" tag is absent, rather than defaulting to the "sp" tag's policy.

A few minor suggestions:

In section 4, "requiremetns" should be "requirements".

In section 4.1, there is an extra "be", so "This leakage could be potentially be utilized ..." should be "This leakage could potentially be utilized ...".

In appendix B, "faciliate" should be "facilitate".

Sincerely,

-Eric

________________________________

Eric Chudow

DoD Cybersecurity Mitigations

________________________________
From: Alessandro Vesely <[email-masked]>
Sent: Tue, 16 July 2019 14:53 UTC
To: [email-masked]
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

---

From: Ian Levy <[email-masked]>
Date: Tue, 16 Jul 2019 17:34:10 +0000

> Mail.ru reports seem to be missing from non-existing domains.  

Yep, that's our experience. We get plenty of DMARC reports from mail.ru in the course of normal business; just not in the non-existent domain case. Interesting that your experience was different, though. 

> It is possible that some cases of non-existent domain are treated as a short-cut

That's certainly my assumption.

I think the point is that the current behaviour is inconsistent (even more inconsistent than 'real DMARC'), hence the need for this experiment. I mentioned the report yesterday. It's now published and linked off here : https://www.ncsc.gov.uk/blog-post/active-cyber-defence--acd---the-second-year

There's a whole section on our experience and work on DMARC that may be interesting to the group, including some of the effects of the specific problem we're talking about here. 

Ta.

I.

(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-masked]> On Behalf Of Alessandro Vesely
Sent: 16 July 2019 15:53
To: [email-masked]
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

NetEase (163.com, 126.com, yeah.net)
Google *
Yahoo!
Microsoft
AOL
cisco Systems
DHL
Comcast *
Tencent (qq.com)
Mail.ru
.... https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdmarc.org%2Fstats%2Fdmarc-reporting%2F&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cb422dd587d5543c6142908d709fd6300%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636988856820114383&amp;sdata=8ikFqwHQDkEaOQVJslti2vYNp8jYWU4C7omM7SJAAuY%3D&amp;reserved=0
(That used to be on dmarcian, but couldn't find it any more)

Best
Ale
--

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-masked]. All material is UK Crown Copyright ©

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 00:14:55 -0400

I was slightly more verbose.  I'll send the updated diff for 'np' once I get 
through my email backlog.

Scott K

On Monday, July 15, 2019 8:30:35 AM EDT Tim Wicinski wrote:
> > > > > 3. If an np= tag is needed to allow PSD functioning for only
> > 
> > NXDOMAINs
> > 
> > > I am much more concerned with adding another tag that can only be used
> > 
> > in a
> > 
> > > PSD-DMARC record. I would be much more open to make a "normative" change
> > 
> > to
> >

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 00:40:29 -0400

Fixed.  Thanks.

Scott K

On Tuesday, July 16, 2019 4:20:12 AM EDT Richard C wrote:
> I'm happy with the proposal but just wanted to flag that you have a typo for
> the tag name in section 3.3 - you use 'sp' rather than 'np'
> 
> Thanks
> 
> Richard
> 
> | > any DMARC record.  Part of the experiment is to see if it's useful
> | > beyond
> | 
> | PSD.
> | 
> | Attached is my proposed text to add the np tag.  Based on the discussion
> | to
> | This information is exempt under the Freedom of Information Act 2000
> | (FOIA)
> 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-masked]
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 01:00:47 -0400

On Tuesday, July 16, 2019 12:14:54 PM EDT Chudow, Eric B CIV NSA DSAW (USA) 
wrote:
> I recently joined this working group from the United States Department of
> Defense (DoD), which runs the .mil TLD. We appreciate all the work that has
> been done so far on DMARC and are currently investing significant efforts
> to implement DMARC broadly across DoD domains.  We value and support this
> PSD DMARC draft and experiment and see how it will complement the existing
> DMARC effort for us and many others by being able to broadly apply DMARC at
> TLDs and PSDs when subdomains are missing their own DMARC records and for
> non-existent subdomains, which are significant gaps today.
> 
> 
> 
> I agree with the suggestion below that the default policy for non-existent
> sub-domains should be the domain's policy if the "np" tag is absent, rather
> than defaulting to the "sp" tag's policy.

Although a few people have suggested this, I think it would be a mistake 
because it would cause a gratuitous incompatibility with RFC 7468.

Current behavior (where np is not defined) is for sp to apply to all domains, 
existing or not.  No distinction is made.  Consider the effect of the two 
different approaches:

Example:

p=reject
sp=none
np=quarantine

A receiver that is not a participant in the experiment will process the policy 
for a non-existent subdomain as none (since they don't recognize np).

This is equivalent to:

p=reject
sp=none

I think it is a desirable characteristic that the addition of np not disturb 
existing expectations.  If a recipient that is a participant in the experiment 
attempts to determine policy for a sub-domain without 'np', then the result 
should match what a non-participant gets.

If no 'np' falls back to 'p', then the policy is reject, which will  have a 
negative interaction with non-participants.  If the policy falls back to 'sp', 
then the result is the same whether the recipient is a participant or not.

Also, keep in mind, that if 'sp' is not present, it falls back to 'p', so 
falling back to 'sp' first is not a dead end.

Fixed.  Thanks.

> In section 4.1, there is an extra "be", so "This leakage could be
> potentially be utilized ..." should be "This leakage could potentially be
> utilized ....".

Fixed.  Thanks.

> In appendix B, "faciliate" should be "facilitate".

Fixed.  Thanks,
...

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 01:07:05 -0400

On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote:
> > > in

Updated rfcdiff attached.  The only change other than typos is to add mention 
of 'np' to Appendix A.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 01:18:50 -0400

On Friday, July 12, 2019 1:22:21 PM EDT Scott Kitterman wrote:
> in pretty good shape with these questions as outliers.  Shortly I plan to
> send a separate email on each of these with my perspective on both the
> issue and my read of the discussion so far so we can focus on driving each
> question to closure.

I think we've had some good discussion since Friday.  Here's where I think we 
are now:

#1.  I think we incorporate both the specific suggestions Tim Draegen made 
earlier in the month and we should incorporate changes from Kurt Andersen in 
https://mailarchive.ietf.org/arch/msg/dmarc/7Qjo6oEoUpPGvCWVFZHyBeCDI44 :

Drop the sentence from section 1, make the 2.2 change, drop willing to accept 
in 2.6 (which I think cures the section 4 comment), and make the 3.5 change.  
Addition of np is covered in #3.

#2.  I think we've worked out text and we just need to add it.

#3.  I think we're close on text with the only open questions being does np 
fall back to sp or p and do people agree with the Appendix A words.

Pretty close.  If the group accepts my rationale for the sp fallback, then I 
think it's pretty clear what changes the document needs after last call.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 16 Jul 2019 22:18:50 -0700

As an individual-

> because it would cause a gratuitous incompatibility with RFC 7468.

The people suggesting this are the people asking for np= in the first place.

> should match what a non-participant gets.

I'm not certain this is desirable for PSD in the context of an experiment
around np=.

Specifically, the point of np= is for strict enforcement for non-existent
domains while the remainder of the zone gets its act together moving
registered domains to policies more strict than none. Since, a) nearly all
sp= policies in the world are set to "none", and b) sp= is meaningless at
the PSD level anyway, I concur that np= should default to p=.

Or put a different way, the tags serve very different use cases, and in the
wild, sp= will generally be none, whereas np= will generally be
reject/quarantine. p= is the the meaningful tie-breaker here at the PSD
level if no np= is set.

This (np='s default) should also be called out as part of the experiment
around np if the group doesn't reach consensus before WGLC ends tomorrow.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 01:39:41 -0400

> around np if the group doesn't reach consensus before WGLC ends tomorrow.

Let's be clear:  If the experiment around 'np' is successful and it is 
included in a future non-experimental update, then it will have enough 
deployment that changing its behavior will almost certainly fall into the too 
hard bucket without an amazingly good reason.  While the experiment may 
conclude 'np' isn't worth doing, I think we should assume that if it is 
carried forward, then it will be the way we define it in this document.  So, 
"It's an experiment" is not, in my view, a useful reason to accept 
interoperability issues we can avoid.

I think you are reading the request backwards.

Yes, the point of 'np' is to allow for a stricter sub-domain policy, but 
that's to support early deployment of strict PSD level policies without 
breaking org domains that are still deploying/have not deployed DMARC.

Case:

PSO mandates all orgs deploy DMARC, but that's not done yet.  PSO wants to 
deploy PSD DMARC for reject at the PSD level and for non-existent domains, but 
leave non-DMARC deployed existing domains at none.  PSO publishes these 
policieis for the PSD:

p=reject, sp=none, np=reject

Results (for org domains)

Org domain with DMARC: Use org policy
Org domain with no DMARC:
         Regular DMARC: No DMARC policy, no feedback
         PSD DMARC receiver: policy is none, feedback to PSO if requested
Non-existent domain:
         Regular DMARC: No DMARC policy, no feedback
         PSD DMARC receiver: policy is reject, feedback to PSO if requested

Having 'np' fall back to 'p' doesn't actually solve the problem you claim to 
be solving since it only affects non-implementers.

I believe that's the exact requested case and the changeset I've provided 
supports that without creating a situation where every implementer of the 
experiment suddenly starts processing existing DMARC records differently (which 
I think would be very bad).

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 16 Jul 2019 22:54:41 -0700

> breaking org domains that are still deploying/have not deployed DMARC.

I absolutely agree with this.

> p=reject, sp=none, np=reject

Ah, I see what you're saying here. I honestly couldn't understand why you
were talking about sp=none at all within a PSD context. I thought the
solution to this scenario was to do as the PSO p=none; np=reject. I
actually like p=reject; sp=none; better here, because that lets the PSD
lock itself down as a sending domain. But to me, this also makes it clear
that np= should use the p= not the sp= as its default.

That said, I feel less strongly about this now, and can see merit in
inheritance from either side (or from a hard default of none, for that
matter, although I'd strongly argue against that personally...).

> be solving since it only affects non-implementers.

This I don't understand. The results you outlined are exactly what I think
should happen.

> I think would be very bad).

I don't think I properly understand what you're saying. Can you clarify
this point?

Thanks!

S

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 06:26:25 +0000

On July 17, 2019 5:54:41 AM UTC, Seth Blank <[email-masked]> wrote:
>> deploy PSD DMARC for reject at the PSD level and for non-existent
>domains,
>> but

See if you still feel that way after considering backward compatibility ...

>> Having 'np' fall back to 'p' doesn't actually solve the problem you
>claim
>> to

I think we agree on the goal, the difference is only about implementation details and impact on non-particpants in the experiment.
>> experiment suddenly starts processing existing DMARC records
>differently
>> (which

Keep in mind that senders do send from what we call non-existent domains for reasons that seem good and sufficient to them.  Let's take that as a fact, whether it makes sense to us or not.

Sender (who knows nothing of our experiment) has published a DMARC record that includes:

p=reject, sp=none

When a DMARC compliant receiver receives mail from a subdomain of that organization domain, the policy to apply is none.

If our experiment has 'np' fall back to 'sp', then the non-particpant gets the same result.  An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'sp' (none - 'np' fallback) for a non-existing sub-domain.

If our experiment has 'np' fall back to 'p', then the non-particpant gets a different result.  An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'p' (reject - 'p' fallback) for a non-existing sub-domain.

Keep in mind, this isn't just about receiver processing.  The policy applied is also in the aggregate reports.

I think changing existing defined behavior for non-participants in an experiment is not appropriate.  It's even more unacceptable in a case like this where we absolutely don't need it to achieve the desired behavior within the experiment.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jul 2019 00:45:02 -0700

> ICANN process to allow the PSD record at the top of a TLD zone.

+1.

-MSK, participatin'

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 17 Jul 2019 08:29:17 -0400

Thanks for the update Scott, and your wording on the 'np' tag in the
Appendix works.

I just want to call out your statement:

I think changing existing defined behavior for non-participants in an
experiment is not appropriate.  It's even more unacceptable in a case like
this where we absolutely don't need it to achieve the desired behavior
within the experiment.

I agree very strongly on this, and this is the right way to view this.
While we all are confident that the 'np' tag will be a wild success,
there is the case this is not true, and we need to not upset current
working behavior.

Tim

(probably chair'ing a little here)

On Wed, Jul 17, 2019 at 2:27 AM Scott Kitterman <[email-masked]>
wrote:

> I think we agree on the goal, the difference is only about implementation
> details and impact on non-particpants in the experiment.
> >
> Keep in mind that senders do send from what we call non-existent domains
> for reasons that seem good and sufficient to them.  Let's take that as a
> fact, whether it makes sense to us or not.
>
> When a DMARC compliant receiver receives mail from a subdomain of that
> organization domain, the policy to apply is none.
>
> If our experiment has 'np' fall back to 'sp', then the non-particpant gets
> the same result.  An experiment participating receiver would use 'sp'
> directly (none) for an existing sub-domain and also use 'sp' (none - 'np'
> fallback) for a non-existing sub-domain.
>
> If our experiment has 'np' fall back to 'p', then the non-particpant gets
> a different result.  An experiment participating receiver would use 'sp'
> directly (none) for an existing sub-domain and also use 'p' (reject - 'p'
> fallback) for a non-existing sub-domain.
>
> Keep in mind, this isn't just about receiver processing.  The policy
> applied is also in the aggregate reports.
>
> I think changing existing defined behavior for non-participants in an
> experiment is not appropriate.  It's even more unacceptable in a case like
> this where we absolutely don't need it to achieve the desired behavior
> within the experiment.
>
> Scott K
>

---

From: "Chudow, Eric B CIV NSA DSAW (USA)" <[email-masked]>
Date: Wed, 17 Jul 2019 14:01:01 +0000

Scott, good point about the interoperability issue for the ‘np’ tag.  I hadn’t really thought about that.  Since what we do here for PSD DMARC will hopefully be included in regular DMARC for the future as well, I agree that it makes that we should not have the default behavior be different than current implementations, so we should keep your original intent to have ‘np’ default to ‘sp’ first if ‘np’ is absent.  

From a purist perspective, I agree with Ian that non-existent sub-domains are really the responsibility of that domain and so that domain’s policy should apply by default. But the interoperability issue is more important.  Even without having ‘p’ as the default, it’s easy for a domain to achieve this by adding the ‘np’ tag explicitly. 

For the current wording, I think the “if not” is unclear in the “If absent, the policy specified by the "sp" (if present) and then the "p" tag, if not, MUST be applied for non-existent subdomains.”  Does the “if not” mean if the sp tag is not present?  If so, then I think it should be in parentheses to match the “(if present)” and probably could be a little clearer by saying “(if the “sp” tag is not present)”.

Thanks,
-Eric
_________________________
Eric Chudow
DoD Cybersecurity Mitigations

_______________________________________________________
From: Tim Wicinski <[email-masked]> 
Sent: Wednesday, July 17, 2019 8:29 AM
To: Scott Kitterman <[email-masked]>
Cc: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Thanks for the update Scott, and your wording on the 'np' tag in the Appendix works.

I agree very strongly on this, and this is the right way to view this.  While we all are confident that the 'np' tag will be a wild success, 
there is the case this is not true, and we need to not upset current working behavior. 

Tim

On Wed, Jul 17, 2019 at 2:27 AM Scott Kitterman <mailto:[email-masked]> wrote:

On July 17, 2019 5:54:41 AM UTC, Seth Blank <mailto:[email-masked]> wrote:
>On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <mailto:[email-masked]>
>wrote:
>

p=reject, sp=none

Scott K

mailto:[email-masked]

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 17 Jul 2019 13:14:54 -0700

> Updated rfcdiff attached.  The only change other than typos is to add

Having reviewed the thread and the diff insofar as it pertains to the "np"
tag, I'm in favor of the "np defaults to sp" approach.

Generally, I think that the proposed text works, but have two concerns:

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
:-)

Secondly, I think that we need to update the "p" and "sp" descriptions in
both 7489 sections 6.3 & 11.4:

   - p --> 'Policy applies to the domain queried and to subdomains, unless
   subdomain policy is explicitly described using the "sp" tag.' change to
   'Policy applies to the domain queried and to subdomains, unless subdomain
   policy is explicitly described using the "sp" or "np" tags.'
   - sp --> 'Requested Mail Receiver policy for all subdomains
   (plain-text; OPTIONAL).  Indicates the policy to be enacted by the Receiver
   at the request of the Domain Owner.  It applies only to subdomains of the
   domain queried and not to the domain itself.' change to 'Requested Mail
   Receiver policy for all subdomains (plain-text; OPTIONAL).  Indicates the
   policy to be enacted by the Receiver at the request of the Domain Owner.
   It applies only to subdomains of the domain queried if they exist or if
   there is not an "np" tag published. "sp" does not apply to the domain
   itself."

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2019 17:40:20 -0400

In article <CABuGu1rSyifv0B9RtD3_R2ex-sh+nVrh4Q3H=kU=[email-masked]> you write:
>think that is an accurate portrayal. ...

I think what it means is that if there's a DMARC record on a
subdomain, it won't see any np= in the org domain or the PSD.  I agree
the wording could be better.  I also don't understand what possible
meaning an np= on a subdomain record would have.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 17 Jul 2019 14:55:12 -0700

> meaning an np= on a subdomain record would have.

np on a subdomain doesn't make any sense; np on an org domain would. I
think that just omitting the "and PSDs" would solve my concern unless the
use case of concern has to do with PSD subdomains that are still in the
public space. It's a question of distinguishing between LPD (longest public
domain) and PSDs in general.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 23:45:08 +0000

On your first point, I'll go double check.  I copied that text from the 'sp' definition.  I'm not sure why 'np' would be different.

On the second, I'm slightly reluctant to present redefine existing terms in an experimental document, but it is clearer and more explicit the way you suggest.  I'm curious what others think?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 17 Jul 2019 22:34:43 -0400

> >publish an np record on a non-existent Org domain or any subdomain

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 18 Jul 2019 08:42:36 -0700

> can have DMARC records, so I think the description is correct, but

Most MTAs will also follow CNAMEs. Should they be included (along with
other things like DNAME records) within the scope of existence? I'm a
little concerned that we are making a special definition of "non-existence"
which differs from the standard DNS concepts of NODATA and NXDOMAIN without
having a correspondingly special name.

> in non-org subdomains of PSDs don't get discovered.

I was considering the case of a domain such as
subX.sub1.org.pub2.pub1.example:
* subX (and sub1) domains would only have direct lookup DMARC records
applied if they exist and would fall back to org
* org would be direct unless it doesn't have a record in which case if fall
back to LPD (pub2's record)
* pub2, pub1, and example would only have direct lookups since they are
already above the PSL line <-- this is where my concern with the "and PSDs"
phrase resides

I'm not sure how well this maps to what we describe. I'm also concerned
that a wildcard null MX record at the org level would end up having all
subdomains "exist", but the policy that should be applied would be the more
restrictive "np" policy, not the (possibly) more permissive "sp" policy.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Jul 2019 01:41:28 -0400

On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote:
> > > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" <[email-masked]>
> > > 
> > > wrote:

OK.  I wish you'd jumped in earlier when we were discussing that exact topic.

https://mailarchive.ietf.org/arch/msg/dmarc/44sVJzvPkXkdT7Np-0ANr9Wm2Zc

If we want to take another run at this and put it in more standard DNS 
terminology, then maybe:

... a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, 
and MX records.

I think that cures John's concern with my last proposal and addresses yours as 
well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are 
correctly followed).

> already above the PSL line <-- this is where my concern with the "and PSDs"

It's possible that could happen, but it's not the most general case.  There 
are probably a nearly infinite variety of ways this could work or not work, I 
don't think we have to describe them all.

> restrictive "np" policy, not the (possibly) more permissive "sp" policy.

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.

Scott K

---

From: Ian Levy <[email-masked]>
Date: Fri, 19 Jul 2019 07:29:03 +0000

> 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 .gov.uk. 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.

Ta.

I.

-----Original Message-----
From: dmarc <[email-masked]> On Behalf Of Scott Kitterman
Sent: 19 July 2019 06:41
To: [email-masked]
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) 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.
> >
> > 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.
>
> which differs from the standard DNS concepts of NODATA and NXDOMAIN 
> without having a correspondingly special name.

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdmarc%2F44sVJzvPkXkdT7Np-0ANr9Wm2Zc&amp;data=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cfd04a584f3394adcaeba08d70c0bdebd%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991117441523973&amp;sdata=UZok5iWF4kKutpE%2F6%2FN43CwLPAgtGPbaRaLGh4Ge%2Bz0%3D&amp;reserved=0

If we want to take another run at this and put it in more standard DNS terminology, then maybe:

.... a domain for which there is an NXDOMAIN or NODATA response for A, AAAA, and MX records.

I think that cures John's concern with my last proposal and addresses yours as well (the response to a CNAME/DNAME is not NODATA/NXDOMAIN, so they are correctly followed).

> > 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')
> * org would be direct unless it doesn't have a record in which case if 
> fall back to LPD (pub2's record)
> * pub2, pub1, and example would only have direct lookups since they 
> are already above the PSL line <-- this is where my concern with the "and PSDs"
> phrase resides

It's possible that could happen, but it's not the most general case.  There are probably a nearly infinite variety of ways this could work or not work, I don't think we have to describe them all.

> I'm not sure how well this maps to what we describe. I'm also 
> concerned that a wildcard null MX record at the org level would end up 
> having all subdomains "exist", but the policy that should be applied 
> would be the more restrictive "np" policy, not the (possibly) more permissive "sp" policy.

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.

Scott K

_______________________________________________
dmarc mailing list
[email-masked]
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%7Cfd04a584f3394adcaeba08d70c0bdebd%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991117441523973&amp;sdata=zTGFs%2BLFVOPFLr%2Bx5w5%2BIbcSm9CQvCWPkAe77o7jaOc%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-masked]. All material is UK Crown Copyright ©

---

From: Dotzero <[email-masked]>
Date: Fri, 19 Jul 2019 08:04:20 -0400

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=
[email-masked]> wrote:

> > 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.
> 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 .gov.uk. 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 dmarc.org 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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 19 Jul 2019 08:30:01 -0700

On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman <[email-masked]>
wrote:

> .... a domain for which there is an NXDOMAIN or NODATA response for A,
> AAAA,
> and MX records.
>

Yes - I think that will fix my concerns (and John's too).

> > I'm also concerned
> know a

Perhaps a reminder in the text related to "np" that wildcards may cause
undesired results and leave it as an exercise for the implementor to learn
from that warning.

--Kurt

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 19 Jul 2019 08:33:38 -0700

> Yes - I think that will fix my concerns (and John's too).

Thinking about this from a reporting POV, where would a receiver categorize
messages which ended up with SERVFAIL during the process of DMARC (regular
or PSD)? Would "sp" handling or "np" handling be invoked for SERVFAIL (such
as a broken DNSSEC implementation)?

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Jul 2019 23:13:25 -0400

On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote:
...
> > > subdomains "exist", but the policy that should be applied would be the
> > 
> > more
> > 

It seems like either too much or not enough.  This at least slightly concerns 
me because I don't want to warn about the implication of one DNS feature 
without being comprehensive.  DMARC deployment in any non-trivial organization 
is an inter-disciplinary task, even more so PSD DMARC.  I don't think we want 
to take on being a deployment guide, so I'd leave it out.

Let's see what others think.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Jul 2019 23:15:04 -0400

> experiences of early adopters.

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

Scott K

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 19 Jul 2019 23:16:26 -0400

An experimental draft isn't the best place for a deployment guide.

an operational document that discusses deployment among other things is a
different story

On Fri, Jul 19, 2019 at 11:13 PM Scott Kitterman <[email-masked]>
wrote:

> ....

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Jul 2019 23:22:32 -0400

On Wednesday, July 17, 2019 10:01:01 AM EDT Chudow, Eric B CIV NSA DSAW (USA) 
wrote:
...
> For the current wording, I think the “if not” is unclear in the “If absent,
> the policy specified by the "sp" (if present) and then the "p" tag, if not,
> MUST be applied for non-existent subdomains.”  Does the “if not” mean if
> the sp tag is not present?  If so, then I think it should be in parentheses
> to match the “(if present)” and probably could be a little clearer by
> saying “(if the “sp” tag is not present)”.
...
Thanks,

I'm going to post an update shortly to the proposed 'np' section that 
(hopefully) addresses this concern.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Jul 2019 23:32:00 -0400

RFC 7489 says:

>    Handling of DNS errors when querying for the DMARC policy record is
>    left to the discretion of the Mail Receiver.

In every case where it discusses DNS errors, it leaves it to the receiver to 
decide.  I think it's out of scope for us to do differently.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 19 Jul 2019 23:47:08 -0400

On Wednesday, July 17, 2019 1:07:05 AM EDT Scott Kitterman wrote:
> Updated rfcdiff attached.  The only change other than typos is to add
> mention of 'np' to Appendix A.

Updated again.  I believe this addresses all the 'np' related last call 
discussion.  Shortly I'll move on to what I think the group wanted on the 
other topics.

Scott K

Note:  I'm not planning on publishing diffs on every topic.  I only did it for 
'np' because it required me to write more new text that no one else had 
reviewed.

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2019 01:08:52 -0400

>having a correspondingly special name.

Good catch, you have to chase CNAME and DNAME before deciding whether you've found
A/AAAA/MX.

>restrictive "np" policy, not the (possibly) more permissive "sp" policy.

That sounds fairly deep into "don't do that" territory.  If you are
clever enough to publish a wild card MX, you should be clever enough
to publish an appropriate DMARC record.  Keep in mind that wildcards
don't work the way many people think they do, so if you have *.foo.com
along with a.foo.com, then the wildcard will match b.foo.com, but not
b.a.foo.com.

R's,
John

---

From: Ian Levy <[email-masked]>
Date: Sat, 20 Jul 2019 09:04:57 +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.

+1.

Ta.

I.

-----Original Message-----
From: dmarc <[email-masked]> On Behalf Of Scott Kitterman
Sent: 20 July 2019 04:15
To: [email-masked]
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.
>
> > 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.
> > 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 .gov.uk. 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.
> >
> > 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.
>
> 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 
> dmarc.org 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.
>

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

Scott K

_______________________________________________
dmarc mailing list
[email-masked]
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%7C7c7b41070b5a449edbc008d70cc0908f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636991893511878654&amp;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 [email-masked]. All material is UK Crown Copyright ©

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 21 Jul 2019 18:40:49 +0200

On Wed 17/Jul/2019 08:26:25 +0200 Scott Kitterman wrote:

> Keep in mind that senders do send from what we call non-existent domains for
> reasons that seem good and sufficient to them.  Let's take that as a fact,
> whether it makes sense to us or not.

Fair enough.  Let me quote the current spec:

A.4.  Domain Existence Test

   A common practice among MTA operators, and indeed one documented in
   [ADSP], is a test to determine domain existence prior to any more
   expensive processing.  This is typically done by querying the DNS for
   MX, A, or AAAA resource records for the name being evaluated and
   assuming that the domain is nonexistent if it could be determined
   that no such records were published for that domain name.

   The original pre-standardization version of this protocol included a
   mandatory check of this nature.  It was ultimately removed, as the
   method's error rate was too high without substantial manual tuning
   and heuristic work.  There are indeed use cases this work needs to
   address where such a method would return a negative result about a
   domain for which reporting is desired, such as a registered domain
   name that never sends legitimate mail and thus has none of these
   records present in the DNS.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 21 Jul 2019 16:53:35 +0000

>   records present in the DNS.

Yes, but that was for a different use case.  It was , AIUI, considered that reporting could be skipped on such 'non-existant' domains, but that proved problematic since such domains as these are used in mail.

'np' doesn't have the same issue.  It uses non-existence in a positive (do some processing) not a negative sense (reporting can be skipped for these), so the problems described in that paragraph are not only not relevant, the paragraph supports the case for 'np'.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 21 Jul 2019 20:01:05 +0200

On Sun 21/Jul/2019 18:53:35 +0200 Scott Kitterman wrote:
> Yes, but that was for a different use case.  It was , AIUI, considered that
> reporting could be skipped on such 'non-existant' domains, but that proved
> problematic since such domains as these are used in mail.

Wasn't it for rejecting non-existent domains?  That is, IIRC, <sciencefiction>
as if there were a root DMARC record (_dmarc.) with np=reject.</sciencefiction>

> 'np' doesn't have the same issue.  It uses non-existence in a positive (do
> some processing) not a negative sense (reporting can be skipped for these),
> so the problems described in that paragraph are not only not relevant, the
> paragraph supports the case for 'np'.

Uh?  (I don't understand your parenthesized phrase...)

At any rate, the first paragraph gives a definition of non-existence equal to
the one we've been discussing these days, doesn't it?

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 21 Jul 2019 19:41:59 +0000

>np=reject.</sciencefiction>

I think no.  I think it was about skipping reporting on 'non-existant' domains.  Perhaps someone who was more involved at that point can clarify.

>the one we've been discussing these days, doesn't it?

Yes, but since we're using it for a different, opt-in, purpose, the caution doesn't apply.

Scott K

---

From: "Douglas E. Foster" <[email-masked]>
Date: Mon, 22 Jul 2019 00:31:40 -0400

>> records present in the DNS.
  
  This section seems to give a free pass to senders who use non-existent 
domains, as if such behavior had no impact on the risk posture of the 
recipient. 
 It seems to say, "You can keep doing this, because so is everyone else."
  
 I would think better language would be along the following lines:

 "Senders SHOULD register all domains in DNS, as MTA operators MAY block 
messages that appear to come from non-existent domains.
 Developers of MTA filtering software SHOULD provide MTA operators with the 
ability to block non-existent domains.
 If such ability is provided, the MTA filtering system MUST provide a 
mechanism for overriding the filter rule for messages that are acceptable 
to the recipient organization."
  
 In short, the evaluation of whether manual tuning is worthwhile should be 
left to the discretion of the MTA operator, based on his organization's 
risk tolerance and message characteristics.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Jul 2019 10:43:47 +0000

>risk tolerance and message characteristics.

I think that it is well outside the scope of this document to impose such a requirement.

Scott K

---

From: Dotzero <[email-masked]>
Date: Mon, 22 Jul 2019 07:45:31 -0400

+1 on Scott's comment.

Michael Hammer

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 22 Jul 2019 08:35:15 -0600

On Mon, Jul 22, 2019, 04:44 Scott Kitterman <[email-masked]> wrote:

> >"Senders SHOULD register all domains in DNS, as MTA operators MAY block...
>

Agreed

--Kurt