Re: e-mail encoding/formatting (was Re: Split-screen mode in mutt?)
On Wed, May 10, 2006 at 11:08:16AM EDT, Kyle Wheeler wrote:
> On Tuesday, May 9 at 08:00 PM, quoth cga2000:
> >> Mutt stores all mail in "raw" or "undecoded" format, and decodes it
> >> every time you view it. So, saving mail to a file and then editing
> >> that file will show you the long =E2=80=99 form.
> >
> > I wasn't sure how/if you could use mutt to actually save a message - I
> > think you can save the message to a separate mbox by pressing 's' (by
> > default) in the pager or index, right?
>
> That will copy the message to a separate mbox and mark it to be
> removed from the current one, yes. You can also use 'C' to "copy" the
> message to another mbox and leave the current one as-is.
>
In this particular case I should save the entire thread.
[..]
>
> > One of the difficulties of learning all this on a live environment
> > is that some garbled displays may be caused by mutt - and other
> > things.. locale.. font.. bad procmail rewrite rules.. not being set
> > up correctly my end.. but if I understand the situation correctly,
> > they could also be caused by a bad setup at the other end (the
> > sender's machine).. or even some relaying machine.. So it's not just
> > a case of saying.. ok, this message does not display correctly here
> > in mutt.. so let's investigate my setup and fix this.. because there
> > are other things that may not be right over which I have no control.
> > Not easy to tell the difference.
> >
> > Am I right in assuming this?
>
> Yes, though it's usually best to presume that the remote end is right
.. and in any case, I guess it's probably a good idea to triple-check
your stuff before you start yelling at people.. and likely make a fool
of yourself.
> until you decide or discover (by comparing it to the official specs)
> that it is wrong. I mean, in any case, there's not much you can do
> about the remote end other than to find a way to configure your system
> to handle it.
Does tend to make things more difficult for the novice, though. I'm
keeping an eye on the messages I send to mailing lists. They are
interesting because I control both the sending and the receiving end of
the process. In this particular case, the only part that's beyond my
reach is what the middleman might be doing..
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".
Embarrassing..
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..?
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.
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.
>
> > Lastly, I will need to set aside at least one week-end to review and
> > test my entire setup in detail. Are there any useful docs that are
> > more implementation-oriented (I run a linux box) than the RFC's and
> > that would cover the encodings & content header aspects?
>
> I'm not aware of any... I educated myself mostly by reading the
> Wikipedia entries on UTF-8 and Charset, and then playing around with
> echo (e.g. I have a uxterm running, and in there I can echo raw bytes
> to construct utf-8 characters, like so: echo -e '\342\200\231')
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.
Thanks again.
cga