Indeed, a problem with munging, or with any other workaround that mailing-list software might do, is that the problem happens at subscribers' domains, not at the mailing-list domain, and the mailing list software has no idea what's going to happen on the subscriber's side. It can only see that the sender's domain has p=reject and apply the workaround to all the fanned-out copies just in case.
Even with ARC, we have the same problem: the mailing list can put the appropriate ARC seals on, but it has no idea which recipient domains have implemented ARC and which have not. Making ARC work involves having it implemented widely enough that the other workarounds are needed seldom enough that we don't have to do them any more. Barry On Wed, Aug 10, 2022 at 9:16 AM Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote: > > To avoid munging, MLMs have a double problem: (1) the evaluator must find > an alternative to DMARC for concluding that the message is "not untrusted", > and (2) the MLM must know that this trust has been granted. > > If (2) is known for some recipients but not others, the MLM must be able to > make munging conditional on the destination domain. Given the perceived > intransigence of AOL, having (2) known for all recipients is not expected. > > Based on previous conversations, MLMs are not willing to perform conditional > munging, so munging cannot be prevented if any subscriber domain publishes a > policy other than "none". > > Unminging has the advantage of being a local policy implementation with > potentially no dependency on the MLM. > > But unmunging must be reversed if any messages are re-forwarded. The > technical challenges of knowing when to re-mung seem significant. > > DF > > On Wed, Aug 10, 2022, 12:14 AM Murray S. Kucherawy <superu...@gmail.com> > wrote: >> >> On Tue, Aug 9, 2022 at 2:01 AM Alessandro Vesely <ves...@tana.it> wrote: >>> >>> > Because there are more ways for a forwarder to change a message than you >>> > or >>> > I can describe. >>> >>> That critic applies to my draft, not to unmunging in general. The only >>> change we care about here is the From: field. While there are many ways to >>> munge it, there is a simple way to restore it: >>> >>> IF message is dmarc=pass AND From: domain belongs to $MAILING_LIST_SET >>> IF Author: is set >>> RENAME From: Munged-From: >>> COPY Author: From: >>> >>> Et voilà! >> >> >> This only works when that second "if" is true. Of all the emails in this >> particular thread, only yours have it set. >> >> So now, perhaps a hyperbolic question, but: If we were to adopt and publish >> draft-crocker-dmarc-author, what's the likelihood that we could get all MUAs >> to start adding it? And then, what's the likelihood that it will remain >> pristine in the future? >> >> -MSK >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
