On 8/20/2025 6:52 AM, 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.
I think this is the text you are interested in:
6 <https://www.rfc-editor.org/rfc/rfc6376#section-6>. Verifier Actions Since a Signer MAY remove or revoke a public key at any time, it is advised that verification occur in a timely manner. In many configurations, the most timely place is during acceptance by the border MTA or shortly thereafter. In particular, deferring verification until the message is accessed by the end user is discouraged.
Since DKIM is meant as a transit-related tool, and since there are no guarantees or expectations that keys will have long-term validity, the important language here is "timely manner".
Since a recipient's user agent might attempt validation long after delivery, the basic concern about /relying/ on recipient-based validation -- rather than, receiving-platform-based -- has merit.
However, to the extent this language leads to thinking that it is wrong or bad or somehow problematic to perform recipient-based validation, then the language could use beefing up. DKIM is designed to permit all of the work to be done by user agents and either end; implementation in the handling software, rather than user software, is an operational expedient, not an architectural necessity.
Consider: * A key needs to be valid for at least a few days, since a message might take several days to get delivered, what with various possible sources of delay. * But most messages are delivered very quickly and a recipient's user agent might be able to perform validation within seconds or minutes of that delivery. Well within the window d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net bluesky: @dcrocker.bsky.social mast: @[email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
