Charles Lindsey wrote:
On Wed, 25 May 2011 01:33:00 +0100, Dave CROCKER
<dhc(_at_)dcrocker(_dot_)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