I should have mentioned that the example is a problematic scenario where DKIM2 and in particular the ideas in draft-gondwana-dkim2-modification-alegbra could make this scenario tractable for authentication. The details of the modification algebra are however out of scope for this particular example. It does however show the changes to header hashing through forwarding.
On Wed, Mar 26, 2025 at 9:08 AM Alessandro Vesely <[email protected]> wrote: > On Wed 26/Mar/2025 09:23:19 +0100 Wei Chuang wrote: > > FORWARDED MESSAGE: From header rewritten and Delivered-to added > > DKIM2-Signature: i=2; h=list-unsubscribe-post:delivered-to > > From: [email protected] > > > Wasn't the purpose to keep the author's real address in the From: field? > > > > Delivered-to: [email protected] > > DKIM2-Signature: i=1; h=list-unsubscribe-post > > To: [email protected] > > List-Unsubscribe-Post: > > > Hmm... Delivered-To: doesn't seem to be a significant element. RFC 9228 > says: > > It appears that all uses include a string in the form of an email > address, although at least one example has leading text that is a > comment about the address. In some cases, the string appears to be > the email transport destination address, such as the address used in > SMTP's "RCPT TO" command. In other cases, it appears to be the > result of some internal mapping at the receiving system, although > tending to be a variant of the transport address. > > > It's meant to be illustrative of some header updates during forwarding where someone e.g. a mailing list may care to sign for an extra header. (We wouldn't) -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
