According to Richard Clayton <[email protected]>: >In message <[email protected]>, Bron >Gondwana <[email protected]> writes > >>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. > >That's not correct ... a backup MX which implements DKIM2 could well add >am i=2 DKIM2-Signature when forwarding the mail to the system that >actually handles the domain's email.
I don't see how. A backup MX is going to keep the same envelope addresses, so the existing signature is adequate. And since it's only relaying someone else's mail, it wouldn't have a signing key for the mail-from domain anyway. >>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. > >I don't think they should be modified, but if they were then the system >that actually handled them (see comment on #1 above) can undo changes How about if an intermediate systems wants to unwind the changes it made to avoid leaking info about its downstream recipients? I suppose it would create a new DSN since otherwise it'd leak recipient info anyway. R's, John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
