On Sun 10/Sep/2023 18:44:00 +0200 Jesse Thompson wrote:
On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote:
On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson <z...@fastmail.com> wrote:__
Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in
control of the signer, as opposed to the attacker.
Has anyone (else) implemented it?
That's what I want to understand. Or, more specifically, if no one implemented
it, why? And have those blockers changed due to the changed landscape with dkim
replay, etc.
When DKIM was young, a mechanism like the one defined in RFC 6651 was enormously valuable to me when two implementations were trying to debug interoperability problems. It allowed us to see why signatures were failing.
Once all the bugs were worked out and things like canonicalization and common MTA mutations were well understood, the need for this sort of thing faded away.
DKIM Replay is leading to interoperability problems as result of local policies
being rolled out to mitigate the abuse, and senders (and their customers) need
to make changes to their configuration to not get caught up in the emerging
algorithms. Examples may include duplicate message throttling, blind recipient
limitations, tighter expiration enforcement, etc.
I think usage of the 'p' and 'x' reports and the 'rs' tag would be valuable
(perhaps enormously, as you experienced first hand)
p Reports are requested for signatures that are rejected for local
policy reasons at the Verifier that are related to DKIM
signature evaluation.
x Reports are requested for signatures rejected by the Verifier
because the expiration time has passed.
These look like aggregate data that could be included in DMARC reports or
extensions thereof. Perhaps that tool has more traction than 6651.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
