--On February 15, 2006 6:36:40 PM -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
...
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.
Interesting idea, but I think it's probably best held off until the
document is essentially done so we don't get things out of sync.
...
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.
OK, I made the last paragraph of Section 6 (i.e., right before 6.1)
read
Verifiers MUST apply the following steps in the order listed.
In many cases these steps say that a "DKIM-Signature" header
field should be ignored, e.g., because it is malformed or
because the signature verification failed. In such cases
verifiers SHOULD proceed to the next signature, and treat the
message as verified if any signature succeeded, ignoring the
bad signatures. The order in which signatures are tried is a
matter of local policy for the verifier and is not defined
here. A verifier MAY treat a message that has one or more
bad signatures and no good signatures differently from a
message with no signature at all; again, this is local policy
and is beyond the scope of this document.
I hope this captures what we are both trying to say. There is one
possibly controversial point here: that a verifier MAY treat a
message with bad signatures differently than those with no
signatures. I really view this as out of scope, since that's a local
policy issue, so perhaps it should be deleted entirely.
...
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 think we're agreeing, although I think your last "if" block has
some conditions reversed (or I'm getting confused over variable
names). It seems to say that I have a good signature but something
is wrong and my local policy allows this then I should reject the
message.
My initial draft actually included something like this but I pulled
it out for simplicity; mine just included a "something failed"
boolean that got set in the obvious places.
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?
Dream on, although I'm surprised the number is so high --- perhaps if
you include spam engines. But here is where I think we have a
disagreement; I am concerned, at least in the short run, about
signatures that get trashed for innocuous reasons, such as mailing
list exploders. I don't think such messages should be rejected.
This is, of course, local policy.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html