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
