Murray S. Kucherawy wrote:
DKIM's purpose has been lost with the continued out of scope undefined
reputation modeling. A concern raised over and over again, Assessment |
Reputation - wink wink, same thing when it come to coding it. Word
smithing does not solve implementation issues.
I don't agree at all with these claims. An assessor module can make a
complete determination about what to do with a message using inputs from DKIM
and several other systems of its choosing (e.g. SPF) without consulting any
reputation system at all. Reputation is just another input to the assessor.
The total set and weighting of the assessor's inputs is both a matter of
software design and local policy.
They are certainly disjoint in my implementation.
There are a few points that seem to be lost in all of this:
1) People saying that d= is THE IDENTIFIER are overloading the value: d= a
routing
label to a particular DNS subtree. Whether it has anything to do with THE
IDENTIFIER is purely coincidental. The assumption that these two functions
are
identical is bogus. i= was supposed to be this stable value detached from
the
mechanical DNS routing function.
2) assessors are going to use what they find useful regardless of whether we
hurry
this draft out any faster or with any less review.
3) What's "useful" to assessors, d=, i=, or even x= is out of scope for the
DKIM wg.
The level of interoperability being pursued here much higher level than
anything we ever signed up for. We shouldn't force normative changes on
implementations
for functions outside of the scope of this working group.
4) #3 is doubly true since we don't even have any feedback, or an actual
problem being
reported in the field. when I asked about this at the SF meeting, I got a
lot of
bluster about "not revisiting first principles".
In conclusion, changing a spec absent actual problems in the field and to solve
problems
that are outside of charter seems dubious and dangerous. Doing so as an
emergency must-fix
update is even moreso: it tells the world that there's something dreadfully
wrong with
DKIM when that's far from the case.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html