Trying to stay within Barry's guidelines, my original comment was about this list, but with an eye to how it can be generalized.
In any specific case, the message stream from a list like our own should be identifiable by seeing expected values for: - MailFrom address = list bounce address - DKIM signature with DKIM PASS (to retain authentication after secondary forwarding) - List ID - To address = list's posting address - SPF PASS or SPF NONE at first hop after list forwarding - ARC data that identifies the forwarding point and affirms the author identity I do not suggest that a general mail stream can be parsed to detect a previously unknown list. Nor do not suggest that an automated detection process can be safely used to grant the privileged status needed by lists. I do think ARC will need additional tokens to describe tools other than SPF and DKIM which a list may use to authenticate a post's author. Options for our specific list: We have alternatives to the current munging behavior, and this group is highly motivated to see munging go away. So something should be done. Baptiste's proposal is clearly the easiest to implement: Admins inform the group that IETF is going to stop munging on a specific date. After that date, subscribers are switched to digest mode if the MLM or the user detects problems. Admins switch them back when the user reports that the list traffic has an exception in place by the subscriber's evaluator. This approach may also be sufficient for this list, as I suspect that most of our evaluators will already have an exemption for IETF. Emanuel's approach requires software development by every evaluator or their software providers. The Intranet has a decreasing number of software providers and hosting services,, but this scope seems problematic even for the limited scale of this list. The larger problem is that the software implementation still needs human guidance about which messages should be un-munged. Malicious actors will add un-munging signals if they think it will enhance their attacks and permit impersonation. So I keep coming back to the most difficult proposal, which is my own. An evaluator needs to be able to identify specific list traffic using information provided by the list, probably through a disclosure statement or service agreement document. To facilitate automation, the disclosure could eventually be standardized as an XML document, perhaps supplemented by free-form content for human consumption. We need an initial list, our own, to work out that standard. Ultimately, my approach still requires a transaction where a human decides to trust the list and restore it to "privileged" status, typically in response to a support ticket from a subscriber to his own email administration. I admit that my approach also has scaling problems, because each list must be considered individually. For the moment, the scope is one list, not all lists. Being a trustworthy list is also very important to me. Baptiste's approach does not require the list to make any promises, so it does not require the list to undertake any security improvements. I want to see this list implement 100% sender authentication even more badly than I want munging removed. I want that level of authentication to become the norm when the concept scales upward. Disclosure statements only work when they are not announcing vulnerabilities. Doug Foster On Wed, Jul 19, 2023 at 2:20 AM Murray S. Kucherawy <[email protected]> wrote: > On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < > [email protected]> wrote: > >> 1) For evaluators that enforce DMARC against lists, are they willing to >> consider any concessions to list traffic? If so, do they favor an >> exemption process where the list avoids munging, or an unmunging solution >> implemented at their inbound gateway? >> > > How do you determine that an evaluator is enforcing DMARC "against > lists"? How can one definitively identify list traffic? > > Also, I imagine that if munging is to be considered reversible, either the > munging itself, or a way to describe it, needs to be standardized in some > form. > > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
