On 8/30/2013 10:46 AM, Tony Hansen wrote:
The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well.
Hi Tony,
As a high potential implementator of this DKIM-REPUTE framework and
user of any future REPUTE products based on this DKIM-REPUTE
framework, I am somewhat disappointed to find not a single integration
consideration for the highly adopted SPF technology. Not a single
mentioning of the word or the integrated use of this highly adopted
mail transport augmented technology.
Any adopter of this framework or its products who are also SPF
implementors would need to know at the very least how current
protocols are affected and also can affect DKIM-REPUTE product
designers.
For example, DKIM-REPUTE product designers would need to consider SPF
reputons product models. Simple text as follows can resolve the
integration consideration with little SPF fanfare the draft obviously
tried to avoid:
REPUTE protocols based on this framework need to consider reputons
based on SMTP level filtering protocols such SPF [RFC4408],
IP based filtering [DNSRBL] or others.
The design consideration for operations may necessitate disabling
or relaxing SMTP level filters in order to enable filtering based
on this DKIM-REPUTE model.
I am seeing all this as an integrator of all mentioned mail
technologies; SPF, SENDERID/SUBMITTER, DKIM, ADSP, VBR. I welcome
this REPUTE framework. It should consider the existence of other
protocols and integrators need some design tips. Besides, for any
provider of a REPUTE service, they will benefit by these integrated
considerations as well.
Thanks
--
HLS