This assumes that email which transits a list will fail DMARC evaluation. While that's the most common case, it's nowhere near universal.
This isn't something that can be reduced to a simple truth table and optimized to a single solution. Scott K On October 15, 2021 10:36:13 PM UTC, Douglas Foster <[email protected]> wrote: >To be completely clear about Murray’s concern: > >There are three possible strategies for lists to handle postings from >DMARC-enforcing subscriber domains: > >- Never rewrite From > >- Conditional – rewrite From if required by evaluator > >- Always rewrite From > >Similarly, there are three relevant security postures for evaluators: > >- Always block on DMARC Fail >- Exempt my list from DMARC fail >- Never block on DMARC FAIL > >We can construct a grid showing the possible outcomes > > \ --------- Evaluator Policy --------------- >List Policy \ Block Fails | List Exempt | Ignore DMARC| >---------------+--------------+-------------+-------------+ >Never Rewrite | Blocked* | OK w/o Mung | OK w/o Mung | >---------------+--------------+-------------+-------------+ >Conditional | OK with Mung | OK w/o Mung | OK w/o Mung | >---------------+--------------+-------------+-------------+ >Always Rewrite | OK with Mung | Wasted Mung*| Wasted Mung*| >---------------+--------------+-------------+-------------+ > >Asterisks indicate inferior outcomes. > >As in all of life, some actionable information is better than none, as long >as the actionable information is used to take action. Consequently, >the Conditional >strategy will always outperform a strategy based on no information. > >Note that the Conditional strategy is superior even if no evaluators make >exceptions for the list. Superior outcomes are achieved with as little as >one recipient domain with actionable information. > >The Conditional strategy is also superior even though complete information >will not be available. All that is needed for a win is to have SOME >information. It just requires a list that is willing to collect and use >actionable information. > > >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
