Having negotiations between senders, evaluators and lists sounds difficult. I agree the dream would be to have at least a semi-automated solution which works. I'd be interested to hear what you think of the following rough idea (with the assumption that most lists today are currently doing FromMunging on p=reject domains):
- By default FromMunging remains the practice without special information. - MailingLists add ARC Headers and an additional header for what the unmunged FromHeader was (with some agreed on standard, e.g. Wei's proposal <https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00> to use `Prior-From`). This gives the information needed to evaluators to undo the fromMunging on their end. Evaluators can check the original authentication in case the list does not enforce authentication checks. More importantly, evaluators can undo the fromMunging and restore the original header within the evaluators system. This can be based on an explicit system (user manually adds a setting that this list is trusted), or an implicit system (evaluator sees that the list is trustworthy in general, or that is implicitly trusted by the specific recipient). This would place a burden on MailingLists (to add Arc headers and original FromHeader) and would place a burden on evaluators (to have a refined evaluation method with a nuanced understanding of "trust" in lists). It seems if both parties showed interest it would be a tractable solution. A nice aspect of this solution is that I don't believe these changes would break non-participants, and gradual adoption by individual lists / evaluators would show benefits. Emanuel Schorsch On Sun, Jul 16, 2023 at 1:51 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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 < > devel2...@baptiste-carvello.net> 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 >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > 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
