Personally, I prefer the latter of the two, quoted below.
"to preserve interoperability, domains SHOULD NOT publish p=reject unless they are
[not general purpose]* domains"
"Publishing DMARC records with restrictive policies does cause interoperability
problems for some normal email usage patterns. Potential impacts MUST be considered
before any domain publishes a restrictive policy."
These two combined address how p=reject interoperability risks are considered
on most [general purpose] domains today during implementation, while also
making well-known the damage that a strict policy can cause to [some types] of
indirect mail flow.
On 4/8/2023 7:52 PM, John Levine wrote:
It appears that Scott Kitterman<skl...@kitterman.com> said:
We could do I think any of the following and they are roughly semantically
equivalent:
[general purpose]* domains MUST NOT publish p=reject to preserve
interoperability
to preserve interoperability, domains SHOULD NOT publish p=reject unless they
are [not general purpose]* domains
which could be accompanied by:
[not general purpose]* domains SHOULD determine their email authentication
deployment is accurate and complete before publishing restrictive policies
(p=quarntine or p=reject) to avoid interoperability issues.
Publishing DMARC records with restrictive policies does cause interoperability
problems for some normal email usage patterns. Potential impacts MUST be
considered before any domain publishes a restrictive policy.
* whatever the right formulation is, that's a related, but distinct (and I
think less controversial question).
I'm OK with any of these.
I do think it's important to make it clear that you lose interopn when
you publish a policy on a domain that's sending more than transactions
or spam.
R's,
John
_______________________________________________
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
