Re: [dmarc-ietf] Tree walk is screwed up
On Wed, 26 Jan 2022, Murray S. Kucherawy wrote: On Wed, Jan 26, 2022 at 9:56 AM John Levine wrote: More saliently, we had an entire working group called DBOUND that tried and failed to come up with a way to publish boundary info about the DNS: https://datatracker.ietf.org/wg/dbound/about/ DBOUND came up with two ways to deal with this, but no clear winner emerged in terms of development of consensus. It doesn't necessarily mean those proposals weren't valid. All three of the proposals would have worked technically, but we never got consensus to move any of them forward. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On Wed, Jan 26, 2022 at 9:56 AM John Levine wrote: > More saliently, we had an entire working group called DBOUND that tried > and failed > to come up with a way to publish boundary info about the DNS: > > https://datatracker.ietf.org/wg/dbound/about/ > DBOUND came up with two ways to deal with this, but no clear winner emerged in terms of development of consensus. It doesn't necessarily mean those proposals weren't valid. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 11:11 AM, John R Levine wrote: Hm, we're addressing the same problem that DBOND did, but it's not DBOUND. Well, OK. You seem to be, but I'm not. I'm addressing a documentation issue. I'm sorry you are having so much trouble understanding that. I've no idea how you came up with a larger and more abstract scope. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
2. But since you are asking, I think it is pretty easy to specify the details of the mechanism in a way that does not require DMARC specific text. Not because it is will or might have more general use -- that that's often a collateral benefit -- but because specs should not overspecify detail they don't need to. Hm, we're addressing the same problem that DBOND did, but it's not DBOUND. Well, OK. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:49 AM, Scott Kitterman wrote: Or, not to put too fine a point on it, if you two want to discuss DBOUND, I thinkdbo...@ietf.org is still active. there's nothing in what I posted that has anything to do with dbound or possible derivatives. The introduction of the reference came from a creative misreading of my posting. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:54 AM, John R Levine wrote: Ahh, You are claiming I said something about a 'general method'. I didn't. Since you think otherwise, could you explain in simple language that even I could understand how you reached that interpretation of my note? Now we're both confused. When you said "The method of finding the organizational domain should be specified outside of the base DMARC specification" did that mean it's still unique to DMARC, but we put it in a different document? 1. I said it should be specified outside of the base DMARC document. That's different from saying what the internals of the separate document should contain. I didn't comment on that. 2. But since you are asking, I think it is pretty easy to specify the details of the mechanism in a way that does not require DMARC specific text. Not because it is will or might have more general use -- that that's often a collateral benefit -- but because specs should not overspecify detail they don't need to. If so, what's the point of making it separate? If not, what am I missing? It removes fate-sharing of the core mechanism from the messier component mechanism that will have (at least) two very different operational designs with the new one being... new and lacking solid field experience that gives assurance for uptake. (Thought I said all that in the original note. Should I have used caps?) d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
Ahh, You are claiming I said something about a 'general method'. I didn't. Since you think otherwise, could you explain in simple language that even I could understand how you reached that interpretation of my note? Now we're both confused. When you said "The method of finding the organizational domain should be specified outside of the base DMARC specification" did that mean it's still unique to DMARC, but we put it in a different document? If so, what's the point of making it separate? If not, what am I missing? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On Wednesday, January 26, 2022 1:47:37 PM EST Dave Crocker wrote: > On 1/26/2022 10:38 AM, John R Levine wrote: > >>> It appears that Dave Crocker said: > The method of finding the organizational domain should be specified > outside of the base DMARC specification. I suggested this back during > the PSD discussion. > >>> > >>> That assumes that the org domain is useful on its own, rather than > >>> just as a tool to help find policy records or to check for relaxed > >>> alignment. > >> > >> It does? I don't understand how it assumes that. > > > > If the org domain isn't useful, why would we care how it's defined? > > Well, now you've completely lost me. I have no idea what you are > talking about, nevermind how it it supposed to relate to the rather > simple point of distinction I suggested, separating what from how. > > >>> We tried and failed to find a general method to find an > >>> organizaional domain in DBOUND, and I don't think we want to go > >>> there again. > >> > >> So it's a good thing I didn't suggest anything of the sort. > > > > Could you explain in simple language that even I could understand how > > a generic definition of a way to find an org domain is not what DBOUND > > tried to do? > > Ahh, You are claiming I said something about a 'general method'. I > didn't. > > Since you think otherwise, could you explain in simple language that > even I could understand how you reached that interpretation of my note? Or, not to put too fine a point on it, if you two want to discuss DBOUND, I think dbo...@ietf.org is still active. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:38 AM, John R Levine wrote: It appears that Dave Crocker said: The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. That assumes that the org domain is useful on its own, rather than just as a tool to help find policy records or to check for relaxed alignment. It does? I don't understand how it assumes that. If the org domain isn't useful, why would we care how it's defined? Well, now you've completely lost me. I have no idea what you are talking about, nevermind how it it supposed to relate to the rather simple point of distinction I suggested, separating what from how. We tried and failed to find a general method to find an organizaional domain in DBOUND, and I don't think we want to go there again. So it's a good thing I didn't suggest anything of the sort. Could you explain in simple language that even I could understand how a generic definition of a way to find an org domain is not what DBOUND tried to do? Ahh, You are claiming I said something about a 'general method'. I didn't. Since you think otherwise, could you explain in simple language that even I could understand how you reached that interpretation of my note? d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
It appears that Dave Crocker said: The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. That assumes that the org domain is useful on its own, rather than just as a tool to help find policy records or to check for relaxed alignment. It does? I don't understand how it assumes that. If the org domain isn't useful, why would we care how it's defined? We tried and failed to find a general method to find an organizaional domain in DBOUND, and I don't think we want to go there again. So it's a good thing I didn't suggest anything of the sort. Could you explain in simple language that even I could understand how a generic definition of a way to find an org domain is not what DBOUND tried to do? As I'm sure you remember, the late Gervase Markham proposed standardizing the PSL in DBOUND, and Casey Decchio and I had ways to put similar info in the DNS. In each case, the idea was that you gave it a domain, it gave you back the PSD above that domain. You know, like we do for org domains. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 10:04 AM, John Levine wrote: It appears that Dave Crocker said: The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. That assumes that the org domain is useful on its own, rather than just as a tool to help find policy records or to check for relaxed alignment. It does? I don't understand how it assumes that. We tried and failed to find a general method to find an organizaional domain in DBOUND, and I don't think we want to go there again. So it's a good thing I didn't suggest anything of the sort. This just leaves the question of why you are introducing it here? 1. There is already an installed base using the PSL. While I understand the desire to move away from it, the change might or might not happen and if it does, it will take a potentially long time. ... I think we have all agreed that whatever we come up with has to produce similar results to the current scheme. I say similar rather than identical, since the PSL is a moving target. My concern has nothing to do with equivalent semantics but rather is about the pragmatics of transition with parallel field operation, duration for gaining traction, and the risk of inadequate uptake. Sorry I wasn't adequately clear about that. 2. In spite of the current fashion that encourages use of tree walk, it does not have prior field experience and in fact runs contrary to long-standing, established practices. ... RFC 8659 suggests otherwise. Because, yeah, the mere fact that an RFC was issued 2 years ago completely reverses established concerns and practice of 35 years... And I'm sure there is plenty of data about operational uptake and comfort with the mechanism, though I didn't see it when searching for references to the RFC. Please provide a point to the field experience that cover the concern I raised. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue 25/Jan/2022 20:39:11 +0100 Murray S. Kucherawy wrote: On Tue, Jan 25, 2022 at 11:26 AM John R Levine wrote: On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: will get the same result. It also occurs to me that in the absence of a PSL-like thing, the idea of an organizational domain is no longer useful. Aren't we basically trying to identify the same thing, just in a different (and more robust) way? >> Yes, but that leads to the question of whether the org domain is useful on its own or it's just a way to figure out alignment. I think it's the latter, dunno what other people think. It's an interesting thought exercise at least. We should be sure to give a decent treatment to this in the "differences since RFC 7489" part of the document. The concept of Organizational Domain is a key concept, as it is easy to understand, based on intuitive set theory ideas. With respect to earlier SPF experience, which required tagging each and every domain name in an organization, it is an invaluable progress. Replacing it with a difficult graph-theoretical argument is going to make the notion of alignment much more difficult to explain. The mere fact that adding a DMARC record can change alignment properties turns such a simple operation into something that requires an extensive analysis before it can be carried out. If we drop Organizational Domain we're probably better off dropping alignment as well. We're worsening DMARC in that case. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On Wednesday, January 26, 2022 12:30:01 PM EST Seth Blank wrote: > Yes, this is a core ticket that needs to be addressed: > https://trac.ietf.org/trac/dmarc/ticket/46 > > I believe right now the group is just dialing in the definition/text, but > there has been broad agreement (I don't remember hearing any disagreement, > but I wouldn't go so far as to call it consensus yet) that everything > related to organizational domain discovery should be moved into a separate > document. In RFC 7489, the organizational domain does two things relative to policy: 1. It provides a top point for checking relaxed alignment. 2. If provides policy for cases where the From domain does not have a DMARC record. In recent discussions around organizational domain, we have mostly been discussing the first point, but if this is carved off into a separate draft, then the second point needs to go with it as they are intimately connected in RFC 7489. If the chairs want a separate document, I'd be glad to take a shot at drafting it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
It appears that Dave Crocker said: >-=-=-=-=-=- > >G'day. > >The method of finding the organizational domain should be specified >outside of the base DMARC specification. I suggested this back during >the PSD discussion. That assumes that the org domain is useful on its own, rather than just as a tool to help find policy records or to check for relaxed alignment. We tried and failed to find a general method to find an organizaional domain in DBOUND, and I don't think we want to go there again. >1. There is already an installed base using the PSL. While I understand >the desire to move away from it, the change might or might not happen >and if it does, it will take a potentially long time. ... I think we have all agreed that whatever we come up with has to produce similar results to the current scheme. I say similar rather than identical, since the PSL is a moving target. >2. In spite of the current fashion that encourages use of tree walk, it >does not have prior field experience and in fact runs contrary to >long-standing, established practices. ... RFC 8659 suggests otherwise. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
It appears that Steve Siirila said: >-=-=-=-=-=- > >After reading this thread, I couldn't help but wonder about how the >addition of a "PSD flag" specifically targeted to DMARC might be repurposed >for other non-DMARC applications since my understanding is that the PSL is >currently being used for other purposes as well. Just food for thought. Since the PSD flag only appears in records at _dmarc.whatever I doubt there will be many non-DMARC applications looking at them. More saliently, we had an entire working group called DBOUND that tried and failed to come up with a way to publish boundary info about the DNS: https://datatracker.ietf.org/wg/dbound/about/ I had what I thought was a dandy proposal, implemented here: https://github.com/jrlevine/bound R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
On 1/26/2022 9:30 AM, Seth Blank wrote: Yes, this is a core ticket that needs to be addressed: https://trac.ietf.org/trac/dmarc/ticket/46 21 months ago? as if I'd remember something from 21 minutes ago. sheesh. I believe right now the group is just dialing in the definition/text, but there has been broad agreement (I don't remember hearing any disagreement, but I wouldn't go so far as to call it consensus yet) that everything related to organizational domain discovery should be moved into a separate document. great. hadn't gotten that vibe from the list discussion but as long as the separation is an open point, that's fine. thanks! d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] tree walk is experimental
Yes, this is a core ticket that needs to be addressed: https://trac.ietf.org/trac/dmarc/ticket/46 I believe right now the group is just dialing in the definition/text, but there has been broad agreement (I don't remember hearing any disagreement, but I wouldn't go so far as to call it consensus yet) that everything related to organizational domain discovery should be moved into a separate document. Seth On Wed, Jan 26, 2022 at 9:23 AM Dave Crocker wrote: > G'day. > > The method of finding the organizational domain should be specified > outside of the base DMARC specification. I suggested this back during the > PSD discussion. > > There are a number of reasons: > > 1. There is already an installed base using the PSL. While I understand > the desire to move away from it, the change might or might not happen and > if it does, it will take a potentially long time. During all of that time, > field operations will be non-compliant with the DMARC specification. > > Note that success for tree walk requires a) receivers to attempt it, and > b) operational experience to be satisfying. Good ideas often turn out not > to succeed... Again, at the very least, it will take an unknown amount of > time for there to be enough uptake of this replacement mechanism. And the > incentives for that uptake are frankly not all that clear; do we have solid > documentation of widespread dissatisfaction with the use of PSL in DMARC? > (I'm not asking about the logic, but about the basis for claiming widesprea > market dissatisfaction.) > > 2. In spite of the current fashion that encourages use of tree walk, it > does not have prior field experience and in fact runs contrary to > long-standing, established practices. While it might prove good to do and > even better than PSL, it is, by its nature, an experimental mechanism. > Including it inside the base DMARC specification encourages treating that > base specification as an experiment. > > 3. The base DMARC specification needs to define the construct of an > organizational domain and it needs to specify how one is used in DMARC > operation. It does /not/ need to specify how to obtain one. Given that we > will have (at least) two different methods, it is cleaner and safer to > partition the 'how' out of the core, leaving only the 'what'. > > 4. To the extent that there is a view that having tree walk inside the > base spec somehow encourages or forces adoption, experience tends to show > that, instead, it makes the transition confusing. Also, see points 1 & 2, > above. > > > d/ > > -- > Dave crockerdcroc...@gmail.com > 408.329.0791 > > Volunteer, Silicon Valley Chapter > Information & Planning Coordinator > American Red crossdave.crock...@redcross.org > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank * | Chief Product Officer *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] tree walk is experimental
G'day. The method of finding the organizational domain should be specified outside of the base DMARC specification. I suggested this back during the PSD discussion. There are a number of reasons: 1. There is already an installed base using the PSL. While I understand the desire to move away from it, the change might or might not happen and if it does, it will take a potentially long time. During all of that time, field operations will be non-compliant with the DMARC specification. Note that success for tree walk requires a) receivers to attempt it, and b) operational experience to be satisfying. Good ideas often turn out not to succeed... Again, at the very least, it will take an unknown amount of time for there to be enough uptake of this replacement mechanism. And the incentives for that uptake are frankly not all that clear; do we have solid documentation of widespread dissatisfaction with the use of PSL in DMARC? (I'm not asking about the logic, but about the basis for claiming widesprea market dissatisfaction.) 2. In spite of the current fashion that encourages use of tree walk, it does not have prior field experience and in fact runs contrary to long-standing, established practices. While it might prove good to do and even better than PSL, it is, by its nature, an experimental mechanism. Including it inside the base DMARC specification encourages treating that base specification as an experiment. 3. The base DMARC specification needs to define the construct of an organizational domain and it needs to specify how one is used in DMARC operation. It does /not/ need to specify how to obtain one. Given that we will have (at least) two different methods, it is cleaner and safer to partition the 'how' out of the core, leaving only the 'what'. 4. To the extent that there is a view that having tree walk inside the base spec somehow encourages or forces adoption, experience tends to show that, instead, it makes the transition confusing. Also, see points 1 & 2, above. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
On Wednesday, January 26, 2022 10:27:04 AM EST Steve Siirila wrote: > After reading this thread, I couldn't help but wonder about how the > addition of a "PSD flag" specifically targeted to DMARC might be repurposed > for other non-DMARC applications since my understanding is that the PSL is > currently being used for other purposes as well. Just food for thought. I suspect they will be rare enough that it won't be generally useful. If it is though, there's nothing we can do to prevent it, so I think it's not something we should be overly concerned with. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is screwed up
After reading this thread, I couldn't help but wonder about how the addition of a "PSD flag" specifically targeted to DMARC might be repurposed for other non-DMARC applications since my understanding is that the PSL is currently being used for other purposes as well. Just food for thought. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
