So just take it to its logical connclusion and
make it a pull protocol.  You get a note with a URL
and grab it at your leasure.  This is exactly what MMS
(cell phones that send/rcv pictures) do for reception.  The
message is kept on a server that other phones can pick it
up from.  The notification is sent to the phone via
a short message. Only if sent as email is it wrapped up
as a MIME email containing SMIL instructions, html
text, and jpg pictures.

We could do the same for email, sending a pick up URL,
and some 'secret' for decoding the message or logging
on or whatever.  If you broadcast (like mailing lists)
only the notification goes out.  AOL/Yahoo/etc mail
relays turn into web repositories.  Your mailbox server
can still yank some stuff automagicly if you like the
identity of the sender.  Use TLS on all connections,
if the web can do it, so can email.  Slowing things
down isn't that bad.

It changes the nature of spam somewhat, i.e., it would
become a short message containing nothing but a URL and
a subject.  Oops, that's what most of my spam already is
but at least it means they can't fire and forget, they have
to leave servers up.

And we're now reduced to a previously unsolved problem
with the same solutions.  If we're unwilling to accept
any solution that identifies the sender more than
trusting the From: we're still stuck with our Bayesian
filters etc.  If we're willing to put up with some
caller id, then we have to live with a public key
infrastructure, SPF, or something similar.  I personally
like public keys, just not the infrastructure.  If
someone has introduced themselves to me once and left
a public key, that's good enough for me.