Hi, I am merely an interested enthusiast without any long-standing reputation in this community, so take my opinion for what it is worth - but I wholeheartedly agree with Vittorio's point here.
There is another aspect that makes the assumption that every forwarding node can simply be upgraded particularly problematic. In Germany, as an example, there are a large number of small registered associations - sports clubs, choirs, cultural associations, and many others - which play an important role in society and are often run largely by volunteers. Many of them have role-based addresses such as "[email protected]" or "[email protected]". These addresses are deliberately independent of the person holding the position and can naturally be forwarded to one or several recipients' existing private mailboxes. This avoids requiring a shared mailbox, credentials, or access-control model, and makes changing office holders straightforward. Replacing this with a shared IMAP mailbox introduces additional identity and access-management requirements. Plus, simply telling the recipient to "use IMAP instead" is not a realistic alternative for users who have been using the same, long-established mail setup for years and might not even be computer literate enough to update their configuration. The other side of the equation is the forwarding server. Very often, this is not operated by a large provider with a dedicated engineering team, but by a member of the association in their spare time. Regularly applying software/security updates is simple, but implementing a new protocol with consequences for the deliverability of forwarded mail is quite another. I am using German associations merely as a concrete example. The underlying issue is broader: there is a very large installed base of independently operated, small mail systems, and there is no realistic mechanism by which all of them can be upgraded in lockstep. This is why I think Vittorio's distinction between the destination and the journey is so important. During the transition, a perfectly valid message can pass through a non-DKIM2 forwarding node and arrive at a DKIM2-aware receiver with a broken chain, through no fault of the sender. If the only acceptable outcome is to reject that message, then interoperability during the "transition" effectively depends on every forwarding node on the path having already migrated. That is the opposite of a migration strategy, it's a "my way or the highway" route and a much stronger requirement than to just deploying DKIM2 on the endpoints. So I strongly support designing the protocol in a way that non-participating legacy hops can be encountered during the **transition** without making an otherwise valid message undeliverable. Cheers Alex ---------------------------------------- Von: Richard Clayton <[email protected]> An: [email protected] Datum: 28.08.2026 17:19:18 Betreff: [Ietf-dkim] Re: Non-participating nodes in the chain: an interoperability gap, not a local-policy question > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected]>, Vittorio > <[email protected]> writes > >> Whatever the adoption rate, there will be a long period in which DKIM2 and >> non- >> DKIM2 nodes share delivery paths: > > No ... if the adoption rate is high then it will not be a long period ! > > If you currently sign with DKIM1 then signing with DKIM2 merely means > that you need to update your software (and perhaps change a config file) > > At present you need to update your software most months to deal with > security issues (and Claude and his friends are rapidly changing months > to weeks). That is updating is not an unusual thing to do. > > Note that we have carefully arranged that the hard bit -- changing your > DNS records -- is not required to update to DKIM2. > >> DMARC's "adopt it", as I have noted before, was a single DNS >> record, required nothing of intermediaries, and even so took years > > Though will you note that the take-up rate for DMARC increased markedly > when major mailbox providers decided that they would not tolerate large > flows of unauthenticated email any more. > > Their tolerance of DKIM-replay is currently wearing very thin -- so you > might well see significant encouragement from them for senders to adopt > a system that prevents it. > > - -- > richard @ highwayman . com "Nothing seems the same > Still you never see the change from day to day > And no-one notices the customs slip away" > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBapGFfWHfC/FfW545EQJ6OwCdEIB15WvYzRvspmapPR5S6/mjqBgAoJHR > CKxfTYhUVuJXCe4/C9fJluqP > =AYyF > -----END PGP SIGNATURE----- > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
