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.
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
