Ale's approach has the best fit with our current reality. Lists continue to mung everything, because they cannot or will not mung conditionally, and this ensures that nothing is blocked by P=reject.
Participating lists also supply an author field to simplify un-munging, and probably a DKIM signature to ratify their own identity across any additional forwarding hops. Then, evaluators who trust the list use the author field or other clues to un-mung and re-mung. The solution is within the evaluators control, which eliminates the dubious strategy of waiting for everyone else to behave the way the evaluator or MLM thinks they should. But there has been a lot of pushback about what cannot go into our spec. Does this solution qualify because it works, or is it excluded because it is "not DMARC"? DF On Thu, Aug 11, 2022, 6:16 AM Alessandro Vesely <[email protected]> wrote: > On Wed 10/Aug/2022 15:02:39 +0200 Barry Leiba wrote: > >> This list saves From: in X-Original-From:. It'd cost nothing to switch > to > >> Author: instead. The arc list, however, saves it by appending to > Reply-To:. > >> The point is to agree on a field name. Author: seems the most > promising one. > >> > >> Now, everybody complains about how From: munging ruined their habits. > Yet, the > >> minimal effort required to restore it is deemed out of the question. > It sound > >> like a tantrum, an excuse to hold that DMARC ruined the MHS and MUST > NOT be used. > > > > Yeh, I have to take serious issue with this: > > It's not a "tantrum" to say that it's not reasonable to require all > > mailing list software and every mailing list in the world to change > > what's worked for decades in order to work around a problem caused by > > use of a new standard in a way that new standard wasn't designed to be > > used. > > > I know it wasn't DMARC's intention. But it happened. > > > > I want to see the Proposed Standard version of DMARC to make it > > abundantly and normatively clear what the intent of p=reject is and > > when it should and should not be used (whether that be at a SHOULD NOT > > or MUST NOT level is something we need to decide). It's not a > > tantrum; it's how we write standards: we avoid having them break > > long-established use whenever we can. > > > I'd say SHOULD NOT. That way we gain plenty of space to explain why a > bunch of > mailbox providers ignore that recommendation. > > > Best > Ale > -- > > > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
