Pragmatic issues with hash verifiers for email messages
Suppose that you have a 'sender stores message' email system, and that you protect yourself against the sender rewriting the message after it's initially sent by sending and verifying a secure hash of the message before you show the message to the user. To follow up a recent entry, here are the social and technical issues that I can see with this hash protection scheme.
First and largest, you have a social issue; users are going to react badly to 'this message is (minorly) corrupt so I will show you nothing at all'. Users want you to recover as much of their messages as you can and show them as much as you can, but doing so weakens or destroys your protection against on the fly targeted spam and phish, client exploits, and so on.
(Trying to sell this to users as message integrity checking is going to be even less successful, because I think users care even less about that.)
Next, this scheme is more complicated than it looks because you don't want to have a 'unitary' message hash, a simple single hash that covers the entire message. The problem with a single hash is that it requires you to download the entire message before you can verify the hash and show any of it to the user, which has very bad delays with large messages (or slow network connections or both). You can deal with this by hashing the message in sections, but this probably leaves you with more client attack surface exposed (especially if you make the mistake of making the sections be the various MIME parts).
Finally, this doesn't help your security issues if clients can be fingerprinted at all; it just forces the attacker to send two messages. You use the first message to find out the client fingerprint (and to verify that you have a live user), at which point you can craft your customized exploit message and send it to the user.
Sidebar: A sectional hash scheme
I think that the best sectional hash scheme would be one that simply breaks the message up into blocks of so many Kbytes each and hashes each block separately. You still need a single final hash for the message, but you can create this by hashing the list of section hashes. Then you embed the list of section hashes early in the message header, so that the client can verify pieces independently.