[kevincox]

This is a strange set of changes to me. Most of them seem to have little to no benefit. None of them seem worth the migration effort except for "policy for non-existent subdomains".

There are two changes I would like to see but that don't seem to be addressed.

1. Option to require DKIM, instead of the current SPF *or* DKIM. I can hold my key close and have less trusted forwarders (which is sometimes necessary for receivers who are very picky about source IP) without allowing them to send mail that I didn't pass to them. For example with AWS SES I can hold the key and let them deliver my mail. But with the current situation they can also corrupt or make up new mail and it is trusted because it passes SPF. If I could say that the message *must* have a DKIM signature then they can't do that.

2. Solving mailing lists. Right now I use p=reject so my participation on many mailing lists (including IETF ones) is basically prevented. Google Groups does sender rewriting when solves this in an ugly way, but it isn't common and it would be nice to have a standardized solution.

Why bother adding a successor to pct? It works fine, so what if people always use pct=0 or pct=100, that is fine. No need to add a new spelling and confuse everyone.

> what’s the “denominator” and how do you estimate it?

Roll a d100 and if it is <= pct then apply the policy to the message. I don't get what is confusing about this.

[matteocontrini]

Both the "require DKIM" and the mailing lists problem were discussed at length by the working group, with many having opposite strong opinions, so in the end the only consensus that was reached is a trade-off that left everyone unsatisfied.

There's hope that the mailing list problem will be solved by DKIM2 [1], since ARC has the problem of trusting the intermediaries.

On `pct`, you're right in theory, but it seems that implementers didn't get the message. From the mailing list [2]:

> That's how we intended it when we wrote that, and that's how early implementations did it. But maybe this is the lesson: People have inferred lots of different things from that rather straightforward definition, so maybe it's more ambiguous than we realized all those years ago.

And the draft says [3]:

> Operational experience showed that the pct tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

I agree that replacing it with another tag is such a confusing and unnecessary change, though.

[1] https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...

[2] https://mailarchive.ietf.org/arch/msg/dmarc/Sk6JnDlXH_MkM4xm...

[3] https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarc...

[kevincox]

> the only consensus that was reached is a trade-off that left everyone unsatisfied

Yeah, that is sort of what I assumed :(

> other values varied widely from one implementation to another.

IMHO the best solution to this is:

1. Clarify the specification so that future implementations are more likely to be correct.

2. Add a note that only pct=100 and pct=0 are recommended as the other values are inconsistently implemented. I would even rather go as far as calling all other values deprecated than add two new values that mean the exact same thing but will force implementations to support both and open this chicken and egg of you can't really switch to the new one because not everyone will support it. Just say that the pct flag has two possible values 100 and 0.