The question was about this list, because Murray has advised that every
specification needs a working prototype. Barry has said that we will not
bloat DMARCbis with advice to mailing lists, but it could be in a companion
document. The topic is closely tied to DMARCbis so there is no other
group which is well positioned to explore the options.
The first conclusion from this discussion is that options exist. The best
option depends on the evaluators involved.
A variant of Baptiste's proposal is to announce and send a test message
that violates DMARC. As he said, rejects and bounces tell you which
evaluators distrust the list. Positive replies ("I got the test")
indicates a domain that is not enforcing DMARC against the list. Negative
responses ("When are you sending the test?") also indicate blocks.
Recipients with no response are ambiguous, but suggest a block. Of
course, an organization's security posture may change over time, so this
result is not stable.
To Ale's point, un-munging should be very simple with an ARC set that
documents the original RFC5322.From value. This still requires that the
evaluator recognize the list as a sender for whom un-munging is desirable.
This desire implies some level of trust in the list and an ability to
distinguish trusted lists from all other traffic, To support that trust
decision, I come back to the need for an operating practices disclosure
document. Essentially, the negotiation still occurs: the evaluator is
unlikely to do anything until requested by a subscriber in his domain, and
then the evaluator will look to the list's published documentation to
decide whether to un-mung.
Questions to consider:
1) For evaluators that enforce DMARC against lists, are they willing to
consider any concessions to list traffic? If so, do they favor an
exemption process where the list avoids munging, or an unmunging solution
implemented at their inbound gateway?
Although inbound gateways routinely add content to inbound messages, I am
fearful of adding custom code to do so myself. So I would prefer a
solution that avoids munging at the source, rather than a solution based on
double changes to mung at the list and unmung at the gateway.
Eventually, we can hope that the optimal solution becomes a standard part
of product offerings, so the fear is diminished. The un-munging solution
requires identifying the list traffic and reversing the changes, but may
have added trust if un verified signatures can be made verifiable. The
negotiated solution requires only the ability to identify the list traffic,
but has no expectation of restoring broken signature.
2) For evaluators that do not enforce DMARC against lists, would a
mung-free solution for mailing lists allow them to enforce DMARC against
other traffic to improve their security posture? It seems like they have
a double whammy: Their users get munged mail because of what other
domains might do, but they are afraid of using DMARC results because of
lists that do not mung.
Doug
On Tue, Jul 18, 2023 at 6:04 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:
> Hi,
>
> Le 17/07/2023 à 03:50, Emanuel Schorsch a écrit :
> >
> > - By default FromMunging remains the practice without special
> > information.
> > - MailingLists add ARC Headers and an additional header for what the
> > unmunged FromHeader was
> > […]
> > This gives the information needed to evaluators to undo the fromMunging
> on
> > their end.
>
> Well, call me a pessimist if you will, but I parse this as: generalize
> FromMunging now in the hope for a future, "potential", solution. It
> looks like a trap: if FromMunging gets even more normalized, evaluators
> will have even less incentive to work towards an actual fix.
>
> The best outcome I see is that power users will be able to undo the
> munging client-side with a MUA-plugin. Which is nice, but only solves
> the problem for a very small part of the community.
>
> Cheers,
> Baptiste
>
> _______________________________________________
> 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
