The other problem is that the Tree Walk makes the entire document experimental. Tree Walk is a great tool for batch-mode detection of PSL errors, but it has multiple problems as a real-time tool.
- It disables best-guess DMARC based on default policy. Instead of disabling best-guess DMARC, this document should be embracing it. - It is prone to inconsistent results and indeterminate results caused by DNS errors. - Multiple DNS lookups are reasonably expected to have lower performance than one database lookup, especially since high-throughput environments can use memory-resident databases for the PSL lookup. - Inconsistent results can be mitigated by using long-term caching outside of DNS, but that adds complexity and overhead. On the benefit side, our limited testing has found zero PSL problems that were previously unknown, while discovering a tiny number of instances where the Tree Walk appears to have returned an inferior result. However, our pilot sites did not start from a blank slate, because they had knowledge of some PSL defects. For organizations that have no prior knowledge of PSL problems, the Tree Walk protects them from that ignorance. But that knowledge only needs to be learned and applied once; it does not need to be learned on every message. In aggregate, I see no justification for DMARCbis to be given Standards Track status, unless the Tree Walk is separated out as an experimental option, either in an appendix or in a separate document. On Sun, Nov 3, 2024 at 6:59 AM Steven M Jones <[email protected]> wrote: > On 11/3/24 3:45 AM, Alessandro Vesely wrote: > > On Sun 03/Nov/2024 04:22:39 +0100 Steven M Jones wrote: > >> I've been looking for documented requirements around whether a > >> Proposed Standard can reference an Experimental document. I reviewed > >> RFC 2026 and ... > > > > If such a restriction existed it would only be about normative > > references. And we don't want to cite ARC as normative at this stage, > > methinks. > > > Thanks. My motivation was to make sure we are clear about any explicit > requirements, and can reference the appropriate text, as we try to > anticipate/address objections to the current text. > > I meant to leave consideration of specific objections and responses for > other threads, so I won't go any further with that here. > > --S. > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
