I must've missed this in my earlier readings of RFC 6376, but 2.1 and 2.2 actually do explicitly list MUAs as potential signers and verifiers. So, I guess for suggestion 1 of my initial email, the request would just be to keep similar language in the draft for DKIM 2.
I couldn't find any discussion in that RFC of why it's not advisable for MUAs to perform verification (but I was just searching for the term "MUA", and didn't actually re-read everything in depth, so I may have missed it). If anyone could shed some light on this, it would be much appreciated. In practice, from working on a MUA that does DKIM verification, the main issues we've faced are: 1. Needing to download the entire message to verify any part of the body. Often times, we only want to download the HTML part for a multipart/alternative, and especially for messages with large attachments, we don't want to download those attachments without explicit user action. This means we cannot verify the MIME parts that we _have_ downloaded. 2. Some mailbox providers modify the message after verifying DKIM. These are then impossible to verify in the MUA. 3. The key is no longer available. I believe DKIM 2's diff algebra should be sufficient to solve issue 2. I think this is the biggest "what's changed" about DKIM 2 (in regards to MUAs as verifiers). Issue 3 has really only been a problem for very old messages, for which DKIM verification is typically not as important anyway. Most senders seem not to rotate keys all that often (order of months or years), and when they do, many will leave old keys around. This could be fully solved by sending the keys in the message, but I think just some language in the RFC to encourage senders to leave keys around for a period of at least few months is enough to mitigate this for most practical use cases. Issue 1 is, I think, the biggest missing piece. And I think the per-MIME-part hash would effectively solve it. - Phillip > On Aug 20, 2025, at 6:52 AM, Murray S. Kucherawy <[email protected]> wrote: > > On Tue, Aug 19, 2025 at 11:36 AM Phillip Tao <[email protected] > <mailto:[email protected]>> wrote: >> Apple clients also verify DKIM 1 today. I didn't know there were other >> parties doing the same, but it makes sense, for I imagine the same reasons >> that Apple wants to do it. >> >> This is all the more reason, then, for these changes. > > I have to find the specific sections, but I recall RFC 6376 talking about why > client verification of signatures is not a great idea. Keys rotate, for > example, so long-term signature validation is not guaranteed to be reliable. > People who were around in the RFC 4871 days may remember other reasons why > the general position was that this wasn't something worth pursuing. > > What's changed? > > -MSK
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
