Charles Lindsey wrote: > On Wed, 25 May 2011 01:33:00 +0100, Dave CROCKER <d...@dcrocker.net> wrote: > >> To make a canonicalization algorithm that is more robust -- such as >> having it based on canonical forms of data, independent of encoding -- >> makes some sense. Trying to create the ability to "reverse" changes >> strikes me as far to complex and fragile to be reasonable.
> Sure. But this thread is simply trying to see whether some minimal > assistance from the signer might be useful for helping any geek who was > mad enough to try reversing the changes. For sure there will such exist > geeks out there somewhere - but I don't expect such reversing to become > normal standard practice. Sure, but its not just being a geek but simply understanding the environment and problems that exist. I think most people will want to know the "Why" this or that happens when you do complex work with a presumption and natural human expectation that the yields will be correct side of things. Most good and experienced engineers (or any discipline in general) have insights into potential problems without having to see it really happen. If you can predict something, it can often serve as a preemption solution. Good Practical Engineers tend to look at the feasibility aspects of a solution. The ideas I proposed (STRIP, "et=" encoding tag) are ones I believe MAY be a feasible solution for a few of these inadvertent incorrect body hash cases. I am 100% aware that it may not be necessary or feasible in the overall practical sense. But its not just thinking out of the box today, this was a long time issue (since 2005) and in my view, it was already a bad idea to try to make DKIM work within LIST environments that could only work in a fundamentally changed framework highlighting all the legacy hiccups of the system. Levine's answer is to forget what you receive, just resign on the way out. That is not unreasonable, but its not a feasible and secured solution neither, and ultimately, it also comes with a change requirement. At the end of the day, no matter what, people software (Old and New) need to change to make DKIM work better. -- 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
