Re: ... why top-posting should be avoided... (was Re: Broken mail readers (was Re: Properly wiping a hard drive ?))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


JD wrote:

>   On 10/10/2010 01:22 PM, Sam Sharpe wrote:
>> You forgot to mention why top-posting should be avoided...
>> --
>> Sam
>> On 10 October 2010 21:01, Tim<[email protected]>  wrote:
>>> On Sun, 2010-10-10 at 09:02 -0500, Matthew J. Roth wrote:
>>>> I'd really appreciate it if anyone could explain why these things are
>>>> happening and how I could configure the Zimbra Web Client to fix them.
>>> You probably can't fix the threading problems, those things sound more
>>> like faults, or badly designed software which simply doesn't do
>>> everything that it should do with email.  But the long line issue may be
>>> a configuration option.  All the things you brought up are mentioned
>>> below.
>>> Threading - Mail clients insert a header, as they reply to a message,
>>> that indicate which message you're replying to (the in-reply-to header
>>> will be followed by its message id).  And add the same message id to a
>>> references header, which lists message ids of all the messages that
>>> belong in the same thread.  Then, when they show a list of messages, the
>>> references headers are used to group them all together, and the
>>> in-reply-to headers to put them in the right sequence.
>>> Headers - These are data put ahead of the message, not where you can
>>> usually see them, but the pre-amble before the message.  Use a "view
>>> message source" option in your client to see them all.
>>> Chances are that if your mail client is destroying threading, then it
>>> doesn't do anything with those headers (doesn't insert the in-reply-to,
>>> and doesn't add to the references).  View the source of one of your
>>> replies to see if it does (send an email to your own address to test
>>> without bothering anybody else with all your tests).  You're unlikely to
>>> be able to add the function to inadequate software.  It's a basic part
>>> of email clients, should already be there, there shouldn't be any
>>> options to remove it, with the exception of anonymous mail services used
>>> to protect people in certain countries and situations.
>>> Line length - Customary practice was to set software to wrap lines at
>>> about 72 characters.  That ensured that the message would fit into 80
>>> column displays, even when there were a few generations of quotes
>>> prefixed with ">" marks.  Messages longer than the screen size would get
>>> badly mangled, being hard line-broken, not re-wrapped.  And often still
>>> are, even with modern software, when someone replies to those messages
>>> (just about everyone's seen hideously ugly and annoying to read messages
>>> with alternating 79 and 6 character length lines).  For those who think
>>> that 72 is too short consider that (a) reading longer lines than that is
>>> more difficult, and (b) it's still about the right size when printing
>>> email to A4 or US letter paper, no matter what your printer resolution
>>> is.
>>> As we all know, software authors, and users, ignore custom as they see
>>> fit.  And options creep in to change this, or the recommendation is just
>>> plain ignored (no wrapping occurs, at all).
>>> No wrapping has its problems, especially with older client or server
>>> software, as many had a 999 character limit, and would have some form of
>>> error if the line was any longer.  Each line in a message is parsed by
>>> the software, headers and message content, looking for information that
>>> it needed to handle the mail (addresses, content headers, etc.).  And
>>> such software may have only been able to handle 999 characters per line.
>>> Not to mention the difficulty in reading messages with huge line
>>> lengths, especially when users don't break their writing up into any
>>> paragraphs.
>>> Options came to be that would allow you to send apparently unwrapped
>>> text, so that the reader could resize their window to suit themselves,
>>> wrapping your message within their window, but with the message source
>>> still using short lines, that would keep all other software happy.
>>> Various content-encoding schemes use some method that virtually says,
>>> ignore the line breaks actually in the source, only wrap at a special
>>> character sequence.  And most mail clients would decode that content,
>>> though some older ones cannot.  They'll show those /codes/, or simply
>>> show the text as 72 character wrapped lines.
>>> And that leads to a couple of things you can try to change how your
>>> message does line length.  Look for user configuration options regarding
>>> line length or line wrapping.  And/or try out different content-encoding
>>> schemes (plain, quoted-printable, base64), your client may wrap
>>> differently for some of them.
>>> Plain will just send out what you typed, as if you were still working
>>> with ASCII-only computing.  Email was originally only 7-bit, and often
>>> still is, requiring encoding to get through many services.
>>> Quoted-printable, inserts control codes that may look odd (an equals
>>> sign, followed by a number), but are a sequence of ordinary characters,
>>> that you could just skip over if you happened to see them in a client
>>> that can't handle them.
>>> Base64 will encode 8-bit textual data into sequences of characters that
>>> only use 7-bit ASCII characters.  It looks like gibberish to the naked
>>> eye, hence why users still using *ancient* mail client software don't
>>> like it.
>>> Don't, however, send HTML content-encoded mail to the list, it will not
>>> be appreciated, and you will get flamed for it.  You can Google why HTML
>>> mail is bad, for yourself.
>>> See:
>>> --
>>> [[email protected] ~]$ uname -r
>>> Don't send private replies to my address, the mailbox is ignored.  I
>>> read messages from the public lists.
>>> --
>>> users mailing list
>>> [email protected]
>>> To unsubscribe or change subscription options:
>>> Guidelines:
> Perhaps the list server, when sending a final confirmation of
> subscription, should include this reminder (I am sure there are other
> reminders that everyone can think of). But this particular one has
> definitely caused many reply posts asking the OP to not top post.

Has anyone ever noticed that gmail (and likely a lot of other online email 
services and desktop software) opens a gap at the top for typing the 

gmail is software written by programmers, yet it is programmers who have the 
most issue with top-posting. And then they complain when people top-post... 

Threading mail is very convenient, this is true, but this particular posting 
is a prime example of the disadvantage of bottom-posting. One has to scroll 
and scroll and scroll all the way to the very, very bottom before one can 
read what was just written. (I am reading this in knode, a dedicated news 
reader. Perhaps your system will display this differently, but I see post 
after post prefixed with >>> and no threading.)

users mailing list
[email protected]
To unsubscribe or change subscription options:

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux