Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On July 21, 2019 6:01:05 PM UTC, Alessandro Vesely wrote: >On Sun 21/Jul/2019 18:53:35 +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 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. >> >> 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, > >as if there were a root DMARC record (_dmarc.) with >np=reject. 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. >> '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? > Yes, but since we're using it for a different, opt-in, purpose, the caution doesn't apply. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Sun 21/Jul/2019 18:53:35 +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 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. > > 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, as if there were a root DMARC record (_dmarc.) with np=reject. > '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 -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On July 21, 2019 4:40:49 PM UTC, Alessandro Vesely wrote: >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 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 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 -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
>> 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. -- Dr Ian Levy Technical Director National Cyber Security Centre i...@ncsc.gov.uk Staff Officer : Kate Atkins, kat...@ncsc.gov.uk (I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!) -Original Message- From: dmarc On Behalf Of Scott Kitterman Sent: 20 July 2019 04:15 To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote: > I've been following the discussion but haven't contributed anything > until this point. Comment below. > > On Fri, Jul 19, 2019 at 3:29 AM Ian Levy > 40ncsc.gov...@dmarc.ietf.org> wrote: > > > I think this is one of those "you must be this tall to ride on > > > this ride" > > > situations. DNS comes equipped with multiple footguns and you > > > have to > > > > know a bit about what you're doing to make sure you get the effects > > you're after. > > > > This. DMARC today allows people to disconnect their outgoing mail > > from the rest of the world. Admittedly, the PSD-level policies would > > have a much greater effect, but your PSD/TLD operator can already > > bork you if they're not competent. > > There are two different buckets of risk in my view, though : > > 1) New TLDs are effectively greenfield sites and can enforce > > appropriate requirements on their customers from the start to > > minimize the chance of unintended consequences (for example, by requiring > > domain DMARC labels). > > 2) Existing TLDs, where there are many subdomains with wildly > > variable implementations, policies and use and here we are going to > > have to be really careful. Careful and methodical testing will be > > necessary to make sure that introduction of the PSD-level policies > > doesn't break anything important. It took us 6 months to get to > > synthesizing p=reject for non-existent subdomains of .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 provid
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article you write: >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. Good catch, you have to chase CNAME and DNAME before deciding whether you've found A//MX. >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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Wednesday, July 17, 2019 1:07:05 AM EDT Scott Kitterman wrote: > On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote: > > 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 > > > > > > > > > > > > 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 > > 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. draft-ietf-dmarc-psd-05-from-4.diff.html Description: application/xhtml ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Friday, July 19, 2019 11:33:38 AM EDT Kurt Andersen (b) wrote: > On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote: > > On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman > > > > wrote: > >> 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, > >> , > >> 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). > > > > 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)? 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 wrote: > On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote: > > > > > 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. > > > > 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. > > 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 > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote: > I've been following the discussion but haven't contributed anything until > this point. Comment below. > > On Fri, Jul 19, 2019 at 3:29 AM Ian Levy > 40ncsc.gov...@dmarc.ietf.org> wrote: > > > I think this is one of those "you must be this tall to ride on this > > > ride" > > > situations. DNS comes equipped with multiple footguns and you have to > > > > know a bit about what you're doing to make sure you get the effects you're > > after. > > > > This. DMARC today allows people to disconnect their outgoing mail from the > > rest of the world. Admittedly, the PSD-level policies would have a much > > greater effect, but your PSD/TLD operator can already bork you if they're > > not competent. > > There are two different buckets of risk in my view, though : > > 1) New TLDs are effectively greenfield sites and can enforce appropriate > > requirements on their customers from the start to minimize the chance of > > unintended consequences (for example, by requiring domain DMARC labels). > > 2) Existing TLDs, where there are many subdomains with wildly variable > > implementations, policies and use and here we are going to have to be > > really careful. Careful and methodical testing will be necessary to make > > sure that introduction of the PSD-level policies doesn't break anything > > important. It took us 6 months to get to synthesizing p=reject for > > non-existent subdomains of .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. I agree, but I think solving that is outside the scope of the current document. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote: > > > 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. > > 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote: > On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman > wrote: > >> >> 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, >> , >> 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). >> > > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman wrote: > On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote: > > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman > > > > 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. > > 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, > , > 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). > Yes - I think that will fix my concerns (and John's too). > > 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. > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 wrote: > > I think this is one of those "you must be this tall to ride on this ride" > > situations. DNS comes equipped with multiple footguns and you have to > know a bit about what you're doing to make sure you get the effects you're > after. > > This. DMARC today allows people to disconnect their outgoing mail from the > rest of the world. Admittedly, the PSD-level policies would have a much > greater effect, but your PSD/TLD operator can already bork you if they're > not competent. > There are two different buckets of risk in my view, though : > 1) New TLDs are effectively greenfield sites and can enforce appropriate > requirements on their customers from the start to minimize the chance of > unintended consequences (for example, by requiring domain DMARC labels). > 2) Existing TLDs, where there are many subdomains with wildly variable > implementations, policies and use and here we are going to have to be > really careful. Careful and methodical testing will be necessary to make > sure that introduction of the PSD-level policies doesn't break anything > important. It took us 6 months to get to synthesizing p=reject for > non-existent subdomains of .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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
> I think this is one of those "you must be this tall to ride on this ride" > situations. DNS comes equipped with multiple footguns and you have to know a > bit about what you're doing to make sure you get the effects you're after. This. DMARC today allows people to disconnect their outgoing mail from the rest of the world. Admittedly, the PSD-level policies would have a much greater effect, but your PSD/TLD operator can already bork you if they're not competent. There are two different buckets of risk in my view, though : 1) New TLDs are effectively greenfield sites and can enforce appropriate requirements on their customers from the start to minimize the chance of unintended consequences (for example, by requiring domain DMARC labels). 2) Existing TLDs, where there are many subdomains with wildly variable implementations, policies and use and here we are going to have to be really careful. Careful and methodical testing will be necessary to make sure that introduction of the PSD-level policies doesn't break anything important. It took us 6 months to get to synthesizing p=reject for non-existent subdomains of .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. -- Dr Ian Levy Technical Director National Cyber Security Centre i...@ncsc.gov.uk Staff Officer : Kate Atkins, kat...@ncsc.gov.uk (I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!) -Original Message- From: dmarc On Behalf Of Scott Kitterman Sent: 19 July 2019 06:41 To: dmarc@ietf.org 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: > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman > > wrote: > > > On July 17, 2019 8:14:54 PM UTC, "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. > > > > 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, , or MX. It could have other types. It could > > also have subdomains called "_dmarc" that have TXT records. > >
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: > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman > > wrote: > > > On July 17, 2019 8:14:54 PM UTC, "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. > > > > 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, , 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. > > 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. 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, , 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). > > 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. > > 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 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman wrote: > > On July 17, 2019 8:14:54 PM UTC, "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. > > 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, , 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. > 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. > 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. > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
> On July 17, 2019 8:14:54 PM UTC, "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. 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, , 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" wrote: >On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman >wrote: > >> >> Updated rfcdiff attached. The only change other than typos is to add >> mention >> of 'np' to Appendix A. >> > >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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Wed, Jul 17, 2019 at 2:40 PM John Levine wrote: > In article zsdwzvr...@mail.gmail.com> you write: > >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. ... > > 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article you write: >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. ... 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman wrote: > > Updated rfcdiff attached. The only change other than typos is to add > mention > of 'np' to Appendix A. > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 Sent: Wednesday, July 17, 2019 8:29 AM To: Scott Kitterman Cc: IETF DMARC WG 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 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 <mailto:skl...@kitterman.com> wrote: On July 17, 2019 5:54:41 AM UTC, Seth Blank <mailto:s...@sethblank.com> wrote: >On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <mailto:skl...@kitterman.com> >wrote: > >> 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. >> > >I absolutely agree with this. > > >> 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 >> > >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. See if you still feel that way after considering backward compatibility ... >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...). > > >> Having 'np' fall back to 'p' doesn't actually solve the problem you >claim >> to >> 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 we agree on the goal, the difference is only about implementation details and impact on non-particpants in the experiment. > >> 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). >> > >I don't think I properly understand what you're saying. Can you clarify >this point? 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
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 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 wrote: > > > On July 17, 2019 5:54:41 AM UTC, Seth Blank wrote: > >On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman > >wrote: > > > >> 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. > >> > > > >I absolutely agree with this. > > > > > >> 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 > >> > > > >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. > > See if you still feel that way after considering backward compatibility ... > > >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...). > > > > > >> Having 'np' fall back to 'p' doesn't actually solve the problem you > >claim > >> to > >> 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 we agree on the goal, the difference is only about implementation > details and impact on non-particpants in the experiment. > > > >> 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). > >> > > > >I don't think I properly understand what you're saying. Can you clarify > >this point? > > 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 > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On July 17, 2019 5:54:41 AM UTC, Seth Blank wrote: >On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman >wrote: > >> 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. >> > >I absolutely agree with this. > > >> 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 >> > >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. See if you still feel that way after considering backward compatibility ... >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...). > > >> Having 'np' fall back to 'p' doesn't actually solve the problem you >claim >> to >> 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 we agree on the goal, the difference is only about implementation details and impact on non-particpants in the experiment. > >> 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). >> > >I don't think I properly understand what you're saying. Can you clarify >this point? 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman wrote: > 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. > I absolutely agree with this. > 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 > 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...). > Having 'np' fall back to 'p' doesn't actually solve the problem you claim > to > 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 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). > I don't think I properly understand what you're saying. Can you clarify this point? Thanks! S ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Wednesday, July 17, 2019 1:18:50 AM EDT Seth Blank wrote: > As an individual- > > On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman > > wrote: > > Although a few people have suggested this, I think it would be a mistake > > because it would cause a gratuitous incompatibility with RFC 7468. > > The people suggesting this are the people asking for np= in the first place. > > 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. > > 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
As an individual- On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman wrote: > Although a few people have suggested this, I think it would be a mistake > because it would cause a gratuitous incompatibility with RFC 7468. > The people suggesting this are the people asking for np= in the first place. > 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. > 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. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote: > 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 > > > > > > 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 Updated rfcdiff attached. The only change other than typos is to add mention of 'np' to Appendix A. Scott K draft-ietf-dmarc-psd-05-from-4.diff.html Description: application/xhtml ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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. > > A few minor suggestions: > > > > In section 4, "requiremetns" should be "requirements". 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 > > | -Original Message- > | From: dmarc On Behalf Of Scott Kitterman > | Sent: 13 July 2019 20:35 > | To: dmarc@ietf.org > | 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 > | > > > | > > > | > > 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 ncscinfo...@ncsc.gov.uk > > 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 ncscinfo...@ncsc.gov.uk > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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: > 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 > > 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 > > > > > > 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. > > > > Scott K > > > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
> 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. -- Dr Ian Levy Technical Director National Cyber Security Centre i...@ncsc.gov.uk Staff Officer : Kate Atkins, kat...@ncsc.gov.uk (I work stupid hours and weird times – that doesn’t mean you have to. If this arrives outside your normal working hours, don’t feel compelled to respond immediately!) -Original Message- From: dmarc On Behalf Of Alessandro Vesely Sent: 16 July 2019 15:53 To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd On Mon 15/Jul/2019 09:08:04 +0200 Ian Levy wrote: > 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. 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.) > [...] > 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.com61,363,605 > Yahoo! Inc. 18,876,201 > Mail.Ru 699,554 > sercoglobal.com 227,587 > AMAZON-SES178,262 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdmarc.org%2Fstats%2Fdmarc-reporting%2Fdata=02%7C01%7Cian.levy%40ncsc.gov.uk%7Cb422dd587d5543c6142908d709fd6300%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C636988856820114383sdata=8ikFqwHQDkEaOQVJslti2vYNp8jYWU4C7omM7SJAAuY%3Dreserved=0 (That used to be on dmarcian, but couldn't find it any more) > And here's the volume for the same month for the synthetic DMARC reports : > Reporter Total Reports > google.com23,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. 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
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 Sent: Tue, 16 July 2019 14:53 UTC To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd > 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. 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.) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Mon 15/Jul/2019 09:08:04 +0200 Ian Levy wrote: > 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. 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.) > [...] > 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.com61,363,605 > Yahoo! Inc. 18,876,201 > Mail.Ru 699,554 > sercoglobal.com 227,587 > AMAZON-SES178,262 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) > And here's the volume for the same month for the synthetic DMARC reports : > Reporter Total Reports > google.com23,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. 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 -- --- Begin Message --- Title: Feedback from Mail.Ru Feedback from Mail.RuId: 68064799912189070641563148800; begin: 2019-07-15T00:00:00Z; end: 2019-07-16T00:00:00ZDomain: 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.661nonext.tana.itme 5.170.8.661nonext.tana.ittana.it 82.195.75.1007tana.itlists.debian.org tana.it 62.94.243.2261tana.ittana.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. mail.ru!tana.it!1563148800!1563235200.xml.gz Description: application/gzip --- End Message --- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 On Behalf Of Scott Kitterman | Sent: 13 July 2019 20:35 | To: dmarc@ietf.org | 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 | > > | > > | > > 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 ncscinfo...@ncsc.gov.uk 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 ncscinfo...@ncsc.gov.uk ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 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 > > > > 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. > > Scott K > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 July5,764 August 274,532 September 127,901 October 17,553 November17,191 December105,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): ReporterTotal 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 : ReporterTotal 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 i...@ncsc.gov.uk Staff Officer : Kate Atkins, kat...@ncsc.gov.uk (I work stupid hours and weird times - that doesn't mean you have to. If this arrives outside your normal working hours, don't feel compelled to respond immediately!) -Original Message- From: dmarc On Behalf Of Scott Kitterman Sent: 13 July 2019 07:04 To: dmarc@ietf.org 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, , 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, , 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 dmarc@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarcdata=02%7C01%7Cian.levy%40ncsc.gov.uk%7C34d406d8456ee39d08d70758084b%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6
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 > > > > 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 draft-ietf-dmarc-psd-05-from-4.diff.html Description: application/xhtml ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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, , 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, , 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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, , 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, , 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Friday, July 12, 2019 3:13:48 PM EDT John Levine wrote: > In article you write: > >-=-=-=-=-=- > > > >On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) 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 > >> record, than to make this a special case for PSD-DMARC records. > > > >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. > > 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, , 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, , 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Fri, Jul 12, 2019 at 2:16 PM Seth Blank wrote: > On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) > 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 >> record, than to make this a special case for PSD-DMARC records. >> > > 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 > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
In article you write: >-=-=-=-=-=- > >On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) 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 >> record, than to make this a special case for PSD-DMARC records. >> > >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. How do they feel about NODATA, which is not the same as NXDOMAIN? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
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 > > 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. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) 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 > record, than to make this a special case for PSD-DMARC records. > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman 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. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote: > As Secretary, there are three items that have not yet reached consensus > that must be resolved during WGLC: > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
