Ian Eiloart wrote: > On 23 May 2011, at 17:10, Hector Santos wrote: >
>> Rhetorically, why not? Put another way, why should a receiver >> tolerate failure, or better, why should DKIM itself - the technology >> - tolerate failure? Sounds like DKIM has some inner soul turmoils - a >> devil on one shoulder and angel on the other. > > Because there are known to be paths that break DKIM signatures. And >> because of this: http://www.apps.ietf.org/rfc/rfc4871.html#sec-6.3 That doesn't answer the question of why should it be tolerated. Why is the sender who's intention is to get the receiver to "trust him" tolerate the sender's ignorance of taking the wrong path is not helping him? This is what promotes a very serious problem of relaxation neglect or the "Crying Wolf" Syndrome. In other words, at what point is your signature ok? and ifs that acceptable why isn't the case 100% of the time? If thats not possible, when whats the difference? >> Rhetorically, its all for nothing, why bother looking at how to fix >> C14H hashing, talk about content formatting downgrades when failure is >> tolerated and per specification, deliberately ignored? > Because success has value, if you have a good reputation as a signer. And more usually than not, success can only be determine after you remove all the dirt from it. Can't talk about Pareto without having this being a very fundamental part of the thinking process. The fact is everyone does it - filters information before squeeze out the good. We are trying to ignore that fundamental concept for DKIM - doesn't work very well when its plagued with all sorts of error conditions. We are assuming that receivers will endure high volume abuse and overhead just to look for that limited golden needle in the hay stack of failure. Sorry, its an incorrect mentality that is often exhibited by mail blasters believing that every receiver/MDA will accept all mail with no questions asked. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html