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 <dcroc...@gmail.com> 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
