Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Top posting is the proper place for new content in an email chain to go. It means the new message is prioritized over the history, with the option to have the history of the email chain available if you really want/need it.

MS Office was designed to fit business processes, and it does that well.

It's not a surprise that Apple's mail client falls over attempting to support business functions.



Top posting is completely worthless. All it does is include the message you replied to, which any sane email client can show immediately without having to copy it all.


I’m not defending top posting here. I’ve noticed a couple of practices in companies (not sure about other environments). One is doing a Reply All, adding a reply body and copying some new people into that thread after several back and forth messages have already been exchanged. Those new people (can) now have the full context of what they’ve received without the person composing the reply having to add context. The second is when people send mails to several others and miss copying some. Then one of the receivers or the sender themselves would do a Reply All and add a “+<person forgotten before>” (or sometimes even use ++ and the name).


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.


Top posting is extremely valuable to people who need to weigh in on parts of a discussion without participating in the entire thing from the beginning, like lawyers, accountants, engineers, and doctors, who may get added on late into the discussion but may need the message history so they can make informed statements/decisions.

Also, the suggested alternative, MIME attachments, simply doesn't work well in most mail readers. It's barely usable in Gmail and not at all usable on iPhone or Android. (Ironically, it works quite well in Outlook.)


Not if you are added to a thread.


> MS Office was designed to fit business processes

Microsoft Outlook made sense once you (or at least me) realized it was designed to send memo's not email.


It doesn’t “fall over.” It gives you the option to choose.




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

Search: