Re: [ietf-dkim] A proposal for restructuring SSP

Hector Santos wrote:
> Jim,
>
> If this proposal does not provide the fundamental standard idea of 
> checking for DKIM signing protocol consistency, then I don't think 
> this is solving the basis issue here.
> If we separate this fundamental SSP checking concept into a separate 
> but "out of scope" adjudicator "plug and play" idea, where one segment 
> uses this, another uses that, etc, then I think this will create an 
> exploitable situation of target hot spots.  This idea is one the Cat's 
> Meow in the Bad Actor World.  As long as they know there will be a 
> population of similar systems, but some are weaker than others, they 
> will continue to target everyone with the hope of hitting the weaker 
> ones.  That means a DOMAIN is vulnerable in varying DKIM systems.  I 
> don't think we want this to happen.
There is variability in any case, because some recipients will not 
deploy DKIM at all, and others will deploy it without SSP.  Others will 
deploy something SSP-like, even if SSP is very specific about how things 
should be done.
> Unless I am missing something,  this new separation and complexity 
> provide no world wide standardization for general case, widely adopted 
> expectations by the domain owners.  While is it conceivable the 
> domains might not care how a receiver reaches a decision, I believe 
> they will care that the end result is consistently the same across the 
> board, at least from a standards point of view.
Domain owners have no reason to expect their mail to be handled in any 
particular way.  They can state what they do, IMO they can state 
something about how they'd like their mail handled, but expectations...no.
> In my technical opinion,  this "Roll your own" filtering is going to 
> create hot spots of target systems and lower the confidence of DKIM 
> signers. We would be offering a "cross your fingers" approach with a 
> lack of confidence of how a receiver is expected to operate.
It's cross-your-fingers anyway, regardless of what the spec says.
> IMV, restrictive policies needs to be available for DKIM signers with 
> a expectation they will be honored across all SSP supportive systems 
> regardless of what add-on adjudicators are available.  We will not be 
> able to do this with a 3rd reputation service dependency.
I agree that we need to avoid a dependency on reputation services, but I 
do believe that reputation services, when available, are useful.  
Unfortunately the current draft is perceived as closing the door to the 
use of reputation and accreditation.  That was not my intent, at least.
-Jim

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html