Why it’s so hard to innovate in the e-mail space (2014)

> Clueless developers and users around the turn of the millenium then somehow didn't understand the purpose of providing you with a quoted version of the email you replied to, and started putting the reply above the quoted mail, thus ending up sending a copy of the mail they just received back to the person they received it from ... and nobody seemed to notice how idiotic an idea that actually is, and so it became sortof the new norm in large parts of the internet to attach large blobs of completely useless and often close to unreadable text to every mail, up to the point where some people even invented justifications for the behaviour that mostly tend to describe how this "feature" allows them to work around the lack of proper thread handling in their mail clients.

Yes, I think the rationale must run something like "What if user A deletes the entire conversation they were having with user B, and user B replies to the deleted conversation, but user A doesn't know what the reply is about because they deleted the entire conversation, have a terrible memory, and are too embarrassed to ask user B to explain what's going on? Let's just send the entire conversation as quoted text every time."

I can't see that encryption will ever work end-to-end as we want. People are too stupid to learn most things. Technical solutions rely on big corporations that we trust to do the Right Thing(TM). The Right Thing(TM) is impossible from US companies and probably impossible from European companies.

Attachments. I don't remember the last time I sent a large one. As far as I know most of the size limitations are artificially implemented by companies that don't want to spend that much on storage. Other limitations such as Gmail's block on executables is because people are stupid and will run everything they get sent.

People will never not be stupid so we can never have nice things.

Well, if it's supposed to be compatible with all the HTML crap out there, and even most MUAs' broken encoding of plain text email, it might be hard, but in principle, I'd think this should actually be rather simple:

Simply specify an algorithm that defines how to segment a text/plain body into paragraphs and how to thus generate MIME object-scope IDs per paragraph (by simply numbering them) and use that same structure to provide UI elements per paragraph. Then, if the user writes a per-paragraph reply, generate a multipart/alternative body, with one text/plain part in traditional quoting style, optionally with format=flowed, and one alternative application/fancy-paragraph-foo part which contains in some sort of serialization format references to the message+paragraph IDs, that paragraph's text, and the corresponding reply text. This way, a receiving MUA that doesn't support application/fancy-paragraph-foo will display an ordinary quoted plaintext body, and also, if a communication partner uses different MUAs, you can still reply to an email sent using an MUA without application/fancy-paragraph-foo support and still have the feature work if the reply is then read in an MUA that does understand it. Also, including the text of the original paragraph makes sure you can still display a message sensibly when the displaying MUA doesn't have the mail it's in reply to - you'd just have to be careful to not misrepresent the authorship information as reliable.

> What if user A deletes the entire conversation they were having with user B, and user B replies to the deleted conversation [...]

* g * (is there any way to escape asterisks to their literal meaning?!)

Well, the rationale I've heard is that it's easier to make sure new participants in a conversation can read up on what has happened so far ... which obviously would be solved far better by attaching a thread of message/rfc822 attachments when adding a new participant that the recipient could navigate using their MUA's usual UI instead of having to read a close to unreadable unstructured mess of emails.