Some non-breaking alternatives were discussed back when dkim replay attacks were the hot topic, (examples below) ultimately they were all band aids over the already known DKIM replay problem. Addressing that is the better long term fix.
https://www.ietf.org/archive/id/draft-bradshaw-envelope-validation-extension-dkim-01.html https://www.ietf.org/archive/id/draft-chuang-replay-resistant-arc-11.html On Mon, 6 Jan 2025, at 2:51 PM, Jim Fenton wrote: > I have recently received a number of these replays in my personal email, so I > think I understand the problem better. > > At the risk of getting too far into the weeds: > > The RCPT TO address isn’t available to many DKIM implementations, so > including it in the signature would be a breaking change. But DKIMbis could > define an additional signature field, similar to the b= field but including > the RCPT TO address. This would be ignored by current DKIM implementations > but could be used by DKIMbis implementations, with the additional benefit of > making it clear that it is the RCPT TO address, and not anything else, that > has changed. That would be a non-breaking change. > > Assuming the other goals of DKIMbis can be accomplished in similar ways, I > consider the non-breaking approach preferable to defining a whole new header > field. > > -Jim > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org > -- Marc Bradshaw marcbradshaw.net
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org