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. -- 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
