Your expectations are very different from mine. 1) MLMs have a releationship with their subscribers, and could collect data for conditional munging, if they chose to do so and their software provided the necessary capability.
2) I don't see how "wide deployment" can ever be determined without a data collection process. Having MLMs collect data from their subscribers is one option, and I don't know of any others that are on the table. 3) ARC depends on evaluators choosing to trust the ARC data source, but trusting the source was the original problem. So ARC deployment, by itself, does not seem to be a solution. 4) I have not heard anyone suggest the AOL/YAHOO will trust ARC. 5) My review of available ARC data indicates that it is vulnerable to a lot of source-specific variation in content, which will make parsing very difficult in the general case. It appears to be no small feat to parse ARC data to determine (a) that a forwarding operation occurred, and (b) whether the forward was performed by a server that exists on a local-policy list of trusted forwarders. DF On Wed, Aug 10, 2022 at 11:44 AM Barry Leiba <[email protected]> wrote: > 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 > <[email protected]> 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 <[email protected]> > wrote: > >> > >> On Tue, Aug 9, 2022 at 2:01 AM Alessandro Vesely <[email protected]> > 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
