On Tue 06/Sep/2022 15:28:10 +0200 Stephen J. Turnbull wrote:
At worst, one could set up two lists, fed by the same stream, one with munging enabled and the other not, letting users subscribe to the one they prefer.
To be honest, while I'm at best 50% willing to implement the user option, I could easily be persuaded by a few experiments with the dual list proposal. This could be implemented almost transparently for the subscriber (except at subscription time) by using an umbrella list.
That's right. I'm going to add this as another method to get rid of munged From:'s in my draft. Would you give it a review for me, please?
Internet-Draft MLM Transformations September 2022
The ARC method
For each list with From: munging enabled, a participating MLM MUST configure a twin list with From: munging disabled. Both lists have the same posting address, but separate subscriber lists. Subscribers who think that their mailbox provider runs a suitably configured DMARC filter can subscribe to the twin list. Users subscribed to both lists receive double messages until they unsubscribe or suspend delivery from one of them.
DMARC local policy overrides is one of the use cases that [RFC8617] provides for ARC. It requires that a DMARC filter be configured to accept the authentication assessments provided by a verified ARC chain when all of the domains involved are marked as trusted. In that case, the filter overrides DMARC policy and acts as if the current Authentication-Results: were the ARC-Authentication-Results: (AAR:) of the first ARC set (i=1). Normally, a MLM SHOULD apply DMARC policy on message arrival, so the first AAR: is expected to have dmarc=pass.
MLMs which in turn trust third party domains, such that they override DMARC failures in posted messages, MUST communicate the list of trusted domains to subscribers when they announce the creation of the twin list, and on subsequent modifications. How users can query the list of domains trusted by their mailbox providers is beyond the scope of this document. Anyway, all the domains possibly trusted by the list MUST be trusted by the user's MTA as well, and by any subsequent MTA in case of forwarding.
TIA Ale