On Sun, Aug 23, 2026 at 9:27 PM Bron Gondwana <brong= [email protected]> wrote:
> I'm building slides to talk about DKIM2 in a webinar shortly, and thinking > about the crypto migration strategy. > > The first bits make sense: > > a) define a new key type > b) start signing with that in addition to the original algorithm > c) ... time passes, everybody can verify both types > d) you stop signing with the old algorithm > > The issue is, how do you know when it's safe to do "d"? If email silently > disappears, then people will be very wary of removing the old message, and > it's via multiple hops! So we really want some response DSN which > explicitly says "your DKIM2 signature looked reasonable but we don't > understand your algorithms". This would allow probing for issues with > removing an algorithm, and an ability to re-send with the old algorithm > added back in if the delivery failed. > > Including older algorithms as well isn't a security risk if we work from > the basis of "if it fails the strongest algorithm you know about it's > dodgy"; but we still want to remove excess DNS lookups and header junk over > time. > > 550 5.7.26 seems to be in pretty common usage for authentication-based rejections these days. https://datatracker.ietf.org/doc/html/rfc7372 -- Todd
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
