On Sun, Jul 16, 2023 at 6:50 PM Emanuel Schorsch <emschorsch= [email protected]> wrote:
> 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`). > > Apologies that the draft-chuang-mailing-list-modifications I-D is in rough -00 form i.e. there's some more clean up needed. And agree in hindsight that the draft should be based in ARC (RFC8617) and separately call out how it modifies draft-chuang-replay-resistant-arc. -Wei > 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 < > [email protected]> 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 < >> [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 >> > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
