----- Original Message -----
From: "Eric Allman" <eric+dkim(_at_)sendmail(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
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