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
