Re: e-mail encoding/formatting (was Re: Split-screen mode in mutt?)
On Thu, May 11, 2006 at 09:18:26AM EDT, Kyle Wheeler wrote:
> On Thursday, May 11 at 12:56 AM, quoth cga2000:
> > Interestingly, I just had the problem today.. I was asking the slrn
> > mailing list if there was anything I needed to configure for slrn to
> > display non-ascii characters correctly. I had found one example of
> > an article whose author's first name was Björn something - correctly
> > displayed in mozilla-mail - and in slrn the "ö" was rendered as a
> > vertical rectangle on my display. Now, when the message came back to
> > me from the mailing list, the "ö" was rendered by an "=F6".
>
> ...what's wrong with that? If, as you say, your encoding was set to
> "iso-8859-1", that's the correct quoted-printable encoding for "ö".
> I'm not sure I understand the problem...
Something is indeed very "wrong". My original message did not contain a
capital "A" with what looks like an oblique umlaut on top, followed by
something the looks like a capital P facing left instead of right and
two legs instead of one..! What I had written was the name "Bjoern",
with the "oe" spelled "o" with an umlaut on top.
>
> > So I thought I should check the encoding that mutt generates just
> > before my messages are sent (I sent a copy of this same message to
> > myself and hit 'v' just before hitting 'y'.. ) and I noticed that
> > the encoding was "text/plain 8-bit iso-8859-1".. So I said to
> > myself.. this can't be right.. this is not "plain text" at least as
> > I understand it.. shouldn't it be "quoted-printable", maybe..?
>
> If you check, this message I'm sending should be sent as text/plain,
> 8-bit, iso-8859-1. Quoted-printable is, officially, "plain" text, even
> though that seems rather odd. Basically, it's "plain" text because it
> is not html and it's not RTF (rich text format).
OK. I hadn't thought of that. I took it to mean ASCII.
>
> > So I looked for some way I could control this.. and I found a
> > boolean that is not set by default: "encode-from". I'm not sure I
> > understand the explanations in the mutt manual, but I thought I
> > could run the same test and see if it helps.
>
> The $encode_from variable is a workaround for bad mbox parsers (or bad
> mbox writers). In mbox format, all messages begin with a line that
> begins "From ". Many mbox parsers use that to figure out where each
> new message begins. This of course has the problem that sometimes the
> message body can contain a line that begins with that same string. One
> way around this problem is to include a "Content-Length" header or
> something similar in the message header, allowing the mbox
> reader/parser to know to skip X number of bytes before expecting the
> next "From ", but some mbox writers don't add that header, and some
> mbox readers ignore such headers. On the other hand, if you can turn
> "From " in the message body into "=45rom ", all good mail readers will
> decode that quoted-printable transparently, and the message will be
> parsed correctly even by very simple mbox readers. That's what that
> flag does.
Phew..! Thanks for the explanation. As Alain suggests, I probably don't
want to mess with that.
>
> > I haven't done so yet, but I would like to fix at least this. It is
> > rather annoying to see my *own* messages come back garbled. Because
> > if they are messed up on my display, I would imagine it increases
> > the probability that they also are for everybody else that receives
> > them.
>
> It doesn't *sound* like your messages are garbled (this one certainly
> isn't). What makes you think they are?
>
Well see the above. This is just one example of something that's not
right.. I'm getting lots of messages from different mailing lists full
of those "=" + the two hex digits/characters for stuff that mutt (the
way I'm set up) is unable to decode.
No, I think I grossly underestimated the implications of switching to an
UTF-8 locale. Especially doing it when my mail setup is far from stable.
So due to this and a bunch of other issues with applications that don't
play well with UTF-8 such as slrn and elinks, I have switched back to my
original en_US locale.
> > I was looking for something that would have reliable up-to-date info
> > on the subject in one place. One frustrating aspect is that you can
> > end up spending more time looking for bits and pieces of doc and
> > putting them together than actually studying it.
>
> Understood. Unfortunately, public mailing lists may be your best
> option if you're looking for one-stop shopping.
Well this particular one in definitely a great resource.
Thank you very much for your explanations.
cga