On 1/5/25 7:51 PM, Jim Fenton wrote:
On 5 Jan 2025, at 19:07, Murray S. Kucherawy wrote:
On Sat, Dec 28, 2024 at 6:31 PM Bron Gondwana <brong=
[email protected]> wrote:
- The SMTP RCPT TO address might not be present in the signed header
fields of an email, meaning that the same message can be sent to
arbitrarily many recipients, and those recipients can not tell if the
signer intended to them as recipients.
Am I poking a hornet's nest here, or is it safe to state that this is the
commonly understood definition of "DKIM replay"?
As was brought up elsewhere, do we need to be clear about whether this is
expected to be an extension of existing DKIM or ultimately a replacement of
it? Or are we keeping our options open, which is what the current text
seems to be doing?
I have recently received a number of these replays in my personal email, so I
think I understand the problem better.
At the risk of getting too far into the weeds:
The RCPT TO address isn’t available to many DKIM implementations, so including
it in the signature would be a breaking change. But DKIMbis could define an
additional signature field, similar to the b= field but including the RCPT TO
address. This would be ignored by current DKIM implementations but could be
used by DKIMbis implementations, with the additional benefit of making it clear
that it is the RCPT TO address, and not anything else, that has changed. That
would be a non-breaking change.
Assuming the other goals of DKIMbis can be accomplished in similar ways, I
consider the non-breaking approach preferable to defining a whole new header
field.
If it were important, it could be also its own header which could be
signed. It would then be up to the implementation whether it cared about it.
The less change to DKIM, the better IMO. I think too many people don't
give give enough credit to DKIM's foresight.
But I disagree it would be a breaking change even if were part of the
header. Implementation are suppose to ignore tags they don't understand.
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
