I can support Todd's language: "Domain Owner MUST provide a domain with p=none for mailing list participants"
because it presupposes participation with a mailing list, in particular a mailing list that presumes a right to modify content in transit. Mailing lists are not the only cause of non-malicious DMARC violations, but they are apparently the most significant. Another potential cause is forwarding after a content-altering spam filter. The use of "external sender" disclaimers has become pretty common as part of cyber-insurance contracts. Appropriate language would be: - Domains that allow forwarding to external sources should not allow spam filters to add or alter content. Similarly, domains that allow spam filters to add or alter content should not allow forwarding outside of the organization. Many of the other problems involve the From user being set to match the recipient address, because the message was triggered by the recipient using the sender's website. This problem is more contained and probably not worthy of our mention, since those senders should behave differently. Doug Foster On Sat, Apr 15, 2023 at 9:56 AM Jesse Thompson <z...@fastmail.com> wrote: > On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote: > > 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. > > > That was the first option in the customer service dilemma, and it is the > option I have chosen for now. I do not carry my company's brand in anything > I say here. All opinions expressed are my own, [but maybe my opinions carry > less weight as a result?] > > Why not turn off rewriting on this list, as an experiment? The hypothesis > is that everyone will switch to Gmail and not tilt at IETF, but instead > they will tilt at their domain owners. > > Earlier it was accused that no one is offering alternative language > proposals. > > I feel like "Domain Owner MUST provide a domain with p=none for mailing > list participants" was a reasonable suggestion, and isn't incompatible with > "MUST NOT p=reject for domains with members of the general public". A > couple of people found it acceptable when I suggested it before, and no one > else rejected it (or read it). That kind of language makes it more clear > that the domain owner must work to sort out their mixed-use domains (by > adopting all of the great subdomain/treewalk/psd additions in DMARCbis). > > And the "If a mailing list would like to provide the best customer > experience...MUST rewrite" suggestion seems like a reasonable way out of > this "interoperability vs reality" standoff. How about if I soften it up > further: > > "Any sender (mailing list, forwarder, ESP, or otherwise) which is tasked > to send unauthenticated email from an address within a p=reject|quarantine > domain it MUST refuse to send the message or send the message using an > RFC5322.from address in a different domain." > > Jesse > _______________________________________________ > 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
