Hallam-Baker, Phillip wrote:
The discussion here is about a REQUIREMENT. How the requirement is
achieved is not the issue at this point.
Of course since everyone seems to skip straight to the implementation,
That is what happens in a mixed discipline environment. :-) Plus there
is 100s if not 1000s of man-years experience here - foreseeing
implementing is not to be unexpected with all the knowledge here. I for
one see implementation issues with some of the proposal provisions so
you expect it to be mentioned.
The policy record does not directly reference the signing algorithm, all
that information remains in the key record. All that you get in the
policy record is a statement 'there is always a key record that has a
selector that looks like this' or 'there is always one like this and one
like that'.
I don't understand why. The ultimate selector is the one in the
DKIM-Signature heeader.
Lets hold off on the implementation though as Steve will no doubt remind
us is the basic idea at this point. This means that we only discuss
whether it is a valid requirement. The cost of implementation is not the
issue at this point.
Of course, implementation doesn't mean "coding." It is about the
process model. You must have some insight into this to have an
understanding of the problem and possible solution.
The ideal situation is:
"Having all the information one needs to make a decision."
The total process DATA pool is:
- DKIM Message
- KEY information
- SSP information
or
VALIDATION = VERIFY(MESSAGE, KEY, SSP)
or as some will want that to be:
VALIDATION = VERIFY(MESSAGE, KEY[, SSP])
with an optional SSP.
So the question is, can an OPTIONAL SSP or a DELAYED SSP implementation
be used to address all the concerns?
From my standpoint you have these design points:
- Is mail expected is this a valid condition?
- The mail is signed, is this a valid condition?
- The mail is unsigned, is this a valid condition?
For that all you need is
a) SSP record, or
b) for no mail or no signatures, all you need is no KEY record.
So as you can see, the decisions dictates how the process modeling will
be done.
Beyond that, we are trying to KLUDGE a solution into "Signature Failure
Fixing" and to me, that will be exploited.
Maybe it will help if we define what kind of failures are worth "fixing."
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html