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]
