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

[Michael Thomas]

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