* Baurjan Ismagulov ([EMAIL PROTECTED]) [Dec 09. 2001 18:57]:
> > Can some kind soul point me to the docs I need to read to figure out why
> > I see things like this:
> >
> > \251 allie\260M
> >
> > In some messages? \260 is the degree symbol and \251 is the copyright
> > symbol, I think.
>
> Seems that this is the product of mutt's idea of which characters are
> displayable using your current charset. What is encoding of the message
After following your lead (thank you!), I think I've discovered what my
problem is. There was a thread I started earlier this week about clear
signing with GPG and Mutt. Part of my solution, which included being
able to verify clear-signed messages, was to use a Procmail filter to
add in a content type that Mutt would recognize as PGP signed:
-------8<-------
# For PGP signed/encrypted messages not recognized by content-type
:0:
* !^Content-Type: message/
* !^Content-Type: multipart/
* !^Content-Type: application/pgp
{
:0 fBw:
* ^-----BEGIN PGP MESSAGE-----
* ^-----END PGP MESSAGE-----
| formail \
-i "Content-Type: application/pgp; format=text; x-action=encrypt"
:0 fBw:
* ^-----BEGIN PGP SIGNED MESSAGE-----
* ^-----BEGIN PGP SIGNATURE-----
* ^-----END PGP SIGNATURE-----
| formail \
-i "Content-Type: application/pgp; format=text; x-action=sign"
}
:0 fBw:
* ^-----BEGIN PGP PUBLIC KEY BLOCK-----
* ^-----END PGP PUBLIC KEY BLOCK-----
| formail -i "Content-Type: application/pgp-keys; format=text;"
------->8-------
OK, well I think the problem is that formail is, duh <g>, replacing
the content type:
-i headerfield
Same as -A, except that any existing similar fields are
renamed by prepending an ``Old-'' prefix. If
headerfield consists only of a field-name, it will not be
appended.
(BTW, I doubt -A would help matters any)
And sure enough, in the very message I was complaining about, I see:
Old-Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Content-Type: application/pgp; format=text; x-action=sign
Bad bad bad! :-)
> (you can see it using the "v" key) and your current charset (":set
> charset"<enter>)? I think you can check whether the symbols would
> display correctly on your terminal with something like "echo -e '\251'"
> (single quotes are important), if your echo supports "-e" switch.
Yep, that worked in an Xterm.
I don't suppose anyone knows how to append the message's existing
charset to the end of my injected content-type header? <g>
Or could some charsets fook up the actual signed/encrypted message?
Thanks for you help, Baurjan
--
-Brian Clark
