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
