[ietf-dkim] Re: Delegating responsibility: a make vs. buy designdecision

[Michael Thomas]

Damon wrote:

> What do we do when there is no signature and no d= domain to
> work with?
> This is sort of hazy in my mind.


That's an orthogonal question to your first assertion, and is the very 
subject that
SSP attempts to answer. My only point here is that dkim-base does give you
control over who signs in your domain's name. That's an already solved 
problem
that needn't be revisited by SSP.

       Mike

>
> Regards,
> Damon Sauer
>
>
> On 8/24/06, Michael Thomas <mike at mtcc.com> wrote:
>
>> Damon wrote:
>>
>> > On 8/24/06, Michael Thomas <mike at mtcc.com> wrote:
>> >
>> >> Damon wrote:
>> >>
>> >> > In my opinion, I am agreeing with you due to the lack of specific
>> >> > rules covering who can and cannot sign for me and when/how do I 
>> expect
>> >> > my policy to be enforced.
>> >>
>> >> This is factually incorrect. Dkim-base has very clear and unambiguous
>> >> rules
>> >> about who can sign for you. It would be helpful if you became 
>> acquainted
>> >> with
>> >> them.
>> >>
>> >>       Mike
>> >>
>> >
>> > Really? How so?
>> >
>> > Can I say that any email coming from xyz.example.com MUST be signed
>> > and if it isn't, toss it in the bit bucket even if my ISP signs it?
>> > Can I also go on to say, any email coming from abc.example.com may or
>> > may not be signed, but if it is, it needs to be MY signature.
>>
>>
>> It would be helpful if you didn't conflate too many things at once. I've
>> heard
>> you say on more than one occassion that you believe that DKIM doesn't 
>> have
>> the ability to constrain who signs on your behalf. That's incorrect.
>> That constraint
>> is provided by the requirement that the domain holder place a selector
>> into their
>> DNS for the signer's d= to hold true. The domain holder is thus in
>> control who
>> signs with their domain name.
>>
>> I'm not commenting on the rest, just that particular aspect.
>>
>>       Mike
>>
>> >
>> > EHLO xyz.example.com
>> > MAIL FROM: <return_bounce at xyz.example.com>
>> > RCPT TO: <my_customer at foo.com>
>> > From: <customer_service at example.com>
>> > and apply a policy that says this mail may or may not be signed.
>> >
>> > and also be able to say:
>> >
>> > EHLO abc.example.com
>> > MAIL FROM: <phishing_target at abc.example.com>
>> > RCPT TO: <eReciept_2_Customer at foo.com>
>> > From: <customer_service at example.com>
>> > and apply a policy that says this mail MUST be signed, if it isn't
>> > deliver it to null?
>> >
>> > and then say:
>> >
>> > EHLO myASP.test.com
>> > MAIL FROM: <my_advertising_company at myASP.test.com>
>> > RCPT TO: <opted_in at foo.com>
>> > From: <ad_dept at example.com>
>> > Reply-To: <backoffice at xyz.example.com>
>> > and apply a policy that says this mail MUST NOT be signed because I am
>> > outsourcing my advertising to someone I may trust but I have no
>> > control over them and I never ever want it confused with my
>> > abc.example.com email which is a huge phishing target?
>> >
>> > I don't know... this seems like a typical scenario to me..
>> > If it can't do this, or even come close, then Mike, you have not read
>> > a word I or Hector or others have said. I don't know if this should
>> > surprise me or not. Aren't you the person that is going to be writing
>> > this document?
>> >
>> > Regards,
>> > Damon Sauer
>>
>>
>>