On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote:
>
>
> > On Jul 19, 2023, at 3:21 PM, Douglas Foster
> > <dougfoster.emailstanda...@gmail.com> wrote:
> >
> >
> > Perhaps you can clarify what you think DMARC is.
> >
> > Apparently a significant number of evaluators think that "DMARC Fail with
> > p=reject always means unwanted mail". Or to use Michael Hammer's
> > language, "DMARC Fail with p=reject means the domain owner wants it
> > rejected so I will reject it." These are exactly the attitudes that
> > cause us so much trouble because (a) DMARC Fail with p=reject does not mean
> > that rejection is always the correct response, and (b) DMARC Fail with
> > p=none is an important piece of information.
>
> Doug, if what you’re saying is true then the root cause might be our fault.
> If we’ve not communicated clearly enough DMARC’s purpose. A communication
> problem likely needs to be solved with more and better communication via the
> standards doc itself and other channels.
>
(again, apologies if already suggested, still working my way through the
backlog in my spare time)
I'm beginning to think that a solution to this problem is "other channels"
Let's discuss p=interoperability, p=compliance, or p=orgname:policyname
"By the book" receivers who see an "invalid" policy will treat it no
differently than p=none, and intermediaries will not bother trying to munge.
So, it is achieving the interoperability objectives of IETF
"Smart" receivers will see that the policy is a reference to a policy
definition that can be queried in some standard fashion. The policy owner can
articulate clearly what the policy means.
IETF should not be in the business of describing the mail handling policies
that exist in practice or any that will emerge, but should define how those
policies are communicated (for interoperability sake).
Domain owners interested in achieving compliance will gravitate towards
p=compliance over p=reject (because compliance is what they are trying to
achieve), or they may choose to define their own p=orgname:policyname namespace
if they want to get more specific in describing their intended mail flows
Those that wish to express backwards compatibility can use p=interoperability
or a p=orgname:policyname namespace that expresses policy in some other way
Jesse
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
