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]

 



On Sun, 10 Oct 2010, Petrus de Calguarium wrote:

> 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<ignored_mailbox@xxxxxxxxxxxx>  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:
>>>> http://en.wikipedia.org/wiki/Quoted-printable
>>>> http://en.wikipedia.org/wiki/Email#Content_encoding
>>>>
>>>> --
>>>> [tim@localhost ~]$ uname -r
>>>> 2.6.27.25-78.2.56.fc9.i686
>>>>
>>>> Don't send private replies to my address, the mailbox is ignored.  I
>>>> read messages from the public lists.
>>>>
>>>>
>>>>
>>>> --
>>>> users mailing list
>>>> users@xxxxxxxxxxxxxxxxxxxxxxx
>>>> To unsubscribe or change subscription options:
>>>> https://admin.fedoraproject.org/mailman/listinfo/users
>>>> Guidelines: http://fedoraproject.org/wiki/Mailing_list_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
> response?
>
> 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
> users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change subscription options:
> https://admin.fedoraproject.org/mailman/listinfo/users
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
>

Has anyone considered trimming boilerplate?

-- 
Michael   hennebry@xxxxxxxxxxxxxxxxxxxxx
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux