Hacker News new | past | comments | ask | show | jobs | submit login

Say someone gets added to an email thread some time after it got started—is there an easier way to get them all of the emails in the thread than having all of the emails as part of the one they were sent?

RFC 2046 multipart/digest

A standardized method of sending a set of email messages as messages, rather than copied into body text, predates Microsoft Outlook.

It's funny that this is a suggestion because top-posting was a reaction to the unfriendliness of keeping message history in MIME attachments rather than the body of the message.

MIME may be the technically superior solution...But like Betamax and MiniDiscs, it lost out to the easier-to-use solution.

Message history wouldn't use that; it uses headers (metadata) like 'In-Reply-To:' and 'References:', which are in… well, I was going to say RFC 822, but it turns out they go back to RFC 724 from 1977.

A MIME digest would be used for the case that you want to provide someone a bunch of messages they don't already have. In that case, this brings up another reason this is superior to including the thing as text: it preserves all the threading and other metadata.

Oh yes of course! Actually, multipart/mixed really seems like it should be the way that all clients do things, and that quoting at the bottom is an abuse of the quote button.

Sure, do something between an article a wiki and a forum.

Insert your cursor in their message, press enter and respond to every part worth responding to - inline. (you may want to sign your entry)

Remove all parts of the previous message(s) that do not directly build towards the current conversation.

It should look so organized that the new participant immediately adopts the format. If they fail, do it for them. (preserve the sane part of their signature)

Doing it like this really feels like you are talking with serious people who would never waste your time. That said, you can now ask how their weekend was. That part of the conversation is simply removed later on.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact