As long as the unsympathetic evaluator produces a reject or bounce, the automatic digest approach will work well. if digest mode failover is implemented as an operator function, it could be implemented quickly without software changes . Automating the process seems like a minor undertaking as well. If the evaluator does silent discard, your approach depends on the evaluator noting that messages are missing.
To get out of digest mode, the user still needs to negotiate with his evaluator. You are despondent on that point, I am more hopeful, especially for this particular list's participants. For the negotiation to be successful, I think the user will need the information I discussed, including: a commitment of 100% sender authentication prior to forwarding, a definition of how the evaluator can identify list traffic, and clarity about what content filtering is or is not done before forwarding. We don't want the list to be blacklisted simply because the evaluator has stricter content filtering than the list provides. Both your approach and mine will isolate the problem to unsympathetic evaluators and their unfortunate users. Both approaches know that we must either modify the evaluator's filtering rules or live within those rules. Neither of these two approaches requires asking senders to lower their security posture from p=reject to p=none., and both eliminate From munging, which is a big win. Doug Foster On Sun, Jul 16, 2023 at 9:25 AM Baptiste Carvello < [email protected]> wrote: > Hi, > > Le 15/07/2023 à 12:22, Douglas Foster a écrit : > > [...] > > Track 2: Exception Request > > [...] > > Track 2 benefits: > > [...] > > - Elimination of From munging is potentially available to all > > participants, even those from p=reject domains > > This important word here is "potentially". In practice, only an > insignificant part of this potential can be achieved, because your plan > heavily relies on non-automatable human work, and on end users being > able to weight into their providers' policies. > > Thus for all practical purposes, "conditional munging" is equivalent to > plain munging. > > Therefore I propose Track 3: > > 1) We undo existing munging. > > 2) We inform end users that, if they do not receive messages from > certain senders (especially those senders whose addresses were > previously munged), they can regain them by switching their subscription > mode to "digests", at least temporarily while their mailbox provider > fixes their DMARC handling. > > 3) Whenever we get bounces, we configure our software to forcibly switch > the offending users (I mean the receivers) to "digests". We inform the > impacted users that they can try resetting their subscription mode to > plain messages after a few months, in case their provider fixed their > handling in between. > > 4) We publicize our rules widely, so mailbox providers know how to avoid > inconveniencing their users. > > Track 3 benefits: > - fully automatable > - doesn't break the semantics of conversations (digests correctly embed > the messages instead of improperly claiming authorship) > - gives mailbox providers an incentive to move to a more sophisticated > DMARC handling. > - doesn't rely on the sending side to fix their practices, as the > consensus here seems to be that it will never happen. > > Cheers, > Baptiste > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
