Arvel, I think your note is helpful in describing a set of desires. I am not sure that they fully match what DKIM can reasonably do, or least reasonably in its current form. To explore this, I'll ask some directed questions. I'm am hoping that others will also respond and will ask more questions:
> Here's the real problem I would like to solve: (Domain owner speaking > here): Recipients of messages from my domain currently have no method of > verifying whether the message conforms to my sending policy or not; nor can "Conforms to my sending policy" is powerful language, but also very abstract. It could easily imply many things that you probably do not mean. You could have sending policies that no message may be more than 17033 characters long or that none may contain the word "fooey" or that none may express unhappiness with the company lunch menu. I suspect you do not mean anything that broad or random. So, please try to list the (kinds of) "policies" you have in mind. If we work with a list of more specific policies, it will be vastly easier to evaluate DKIM's ability to satisfy your requirements. > (Email admin speaking here): I'd like to know whether a message I allow > into my network > is authorized by the domain owner in the FROM header and I'd like to know > whether the message contains the same content that the signing domain > intended. Why do you say RFC2822.From header field, specifically? Why do you care what, specific field contains the identity? I assume it is because you have some assumptions about how the validated identity will get used, so I'll ask you to consider those assumptions carefully. (Since you were part of the DKIM development effort, and since the issue has been discussed a couple of times on the mailsig list, you probably know where I am going with this question, but I'd like the discussion to unfold on its own, here.) > (Domain owner speaking here) DKIM provides the ability to distinguish > messages that conform with my local policy from those which do not. What you have stated, here, requires all of the DKIM SSP capabilities, in all their functional glory, including checking for policies that apply to unsigned messages. Is there any value in only dealing with (validating) signed messages? I ask because it seems likely that it would be good not to *require* checking unsigned messages. So, is there benefit in being able to do "nothing more" than validating some identity associated with the message? By way of seeking some efficiency, let me prime the pump: One study has shown that roughly 90% of the SPF-registered email is spam. That's really not a surprising statistic, absent any common assessment services. However, assuming that domain name-oriented assessment services become common, it seems reasonable to expect most signed mail to be from good actors rather than bad actors, since the bad actors will not see any benefit from doing signing. > It also > provides the ability to spotlight messages which have been altered. (Email > user speaking here): DKIM provides the ability to distinguish messages > which conform with the policy of the domain in the FROM header from those > which do not and it spotlights content change. Keeping the focus strictly on the additional point you raise here: DKIM ensures that that changes to the content that was present when the message was signed will be detected. > Here's how I think the "degree to which DKIM does not" solve the problem > plays out: DKIM does not prevent unauthorized use of any domain. DKIM does > not mandate or gaurantee how messages failing to conform to signing policy > will be handled. DKIM does not specify how (or even if) an indication of > forgery will be displayed to end users. DKIM is an input into local policy > decisions. But it is an important and solid input. good list. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
