On Sunday, January 30, 2022 2:57:56 PM EST Dave Crocker wrote: > On 1/30/2022 10:39 AM, Scott Kitterman wrote: > > On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote: > >> On 1/29/2022 7:53 PM, Scott Kitterman wrote: > >>>> 1. Using 7489 or 9091 as fixed, controlling documents is problematic, > >>>> as > >>>> I've noted. So, 'consistency' with them is frankly irrelevant. > >>> The WG charter doesn't say that they are irrelevant. I don't think we > >>> should be redefining terms for the sake of redefining terms. You've > >>> given no rationale for there being a problem with the current > >>> definition, > >>> so I don't think it's up to me to make the case for why things shouldn't > >>> change. > >> > >> 1. For this topic, they are irrelevant. There is nothing in the charter > >> that says terminology must be preserved. Interoperability is not > >> endangered by changes in terminology. > > > > I disagree. > > OK. Then point to the text in the charter that supports your view.
You said consistency is irrelevant. I disagreed. That's not anchored to the charter at all. > > Having the same term mean two different things in different DMARC > > RFCs is a recipe for confusion. > > 1. This ignores the concept of "Experimental" and, therefore, learning > from experience. > > 2. Your certitude about consequences means that you have clear and > compelling evidence from the field that the negative outcome will > happen. Please cite it. > > Otherwise, what you are saying is merely that you are concerned there > might be confusion. To this I'll counter that having two different > terms that cover exactly the same semantic is inherently... semantically > confusing. Yes. I am concerned that having two different definitions for the term organizational domain in RFC 7489 and DMARCbis that are technically distinct in their scope will cause confusion. What two terms are there that cover the same semantic? > > Confusion leads to programming and > > configuration errors, which definitely impact interoperability. I think > > the current definition of Organizational Domain is fine. If you think > > there is a problem with it, I would encourage you to come up with a > > different term to use in DMARCbis (and whatever other documents it's > > relevant to) and make your case. > > OD is not a programming construct. And the way to ensure consistent, > accurate programming -- or, at least, to make it more likely -- is with > clear, precise, accurate specification of algorithms, rather than by > treating unifying labels as problematic. Except when you unify two different things (organizational domain and public suffix domain it what I think you are getting at) and pretend they are the same when they are not. > >> 2. Your 'for the sake of' is uncalled for and dismissive. Please stop > >> doing that. Attempts to be dismissive are a popular debating technique > >> in the IETF, but they are counter-productive, as well as > >> unprofessional. (And no, this comment is not just meant for you. You're > >> just lucky, tonight.) > > > > I agree they are unfortunately common, but you've made no case for the > > change beyond that fact that you proposed it. > > Then I suggest you read my proposal and followup texts a lot more > carefully and even engage with their details, such the details I > reiterated that you included below... > > > You may, in fact, have a good reason > > for it, but I have no idea what it is. That's my opinion based on what I > > know. If I missed something about why you think this is worth spending > > time on, please point me at the reference or explain it. > > Clearly. I've read it all. I find no justification for your proposal and I think it's quite likely to do substantial harm. I doubt I'm going to change my mind absent some new information, so I'll step back and see if your position gains support. > >> 3. As for giving no rationale, 'tree walk' posting set the stage. > >> > >> a) Today's posting specifically noted: > >> "the move towards supporting (at least) two very different methods > >> of finding it." \ > >> > >> b) Again: for DMARC, the semantics of the different mechanisms is > >> the same. Hence a single term. > >> > >> There is quite a bit of benefit in having a single term to cover > >> different means of achieving the same goal. > >> > >> So now I'll again ask: what are the semantic differences that are > >> relevant to DMARC, and what is the benefit of having DMARC use different > >> terms, given that DMARC does not care about which mechanism is used? > > > > Since relaxed mode alignment in RFC 7489 Section 3.1 is referenced to the > > organizational domain, changing the definition of organizational domain to > > include PSDs would have a huge impact on DMARC. > > You are depending on a restriction for relaxed that is not documented > and, frankly, doesn't make obvious sense. So reliance on that isn't > helpful to this topic. I disagree. I think it's plain as day in RFC 7489. > > DMARC may not care about the > > mechanism (I agree with that), but it certainly cares about the result. > > With your proposed change maryland.gov could send mail with a DMARC pass > > from virignia.gov. While that's not particularly catastrophic, as soon > > as a non- governmental PSD publishes a record, it would be. > > Please explain 1) how that can happen under .gov, and 2) why it is > credible to claim that it could happen. Because neither is obvious to me. It's a straight forward reading of RFC 7489 Section 3.1 in my opinion. I don't know how to make it clearer than the RFC already does. I'm sorry. > >>>> 2. To the extent that the text I've proposed does not accurately > >>>> reflect > >>>> the semantics of what DMARC needs, please explain what, specifically, > >>>> are the issues. > >>> > >>> I'm not aware of any related to a need for this new text. I think > >>> that's > >>> up to you. > >> > >> Sorry no. It's not my job to guess at your objections. I'm pretty sure > >> it's your job to explain them. > > > > I've made my objections pretty clear, I think. > > 1. You have not engaged with the specific points I've made, explaining > the basis and benefit of what I've proposed. > > 2. You've relied on points that aren't documented and, IMO, don't make > sense. > > So, no, you have not made meaningful objections. No, nothing other than explaining that I think it will make it possible for unrelated domains to publish email that passes DMARC based on relaxed alignment. I think that's an absolutely fatal flaw in your suggestion. I get that you disagree with that, but fortunately in the IETF it's not up to only you and I to decide. > > I don't see any problems with the RFC 7489 definition. > > This will be perhaps the fourth time I've explained: Having different > labels for the same semantics is not helpful for distinguishing the what > from the how. What you are promoting is different labels for the how, > with no unifying term for the what. Yes and I disagree. They aren't the same. Org is used for policy and alignment. PSD is used for policy in the absence of Org policy. Those are NOT the same thing. > > If you want to change something, surely it's not my > > job to read your mind. > > It is your job, however, to read what I've written, to consider it, and > to respond to its details. I have. I disagree with you. Disagreeing with you is not the same thing as not having read and considered. > >>>> 3. The role of the function that uses the PSD and the role of the > >>>> function that does a tree walk are identical. Since you apparently > >>>> feel > >>>> otherwise, please explain. > >>> > >>> A PSD is potentially useful for DMARC policy determination if no policy > >>> exists for the exact domain or the organizational domain. It is not > >>> useful for evaluating relaxed alignment. Only the organizational domain > >>> can be used for that. So I do not think you are correct. > >> > >> The RFC 9091 does not contain the word 'relaxed', so I'm curious about > >> the basis for your assertion of the limitation. > > > > Because relaxed mode alignment is defined in RFC 7489, as defined in RFC > > 7489 explicitly excludes PSDs (although not using that term, since you > > hadn't come up with it yet), and RFC 9091 makes no changes to it. This > > is just one of the many things about RFC 7489 that RFC 9091 neither > > changes nor mentions. > I'm sorry you do not see that your logic is circular. I agree that I don't see this. I'm out on this thread until there's some clear input from the rest of the working group. One of us is wrong and we're each very confident who that is. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
