ietf-dkim
[Top] [All Lists]

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

2006-08-24 10:19:43
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.

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>