As I'm trying to implement DKIM2 DSNs, I am struck by very many things. 1) they're only ever i=1; because the next hop has to remove the details and create a new DSN.
2) they're only ever mf=<> 3) they aren't modifyable (only ever a single message-instance, with no recipe) 3a) and the signed Mesasge-Instance of the headers they include already hashes its own headers and can be verified. 4) their rt= must match the mf= of the top hop in the message; so can be unambigously derived. 5) their d= must match an rt= from the top hop of the message. *this is required still* So we could really just create a very simple singleton header: DKIM2-DSN: d=example.com; [email protected]; h=<mival> s=sel:alg:digest It doesn't have to have anything else. h= is the same value as the header value on the signed top message-instance, and then the digest is calculated over just this header with the digest left blank like usual. This makes it really clear that this is a DSN. It is only ever expected to be received by Bounce addresses, which will generally be dedicated processor addresses which never see anything else, so have different rules about what to accept anyway. 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]
