I used to think the same but I caved when I started using web interface email clients. Let’s face it, the world has moved on, new generations are online, and we are the wrong ones now.
I don't understand why this isn't configurable. Why can't the basic data structures (of one email after another in serial) be displayed in either order depending on mail client settings?
Admittedly I haven't looked into it because I'm perfectly fine with top posted emails. But I routinely sort files in my directory. Why not emails in a displayed thread?
It's people quoting text, not threads of messages.
The ability to semantically parse text to determine what order paragraphs should be displayed in to suit the tastes of the individual reader is a very recent development. Or, rather, will be soon. Maybe not very soon.
Quoting the prior message(s) should be off by default. When paper letters were still written, did you enclose a copy of the original letter when you answered it? No. And nobody looks at the growing trail of the entire message thread that's copied below your reply. Just leave the subject line intact and anyone that doesn't have a brain-dead email client will see the messages threaded properly.
If you need to address a specific point in a message you're replying to, quote just that bit.
We are emailing TBs of data around daily that provides no value to anyone.
> When paper letters were still written, did you enclose a copy of the original letter when you answered it?
The point of bottom posting was you never left the original text intact, but trimmed it to show the relevant details you are replying to and so enhance readability. Exactly as I am doing now in this reply.
> If you need to address a specific point in a message you're replying to, quote just that bit.
Precisely. Just like this. We are on the same page!
As the other comment mentioned, the email body contains the entire quote chain. The way clients accomplish threaded display is a combination of:
- parsing the unstructured email body and looking for quote levels, html formatting and printed email heads
- parsing certain headers like message-id, in-reply-to, dkim sig
- looking for sections of the message body in the inbox
This is done because there is nothing in the protocol to cleanly accomplish what you want. Even if there was, you could not rely on it at all. Doing anything with email is a gigantic PITA, you sometimes get emails where the msg-encoding header doesnt match the body's encoding, html in the plaintext section and other fun things.
Since nobody really cares about the RFC and just does their own thing, there is no chance at improvement.
This is true. OTOH, I do think the problem is solvable.
I came up with a routine to parse and translate about 2-3GB of saved emails into MBox format once.
The official delimiter is unbelievable, IMHO.
«
the exact character sequence of "From", followed by a single Space character (0x20), an email address of some kind, another Space character, a timestamp sequence of some kind, and an end-of-line marker.
»
If the entire email is being replied to, I can just read that email, which is displayed immediately before the current one in a threaded display. Why should I have to scroll past another copy of that email?
However, the original email is included as a convenience in case my MUA doesn't support threaded display or it's a mailing list I joined after the original email was sent or any other reason why I might not see it. That's why there is quoting at all.
Nobody top-posts when using selective quoting because obviously it's different.
It's one of the things I like about Gmail. It does plain-text and bottom quoting just fine.
> Let’s face it, the world has moved on, new generations are online, and we are the wrong ones now.
NEVER GIVE UP! NEVER SURRENDER!
https://mygeekwisdom.com/2014/03/15/never-give-up-never-surr...