Re: e-mail encoding/formatting (was Re: Split-screen mode in mutt?)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
> So what I did - and it made better sense anyway - was that I hit 'L'
> as if I wanted to reply to the message. This caused mutt to start a
> vim session on the message and then I was able to issue a vim/ex ":w
> /tmp/msg" command to save the message to a file. So I must have
> saved a copy of the "decoded" message that contained just the 3-byte
> UTF-8 encoding.
Yup, as long as your vim can handle multibyte characters (i.e. when
you do :version you should see +multi_byte as one of the enabled
options).
A more direct method would be to set pipe_decode, and then pipe the
message to "cat > /tmp/foo"
> 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
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.
> 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')
> Thank you very much for going to all that trouble setting me on the
> right track.
Happy to help!
~Kyle
- --
This country, with its institutions, belongs to the people who inhabit
it. Whenever they shall grow weary of the existing government, they
can exercise their constitutional right of amending it, or exercise
their revolutionary right to overthrow it.
-- Abraham Lincoln
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iD8DBQFEYgHgBkIOoMqOI14RAkgIAJ4iqFqxpCvSIWQ29l9fywRwUYKCmACcDMWg
4PUZ0vMiGk4yS/NtAbuIqMg=
=jyp0
-----END PGP SIGNATURE-----