SSP, Third Party signatures


#1

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:

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


#2

No. I had started to, but what’s there now is incomplete and not adequately tested. I consider the SSP spec to be still pretty up-in-the-air, and I haven’t had any personal use for it, so it hasn’t been implemented further.

I don’t know what “normal” practice is with DKIM SSP; I’m not sure if anyone’s using it. I think what you describe is “correct”, in that it is how I interpret the spec too.


#3

Personally, I find the SSP policy described in the original DomainKeys spec (now RFC4870) much more useful. I’m considering implementing both DomainKeys-SSP and IETF-DKIM-SSP in the next version of Dkimproxy.


#4

Ok, got it. It’s kind of what I figured with SSP… many major domains we checked are all setting it up differently; I can’t imagine a verifier being able to pick a clear method to implement… Thanks… -C