Hi Murray,
I do not at all disagree with you. Your black box functional model is
one we have modeled as well.
However, IMO, in principle the framework must stand on its own for
general implementation and not depended on other separate or augmented
technologies to achieve some level of payoff. You can not assume
everyone will be using the same model, use SPF and anything else. e.g.
How will a remote system handle DKIM facsimile 3rd party spoofs of our
domain? What if it doesn't use SPF?
When POLICY was, for all intent and purpose became practically useless
in its current ADSP form, we lost 0% false positive fault handling of
domain signing expectations. White List Reputation became the principle
intent by many. New strategic business models are depending on it. I
have no problem with this add-valued service. I think its great and will
use it. However, I have a problem when its becomes a "Batteries
Required" concept in order to get any general payoff from DKIM,
especially when in the short term the reputation services will be very
limited and there is no standard protocol for this. Based on similar
3rd party protocol implementations experiences in the past, this can
create major support issues for customers and a major PR problem for us.
Look, it would of been nice if reputation was part of the charter so it
would not have become such confusing contentious issue, and Dave didn't
have to struggle with word smithing. The focus would of been developing
a reputation standard, models would of been developed and this project
would of been finished long ago.
Thanks
--
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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html