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
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim