----- Original Message -----
From: "Eric Allman" <eric+dkim(_at_)sendmail(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Correct. Standard stuff. [Small Point, might help to highlight if
not there already, a minimum requirement section]
It seems pretty clear to me, but then I know the document perhaps too
well to see it objectively. I think I quoted the text previously.
Just a suggestion for a new section:
1.5 Basic Requirements Summary
Then seach for all "requir" or "MUST" in the document, consolidate it and
try to summary it in this basic section in outline format, maybe with each
having a reference to the specific more detail section as well.
I think there needs to be a clarification in the on-going and
repeated usage of saying "completely ignored".
Yes, I agree. The kind of algorithm I have in mind is something like:
read_all_signatures();
sort_signatures_into_preferred_order();
good_sig = false;
foreach sig in signatures
if (malformed || missing key || expired key || ...)
continue;
if (good_sig = check_sig_ok(sig))
break; // from foreach
if (good_sig)
process the message with signature
else
process the message as though there were no signature
The problem is turning this into English.
[FLAWED TECHNOLOGY!]
If one or more signatures are valid, then process the message as
a good signature. This includes if there exist one or more
bad signature. As long as there is 1 good signature, process
the message as a good signature.
In short, without going too deep with this, transactions based on
the "very limited purpose of DKIM, for assigning transit
accountability, [1]" makes the assertion of:
legacy transit info != new transit and CORRECT accountability
info
But this also implies the assertion:
legacy transit info != new transit and INCORRECT
accountability info
I'm not sure I'm understanding this.
ok, this is what I meant :-)
I would change your pseudo code or implement it as such:
total_sigs = read_all_signatures(); // v1.1 HLS
sort_signatures_into_preferred_order();
good_sig = false;
something_wrong[] = {nope}; // v1.1 HLS
foreach sig in signatures {
//-------------------------
// v1.1 HLS
something_wrong[sig] = malformed || missing key || expired key ||
...
if (something_wrong[sig])
continue;
//-------------------------
if (good_sig = check_sig_ok(sig))
break; // from foreach
}
// v1.1 HLS
not_quite_kosher = false;
foreach wrong in something_wrong
if (wrong != nope) {
not_quite_kosher = true;
break;
}
}
//
if (good_sig)
if not_quite_kosher and LocalPolicy_AcceptWrong then // v1.1 HLS
reject(something_wrong[]); // v1.1 HLS
else
process the message with signature(something_wrong[]);
else
if (total_sigs and LocalPolicy_AcceptWrong)
reject(something_wrong[]); // v1.1 HLS
else
process the message as though there were no signature
In short, if there is any attempt to use a new set of DKIM information, and
its incorrect, then it should it a LOCAL POLICY DRIVEN as to how this will
handled. It is not like there is a "no signature" because that isn't true.
There is a signature, just incorrect and this information is vitality
important.
I can not under good conscious believe there would be such a think as a GOOD
message when there is something wrong with it.
Grant it, I think your code assumes and attempts to desensitize the "List
Server" issues. But it doesn't take into account the high potential abuse
and extreme overhead that will be placed across the network on so many
systems. Over 80% of SMTP transactions are not SMTP compliant
(intentionally). Is DKIM the exception to this high probability?
Note: the Reject() function is just a stub. Whether it is actually rejected,
put aside or flagged, is implementation dependent and more than likely local
policy defined.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html