Thanks for the background John. - Phillip
> On Aug 20, 2025, at 11:34 AM, John R. Levine <[email protected]> wrote: > > On Wed, 20 Aug 2025, Murray S. Kucherawy wrote: >> 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. > > Client signing was clearly out of the question since there's no reasonable > way to manage the signing keys, Agreed. > so if they're not going to sign it makes sense for them not to verify either. I don't think this necessarily follows from the preceding statement. > > Also, by that point we had realized that spam filtering works a lot better in > the MTA than in the MUA. It can look at lots of mail at once, not just mail > to one user, and have shared dynamically updated criteria. I generally agree that the MTA can probably make a lot more use of DKIM than the MUA can. Spam filtering in particular definitely works better in general when done by the MTA. However, we've found that there are other policy decisions we want to apply to messages based on DKIM/DMARC status. For technical, security, and liability reasons, simply getting the DKIM/DMARC status from the Authentication-Results is not sufficient for this. > You can still have per-user criteria, but they're applied in the MTA so, > among other things, all of the user's MUAs see the same results. The flip side of this is that one MUA may want to apply the same per-user criteria to multiple accounts hosted by multiple mailbox providers. > > If you want to check a DKIM signature in your MUA you can, but I don't think > it's useful in practice. I have a little DKIM validator script I can tell > Alpine to run messages through but I only use it for debugging. > > R's, > John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
