Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

[Douglas Foster <[e-mail]>]

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 <[e-mail]>
wrote:

> On Tue, Oct 12, 2021 at 4:42 AM Douglas Foster <
> [e-mail]> 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
>