On Oct 3, 2009, at 2:02 PM, <[email protected]> <[email protected]> wrote:
> I would like cox.com<http://cox.com/> to sign on behalf of a > customer a.com<http://a.com/> to z.com<http://z.com/> so > a checker would lookup a.com<http://a.com/> and see that the > cox.com<http://cox.com/ > > is the > authorized signer on behalf of z.com<http://z.com/> If a receiver receives an email with a selector of foo.cox and a signing domain of z.com then the existence of a DNS record like... cox._domainkey.z.com NS dkim.cox.com ... tells the recipient that cox.com is one of the authorized signers for z.com, and that this particular message was signed by cox.com on behalf of z.com. If you wanted to make it more explicit that the signing was being done by Cox there are several ways you could do it - my first thought would be to add Signed-on-behalf-of: header that was covered by the DKIM signature. Cheers, Steve > On Oct 3, 2009, at 12:16 PM, Steve Atkins wrote: > > > On Oct 2, 2009, at 7:56 PM, <[email protected]<mailto:[email protected] > >> <[email protected]<mailto:[email protected]>> > wrote: > > while I have enjoyed participasting in this WG I would like to > discuss the ability of an ISP to sign on behalf of an entity that we > provide all services for. > > You can do that today, in several ways. > > This has generated disinclination in the > past but as a provider who has an expressed interest in providing 3rd > party signatures we need a set of rules/ideas that states I signed > this message on the behalf of > foo.examplemy.client.com<http://foo.examplemy.client.com > >. Otherwise DKIM > is interesting as an artifact but I ill will be signing soon my > residential emails but have no interest in signing my commercial folks > unless there is a benefit > > If you have control over the DNS for > foo.examplemy.client.com<http://foo.examplemy.client.com > > then > you can sign mail with that token. If you don't have control over > it, but the owner of that wants you to sign on their behalf then > they can give you a private key for signing, or delegate a subtree > inside that space ( cox._domainkey.foo.examplemyclient.com) > to you, so you can handle the key management. > > And you can sign the message twice, once as cox.com<http://cox.com>, > once > as the customer domain, pretty cheaply. > > Can you expand on what you'd like to be able to do that's different > from all those? > > Cheers, > Steve > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
