"Conforms to my sending policy" is powerful language, but
also very abstract. It could easily imply many things that you
probably do not mean.
I suspect you do not mean anything that broad or random.
Absolute right Dave, sorry.
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.
I'll try. Abstractly, I seek a mechanism which will allow message verifying
agents to determine whether the existance or absense of a particular message
property should or should not be expected. In the context of DKIM, that
message property is a valid signature header. In the context of SPF, it is
a proper delivery path, etc. The "holy grail" would be a single policy
mechanism specified somewhere once which is general-purpose (way out of
scope). It's hard to get more specific without diving into the details of
DKIM itself. With DKIM being a signature based solution, I seek a mechanism
that allows message verifying agents to understand whether the existance or
absense of a signature in a message should be expected. So, the kinds of
policies I believe to be critical here are (a) whether the verifying agent
should expect to find a valid signature (b) whether the verifying agent
should not expect to find a valid signature.
(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?
Very, very good question. This is all tied up in the ambiguity associated
with trying to determine "who sent me this message". If one must determine
the signing policy of the "sending domain" one must make the decision - who
is the "sending domain"? To determine that, an examination of the relevant
sub-set of message headers is the only route to take. Among those headers,
there is one which carries a virtue that none of the others possess - the
RFC2822.From - alone amongst all other identity headers, is prominantly
displayed to naive users. Regardless of the truth of the matter, end-users
today have been trained by their MUA's to view the RFC2822.From as the
definitive "sending" entity. So, I pick the RFC2822.From because (for right
or wrong) it has this extra property which the other identity headers do not
possess. Therefore, all else being equal, it seems the logical decision.
Is there any value in only dealing with (validating) signed
messages?
Yes, there is a non-ZERO value here because the signing identity can be used
as a policy input.
I ask because it seems likely that it would be good
not to *require* checking unsigned messages.
This would be a very serious mistake in my view. By removing the
requirement to check unsigned messages, DKIM isn't DKIM anymore. It would
be like SPF without the "SP" - it would just be "F". There would be no
longer any pretense of DKIM as an alternative to Sender-ID/SPF and it would
insure the continued development and deployment of what it is designed
ultimately to replace - DK and IIM.
So, is there benefit in being able to do "nothing more"
than validating some identity associated with the message?
DKIM without an SSP component would no longer be the cross-product of it's
parent specifications. So, although there is a non-ZERO value in a system
which merely validates signatures - this value should not be construed as
justification enough to cripple the SSP part of DKIM. It's like saying,
yes, 50 cent pieces have value - so lets toss away the other half of that
dollar.
--
Arvel
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim