[grey-area]

But I still haven't been able to find a compelling reason that email itself is fundamentally broken in a way that requires a new system altogether.

I'd love to use something very much like email which had a few things like this:

Verified identity

Public key encryption as standard (of content at least, possibly of most headers too)

TLS everywhere

UTF-8 everywhere

Metadata for social presence so that twitter/fb/github/intranet profiles could be referenced in mails and used for things like identity (see verified identity above)

Standardised globally unique message ids (uris perhaps)?

Attachments uploaded to a server by the sender instead of clogging up mailboxes, not fetched unless required

Maybe even mail uploaded to a server and not sent across the wire unless actually requested - why do we need to send messages when I might be able to infer from metadata that I don't want to read it 50% of the time? An API for email clients which pull data as they wish would be nice, instead of the current broadcast all the data model. This plus identity would make it easier to block spam.

HTML with inline CSS for styling (clients could strip to plain text as required, not send the message twice) - no JS for obvious reasons. We pretty much have this already, but it'd be nice if it were just the standard.

Email is a great tool, but it really is showing its age - it was defined in a different age where there was trust by default of network users and servers, and it's been hugely exploited as a result. If it were proposed now it would never be adopted. You could shoehorn a few of the above points into client changes, but some things would be easier with a new protocol.

[derefr]

> Maybe even mail uploaded to a server and not sent across the wire unless actually requested - why do we need to send messages when I might be able to infer from metadata that I don't want to read it 50% of the time?

If you go there, you're basically talking about something that's more like blogs with RSS feeds, rather than email. To me, half the point of email is that it is "pushed": this allows to send messages to people you don't already have pre-existing relationships with, simply by finding out their contact details.

[grey-area]

You could push the fact there is a message at date n from x with subject y to the recipient servers without wasting bandwidth on the message itself along with attachments before you know it will be read. This would also have other effects (possibly delete/modify after send, invert control from the recipient to the sender etc), so it certainly would change the way email is used - probably not everyone would agree with this particular point.

[derefr]

I would think that if you're already going to do the SMTP transaction, the average (plaintext) email message body is small enough to slide into the same packet as the end of the transaction headers. It's the same as keeping the data of small files inside their directory-entry structures on disk.

On the other hand, it would indeed be interesting if email was simply a "unicast presence notification" channel to allow accounts to publish knowledge of a (private, ephemeral, encrypted, authenticated) message channel to other accounts, and then messages flowed via automated subscription-based pull. You'd still want your MUA to be a web service with active background polling, though (like cloud RSS reader services), since otherwise a user could send a message and then "retract" it from their feed before your own client had retrieved it.

But this would solve at the very least the spam problem: you could simply unfollow a channel that's sending you email, and receive no future messages on it. It'd be like every (sender, receiver) pair having its own dedicated inbox, that the true receiver consumes only voluntarily.