On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote:
> On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson <[email protected]> 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.
rs= Requested SMTP Error String (plain-text; OPTIONAL; no default).
The value is a string the signing domain requests be included in
[SMTP <https://www.rfc-editor.org/rfc/rfc6651.html#ref-SMTP>] error
strings when messages are rejected during a single
SMTP session.
The usage of "rejected" here is interesting because I'm seeing permanent 4xx
throttling being employed for the duplicate message local policy limits, not
rejects. I assume it's common for throttling to be employed before outright
rejection, perhaps under the assumption that the message could be retried in a
different fashion in order to be accepted. But without additional details about
how the message could be retried, it is effectively equivalent to rejecting.
> Thus, I never heard of any implementations besides the first one.
Looking at passive DNS data... Only 16 domains had the _report._domainkey.
record historically (as observed by queries through the collectors on the
participating recursive resolvers). 3 have/had spf record values. Low query
counts on all, suggesting that they don't add r= to their dkim-signatures, or
there aren't many significant report generators issuing queries for the record
through the participating resolvers.
Jesse_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
