Re: Broken mail readers (was Re: Properly wiping a hard drive ?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


You forgot to mention why top-posting should be avoided...


On 10 October 2010 21:01, Tim <[email protected]> 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:
> --
> [[email protected] ~]$ uname -r
> Don't send private replies to my address, the mailbox is ignored.  I
> read messages from the public lists.
> --
> users mailing list
> [email protected]
> To unsubscribe or change subscription options:
> Guidelines:
users mailing list
[email protected]
To unsubscribe or change subscription options:

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux