----- Original Message -----
From: "Eric Allman" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
>> Our implementation will be to reject all illegal DKIM
>> implementations, the form, the syntax, etc - regardless of any
>> relaxed DKIM specification or recommendation and especially of any
>> accreditation system saying otherwise including augmented fee-based
>> tokens.
> 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. :-)
> 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]
> If you're just talking about the x=-1019102801 issue (and things of
> that sort, i.e., malformed entries that the verifier does understand)
> then I'm in total agreement,
Correct, this and issues like it.
> [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".
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
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.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
[1] http://mipassoc.org/pipermail/ietf-dkim/2006q1/002168.html
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
