> On Apr 15, 2023, at 6: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."
Not that I’ve seen everything but I’ve never known a company to register a
domain for mailing lists. That said, maybe the wording in the doc suggesting it
would raise awareness. This idea never occurred to me probably because
registering a cousin domain has its issues, yet everything is a trade off.
I don’t think should be advice but more officially recognizing there’s a
problem and here are some options which have costs and benefits for you to
consider. Preferably this would be an appendix so it can get a proper treatment
(appendix devoted to only this topic, while not weakening or muddling the core.
Neil
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
