On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > > The Sender's users being denied the ability to participate in a list due > > to its policies seems to me like it puts this customer service problem > > where it belongs. > Let's say, tomorrow, IETF configures this list to reject Todd's mail (as > well as for every other member with p=reject) and/or disables from > rewriting. Does Todd's domain owner care? No. Todd cares. Todd can't argue > with his CISO and IT security team and biz dev team and public relations > team and legal team and all of the other forces that caused his domain > owner to publish p=reject. But he can argue with IETF for making the > decision to make the change, because he feels like the IETF considers him > an important stakeholder. > > It's this list's customer service problem, like it or not. > > After calling IETF customer service, Todd finds out his options are: > 1. Create an email address in a domain that houses members of the general > public, instead of one that represents his identity as a member of a > company. 2. Don't participate in the list. > > But Todd is really important to this list, and doesn't like these options. > Surely something can be done for an old friend? John, having been escalated > this customer service dilemma seeks DMARCbis for guidance and finds: > > ...MUST NOT p=reject... > (Todd's company is pretty clearly stating Todd mustn't be representing his > company on any mailing list.) > > ...Domain Owner MUST provide a different domain with p=none for mailing list > participants. (Maybe they do, maybe they don't, but it's worth asking.) > > ...Mailbox providers MUST NOT reject or quarantine email based solely on a > DMARC policy violation. (John could ask each mailbox provider to create an > exception to their DMARC policy enforcement) > > and he also finds something like: > > ...If a mailing list would like to provide the best customer experience for > authors within domains that violate the "MUST NOT p=reject" and to deliver > the author's mail to mailbox providers violate their "MUST NOT solely > enforce", for those authors the mailing list MUST rewrite the From header > to use a different domain. This is a new mode of interoperability the > mailing list may choose to adhere to. > > John now knows what he MUST do to provide the best customer experience given > the reality he finds himself in with an important stakeholder. He can > choose to ignore that MUST as much as the domain owners and mailbox > providers will choose to ignore their MUST NOTs. > > I feel like there will be very few mailing lists that will ever stop > rewriting (among those who are doing it), especially if DMARC adoption > (publishing and enforcement) continues to rise. This is the new way of > interoperating, in reality. > > Throw them a bone so that they have a MUST to justify the things they had to > do to interoperate all this time. It's not as easy for them to justify > their reality with only this page > <https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail> > to lean on.
Or Todd gets a Gmail account for his IETF work and doesn't bother tilting at windmills. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
