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