Please, no. This WG has already run a year past its sell-by date. Stuff
like this will just tell the world that we'll never finish.
Apologies. I wasn't trying to disrupt dmarcbis finishing. Ever since I saw
consensus start to form, I started citing dmarcbis whenever explaining how
DMARC
On Wed, Aug 23, 2023, at 11:11 AM, John Levine wrote:
> It appears that Jesse Thompson said:
> >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
>
> Please, no. This WG has already run a
We have many considerations and if we “are [near] finish” then please publish a
new draft to see where are at. With so many unknowns, its fertilizes
uncertainty, “desperate questions” and ignored suggestions and proposals.
I believe an update is warranted.
All the best,
Hector Santos
> On
Apart from "never finish", I would contend that changes of that nature
violate the "preserve interoperability with the installed base of
DMARC systems" clause of our charter. We *can* make changes such as
this if we have a reason that's compelling enough, but as we talk
about changing the strings
It appears that Jesse Thompson said:
>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
Please, no. This WG has already run a year past its sell-by date. Stuff
like this will just tell the
p=reject has two effects:
- It makes impersonation attacks less likely to be successful, and
- It encourages attackers to chose other domains for impersonation, since
attacks on protected domains are more likely to fail.
Therefore, evaluators should expect that most attacks will occur against
On Mon, Jul 24, 2023, at 1:03 PM, Neil Anuskiewicz wrote:
>
>
> > On Jul 19, 2023, at 3:21 PM, Douglas Foster
> > 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