ietf-dkim
[Top] [All Lists]

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

2006-08-24 10:53:23
What do we do when there is no signature and no d= domain to
work with?
This is sort of hazy in my mind.

Regards,
Damon Sauer


On 8/24/06, Michael Thomas <mike(_at_)mtcc(_dot_)com> wrote:
Damon wrote:

> On 8/24/06, Michael Thomas <mike(_at_)mtcc(_dot_)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(_dot_)example(_dot_)com>
> RCPT TO: <my_customer(_at_)foo(_dot_)com>
> From: <customer_service(_at_)example(_dot_)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(_dot_)example(_dot_)com>
> RCPT TO: <eReciept_2_Customer(_at_)foo(_dot_)com>
> From: <customer_service(_at_)example(_dot_)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(_dot_)test(_dot_)com>
> RCPT TO: <opted_in(_at_)foo(_dot_)com>
> From: <ad_dept(_at_)example(_dot_)com>
> Reply-To: <backoffice(_at_)xyz(_dot_)example(_dot_)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



_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>