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