I've written up this idea in a -04. Please take a look in https://datatracker.ietf.org/doc/html/draft-chuang-dkim2-sender-policy-04. I've also removed the "unaligned" flag proposal. Comments are very much welcome. -Wei
On Mon, Oct 5, 2026 at 1:00 AM Wei Chuang <[email protected]> wrote: > Thanks for pointing out this better approach. Upon reading the write-up, > it makes a lot of sense to me. I'll incorporate this concept into the next > revision of draft-chuang-dkim2-sender-policy. > -Wei > > On Wed, Sep 30, 2026 at 6:38 PM Bron Gondwana <brong= > [email protected]> wrote: > >> This came up in the interim call last week, and I promised to write this >> up. >> >> Consider this basic case: >> >> A = sender (supports DKIM2) >> B = intermediate which doesn't support DKIM2 (forwarder or mailing list) >> C = recipient (supports DKIM2) >> >> The proposal I disagreed with in the meeting, I would characterise as: >> >> "A looks up a DNS record, sees that B doesn't support DKIM2, writes rt= >> (blank >> recipient list) showing that the message was departing DKIM2 at this point, >> so C knows it went to somewhere that doesn't support DKIM2." >> >> I propose an alternative method. >> >> A does nothing special, just sends with rt=address@B. >> >> C receives the messages with rt=address@B still on the top (broken) >> DKIM2 header, and does a DNS lookup on B's domain, for e.g.. TXT _ >> dkim2.domain.com which says that this domain supports DKIM2. If that >> record is present, then the message MUST be a replay, because it doesn't >> have Domain B's signature. If it's not present, then it's just a naive >> domain, and the message needs to be treated as "not yet DKIM2 enabled". >> >> This has multiple advantages. >> >> 1) no forward lookup. Domain A doesn't need to care about whether domain >> B supports DKIM2, so there's no caching issues at this point. >> >> 2) destination data is present - C can still introspect the message to >> see what domain it was intended for, and where it came from on the way into >> C's MX, so it has more data to catch replays. >> >> 3) C has to do the analysis anyway, so it's already loading a ton of DNS >> records and can do some of this work asynchronously. >> >> Bron. >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC >> [email protected] >> >> _______________________________________________ >> 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]
