| 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... |
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.