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