[ietf-dkim] testing Message Corpus & question for base spec

[Eric Allman]

>>> ...
>
>> Hector, are you saying that you intend to ignore MUSTs in the spec?
>
> You and I know as SMTP developers, that is not want I meant. :-)

Good, that's what I thought, but I wanted to be sure.

>> For example, the spec says that verifiers MUST ignore any tags that
>> they do not implement.  This can be viewed as a "relaxed" view, but
>> it is critical to allow future extensions.
>
> 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.

> ...
>
>> [I do see one error however; that statement should probably say
>> "MUST cause the header field to be completely ignored", which is
>> consistent with the wording in the rest of section 6.]
>
> 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.

> 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.

> So if one is to assume an assertion that correct usage improves
> legacy SMTP operations, it is also implies incorrect usage improves
> legacy SMTP operations as well. So treating the incorrect as if its
> an legacy system is where I'm afraid to say, we will see some major
> conflicting "mixed technology or policy" adoption issues in the
> future.  There is absolutely no doubt in my mind of that, hence
> basically the basic meaning of my original statement above.

And I'm quite sure I don't understand this.

eric