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

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

 



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


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

  Powered by Linux