On Jan 24, 2008, at 6:14 PM, Hector Santos wrote:
Its unfortunate that it has nothing to do with technical reasons but
the powers that are pushing reputations instead. The fact is, Dave's
never cared for SSP and its spelled out in his deployment guide, and
the other guy pushing his reputation service has no room for SSP
because SSP threatens that service business.
It is would be one thing to kill SSP for its technical merits, but
no one has SHOWN it is flawed system. NO one.
Purely based on self interest, and unfortunately we have a few cogs
who are masters of getting things KILLED if they want it to DIE.
It is a very SAD that not enough the technical developers are here
to mandate the direction.
It is really a sad. Too bad. Such a GOOD system is going thrown
away because of the self-interest reputations pushers.
Hector,
To avoid unwarranted disruption, SSP should be defined in a manner
that permits RFC 4871 to be used as expected when making SSP
assertions like "all" or "strict".
SSP will not impact reputation services. It is hard to imagine how
your conclusion was reached. Spammers have proven themselves able to
adjust to these types of mechanisms. Nevertheless, DKIM deployment is
important for many reasons well beyond reputation and self-published
policy enforcement.
As SSP is currently defined, normal use of RFC 4871 is not possible.
The self inflicted problems will diminish DKIM's deployment.
You have often described an ability to reject email based upon self
published policy as a significant benefit that will be provided by
DKIM. (The batteries.) However, the extent of this benefit may be
less than you have imagined. In addition, having DKIM deployed
provides significant benefits you are likely overlooking.
IMHO, the motivations behind the SSP discussion is to ensure this
policy extension does not become problematic for the more important
DKIM base deployment.
SSP will happen. The goal is to have SSP offer more benefits than
problems.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html