...
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
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html