Hi Jon, On Mon, Nov 21, 2022 at 4:07 PM Jon Callas <[email protected]> wrote:
> As another original author, it was hard for me to understand what this was > talking about when the discussion first came up. I even considered replying > to this thread asking something like, "isn't replay just sending the > message again?" before I understood. > > I really like the guidance that an MDA SHOULD remove a DKIM signature. I > have memories that we discussed just that even at the time, for a number of > reasons. > > This is a fine solution to this problem. The replay issue just goes away > if the header lines are removed. > > It also addresses my long-standing complaint that DKIM is not supposed to > be a tracking and authenticity mechanism. Moreover, this is a much better > solution to my complaint than anything anyone has come up with, including > my eccentric foot-stamping about keys. > > Lastly, it also addresses the inevitable issue that we aren't thinking of > today, but five years from now we're going to discover. > > Let's just do it. Let's advise to people that they remove the signature in > their MDA. We don't even need an RFC for it (though we could do one), we > just need some reasonable implementation. > Just for the sake of being complete, we should probably come up with something to say about this, which is in RFC 4686, the DKIM "threats" document: DKIM operates entirely on the content (body and selected header fields) of the message, as defined in RFC 2822 <https://datatracker.ietf.org/doc/html/rfc2822> [RFC2822 <https://datatracker.ietf.org/doc/html/rfc2822>]. The transmission of messages via SMTP, defined in RFC 2821 <https://datatracker.ietf.org/doc/html/rfc2821> [RFC2821 <https://datatracker.ietf.org/doc/html/rfc2821>], and such elements as the envelope-from and envelope-to addresses and the HELO domain are not relevant to DKIM verification. This is an intentional decision made to allow verification of messages via protocols other than SMTP, such as POP [RFC1939 <https://datatracker.ietf.org/doc/html/rfc1939>] and IMAP [RFC3501 <https://datatracker.ietf.org/doc/html/rfc3501>] which an MUA acting as a verifier might use. We actually seemed to like the idea, at least back then, that the signature survives delivery so that it can be validated at any point later. In terms of mechanism, if this is the consensus position, I imagine a small "Updates" document could be produced to formally amend/extend the advice present in RFC 6376. -MSK
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
