On Wed, Aug 20, 2025 at 12:28 PM Phillip Tao
<[email protected]> wrote:
>
> 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.

The idea of per-MIME-part hash makes me nervous; I am not a fan
because I feel that it could enable a scenario where somebody will
decide whether or not they trust a message based on verification of
hashes for only certain parts of the message. In my mind this is about
trust verification for the entire message, not just bits of it. I want
that trust measurement to be 0 or 100% for the whole message, not,
well we only checked mime part X and that's fine, so we'll assume that
the whole message must be safe.

I'm definitely curious to hear how others feel about that.

I suppose a potential alternative might be that if you mange both the
MTA and MUA, you can leverage the MTA's checks, and give the MUA some
way to obtain that result data from the MTA. When you don't own both
the MTA and MUA, I grant that gets a lot more difficult, and maybe
impossible.

Cheers,
Al Iverson


-- 

Al Iverson | Industry Research and Community Engagement Lead
Email: [email protected]
Phone: (312) 725-0130 (Chicago)
Calendar: https://xnnd.com/cal

_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to