It has come to my attention... ...that Baurjan Ismagulov said on Tuesday, Aug 27 2002: > Hello,
Hi,
> I often receive messages with either unquoted 8-bit headers (in lines
> like From:, To:, Subject:, etc.) or, worse, with characters quoted and
> wrong charset specified.
My condolences. This sounds like a job for procmail's formail program.
> Example 1:
>
> My console can display koi8-r. I receive a mail encoded in windows-1251
> with an unquoted header. Mutt converts the body to koi8-r, and I can
> read the contents. However, Mutt doesn't know the header charset, so it
> is displayed without conversion, and I can't read it. For instance, 192
> is Acyr in 1251, but I see it as yucyr with my koi8-r font.
>
> I wish I could specify the header charset manually (as I do with ^E for
> message bodies) so that Mutt could convert the subject and other fields.
Using procmail/formail and iconv you might be able to accomplish
rewriting of the mail headers based on the sender so they are properly
escaped. You'll have to hit up the folks at procmail-users for that
though, as I wouldn't know how to do it. Tricky situation. Bottom
line is, those senders are using broken mail clients. Though it may
seem anti-social, ya might want to drop a few hints to this. I don't
think mutt's the only mail client that would get confused by such
email.
> Example 2:
>
> My console can display iso-8859-9. I receive a mail encoded in
> iso-8859-9. Headers are quoted, and the charset is set to iso-8859-1
> ("Subject: =?iso-8859-1?Q?some_8859-9-encoded_text?=). Mutt reads the
> charset, and displays 8859-9-specific characters as question marks, as
> they are not present in my 8859-9 font. E.g., 254 is scedilla in 8859-9,
> but Mutt thinks it is 8859-1, and tries to display thorn, which is not
> available in the font.
Hmm, here's an idea for a procmail recipe that should work, but I
haven't tested this myself.
:0 fhw
* ^From: Evil Sender <[EMAIL PROTECTED]>
{
:0 h
SUBJECT=| formail -x"Subject:" | sed 's/iso-8859-1/iso-8859-9/i'
:0:
|formail -I"Subject: $SUBJECT" >> $DEFAULT
}
I would hope this would do the trick, but I can't be sure if you'd
need to reformat the header. I wouldn't think so. Anyone?
"$ man procmailex" for more ideas.
> Again, the only solution I see is to override the charset manually. I
> can't just "charset-hook iso-8859-1 iso-8859-9" since I can as well
> receive mail encoded in koi8-r, but flagged as iso-8859-1.
Yeah, definitely a job for formail.
> I'm using 1.4. I think LC_CTYPE and charset are set correctly in both
> cases. BTW, why does Mutt use both of these variables? I would find
> logical if charset have overridden LC_CTYPE. I can't see the rationale
> behind the current implementation, and find it counter-intuitive. Could
> anyone please shed some light on this, too?
Hmm, from my experience, charset does override LC_CTYPE. I'll have to
double check that. To my knowledge, charset is set based on your
locale if you don't explicitly set it in your muttrc. Anyone?
> I would appreciate any help.
Hope I was helpful. I'm not an expert by any means and for everyone
else, correct me if my information is wrong. I'm pretty spotty on
most of this stuff.
> Thanks in advance,
> Baurjan.
You're welcome.
--
--Sam
UC Davis, California USA
msg30450/pgp00000.pgp
Description: PGP signature
