You miss the point. Many domains are receiving From-Munged mail when they do not want or require From-Munging. I expect that this includes most of the .EDU world. If mailing lists asked their users whether munging was necessary, they could make some of their users happier immediately.
If the big mailbox providers don't want to create exceptions, the lists can continue to From-Mung for them. No evaluator has to make any exceptions than they do not want to make. But if an evaluator is willing to make an exception, somebody internal needs to ask for it, and the exception requirements need to be well-defined. This is so obvious it should have been implemented by the lists a long time ago. Increasingly, I don't think this is a problem that matters. If it was, lists could have devised this strategy years ago, without my help. Doug Foster On Thu, Oct 14, 2021 at 12:48 AM Murray S. Kucherawy <[email protected]> wrote: > On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster < > [email protected]> wrote: > >> Under a collaboration solution, the subscriber goes to her email support >> and says,"I joined list X, and they say that for the best user experience, >> we need to configure a whitelist entry to bypass >From Filtering on >> messages from one SPF-verified SMTP address. Then I need to give them a >> response whether this change has been implemented or not." >> >> Under an unmunging solution, the subscriber conversation is more like >> this, "I joined list X, and they say that for the best user experience, we >> need to configure an unmunging MTA. Hope this is not too much trouble. I >> hope you can get this implemented quickly." >> > > It feels to me like an arrangement like this can't scale well. Given > millions of users at a single email service provider, even a fraction of a > percent of those joining lists means thousands of people have register with > the MTA in some way. This causes two problems: > > a) Many users will forget, many others will be confused by the process > since they've never had to do that before; you should expect that all of > those will complain, screw it up, or both. > > b) Teaching an MTA to use a configuration file with that scale of entries > seems like it would be a beast. Large scale infrastructures can possibly > handle something like that, and boutique operators only have to do it for > their small handful of users, but the space in between could be pretty > unpleasant. > > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
