When all you have is a hammer, everything looks like a distributed decision problem...
But seriously, this would not scale. Using a central block chain as you suggest means that every node in the system receives a copy of every email. It's also trivial to DOS - just send tons of multi-megabyte messages to nonexistent receivers. The messages hang around in the block chain forever and the entire system dies.
Email is not a decision problem (unlike bitcoin, or potentially a DNS replacement). It is a delivery problem, and is local in nature. There are no global decisions to be made, unlike in bitcoin - there's just a sender and a receiver, and they need to find each other to exchange the message. Once they do, nobody else needs to know about any of this.
When you view things in that light, SMTP is a reasonable protocol for the job. It just lacks sender authentication, hence the spam problem, and is cleartext-by-default. It also relies on the DNS protocol for endpoint location, and is a 7bit protocol (making attachments needlessly inefficient). All of these things can be fixed without any kind of radical change to the protocol; just tack on a DHT (keyed on recipient public key hash?) for endpoint location, mandate 8bit-cleanliness, authenticate the sender somehow (this is a HUGE problem and one your hash chain system also fails to address), and mandate encryption.
If you want to also mask IP addresses as well, just toss in a standard mixnet, such as tor or I2P. This gives you endpoint location for free, as well.
As for sender authentication, mandating message signatures is an easy first step, but authenticating the sender key is a hard problem (key management always is). You need to have some kind of vetting process or spammers will just mint millions of keys; but at the same time people like to receive messages from people they haven't exchanged keys with. This here is the fundamental problem with spam, and not one that any purely technical solution can fix.