Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

[David I <[e-mail]>]

This is the scenario we've seen across the UK public sector - at p=none, DMARC reporting showing lots of DMARC fails (SPF+DKIM failing) from IPs associated with an email service provider which both originates email and forwards it (commonly Google). At this stage you don't know if the failed messages are originated or forwarded and so if they will be lost at p=q/r, pct=100. When you switch to p=q,pct=0, forwarded messages are re-written, and so are not included in the DMARC reporting, and so if any failures remain, additional configuration associated with originating messages is required. If not, you're good to go from pct=0 to something stricter.

Benefit: Improve adoption of p=quarantine/reject by reducing the number of domain owners who to get stuck at p=none as they're unsure if switching to p=quarantine/reject will cause loss of legitimate email.

>From a 'getting people started with DMARC perspective', having p=none be 'safe' and not affect mail flows is attractive, and so having the behaviour change require an additional change is good. The fact that it's an opaque hack using p=q, pct=0 is a shame, and clarity of how you trigger this behaviour change in the document would be good.

HTH,
David

________________________________
From: dmarc <[e-mail]> on behalf of Dave Crocker <[e-mail]>
Sent: 03 August 2021 22:08
To: Todd Herr <todd.herr=[e-mail]>; IETF DMARC WG <[e-mail]>
Subject: Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion

On 8/3/2021 1:42 PM, Todd Herr wrote:
That doesn't mean that I think it's not a useful setting on the journey from p=none to something stronger; it only means that I can't remember the particulars of the rewriting that takes place and how the domain owner can take advantage of information revealed by the rewriting in order to eventually remove the pct tag.

It might be this:


I'm not trying to argue against your proposal or the one that preceded it, but am concerned that there be a pretty clear and strong case made for specific benefit.  That is, clarity about what the benefit will be and clarity that there is shared agreement that the benefit will be obtained and that it is substantial.

The pct style of mechanism is not typical for protocol standards, although it comes from a common system development background.  And the fact that its use in DMARC is prompting significant change to that mechanism warrants additional care in justifying it and documenting it.  IMO.


d/

--
Dave Crocker
[e-mail]<mailto:[e-mail]>
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[e-mail]<mailto:[e-mail]>

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [e-mail]. All material is UK Crown Copyright ©