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
