To be fair, this is probably more a question about DKIM in general than DKIM Proxy, but I’d like to know DKIM’s specific behavior relating to these issues as well… we’re using it happily but some questions have come up:
- Does DKIM Proxy fully implement the current version of SSP as described at
dkim.org/specs/draft-allman-dkim-ssp-01.txt
?
Our company works similar to the “resender” style of mailing list (using the term from the SSP spec), where we change the content (and break existing signatures) but we don’t want to re-write the From. SSP spec tells us to add a Sender field and re-sign with an “i=…” that matches that domain, but it’s unclear what that would get us. If the domain referred to by the body-From has an SSP of “o=!”, my understanding is that adding the Sender field will get us nothing, as it’s basically still a third-party signature and the From domain SSP forbids those (this is unfortunately unclear in the SSP spec, any corrective insight is welcome.)
1 - if DKIM Proxy finds a broken first-party signature and a valid third-party signature using a Sender field domain and the matching “i=…” domain from the signature, but the SSP of the From domain is “o=!”, will DKIM Proxy indicate a DKIM “fail”? And is this normal/correct practice with verifiers?
2 - if DKIM Proxy finds a broken first-party signature and a valid third-party signature using a Sender field domain and the matching “i=…” domain from the signature, and the SSP of the From domain is nonexistent or “o=~” or “o=-”, will it indicate a DKIM “pass”? And is this normal/correct practice with verifiers?
3 - if DKIM Proxy finds a broken first-party signature and a valid third-party signature (by definition mismatching the From domain), but no Sender field and an SSP of the From domain of non-existent or “o=~” or “o=-”, I assume that it will pass? And is this normal/correct practice?
If I’m correct with my guesses above for 2 and 3, then what is the semantic/programmatic difference between 2 and 3? In other words, as re-senders, what does adding the Sender field gain for us, at least insofar as dealing with valid third party signatures permitted by SSP? Is it simply some more (potential) credibility for signing a visible field, or does it actually override something in a more dramatic way?
4 - Given question 3, but with a pre-existing Sender field that doesn’t match our re-signing i= domain, this is treated the same as not having a Sender field at all?
Thanks for your time!
-C