Re: [dmarc-ietf] Signaling MLMs

[Scott Kitterman <[e-mail]>]

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