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
