Re: On some broken Japanese mails
On July 16, 2006 at 2:00PM +0900,
cwryu (at debian.org) wrote:
> Japanese mails have been always correctly encoded than ones in other
> languages. But recently I have received several Japanese spams broken
> in evolution and thunderbird. These mails have RFC2047 ISO2022-JP
> encoded headers, but the actual contents are in shift jis. For example:
> ("echo glKCT5VigsWPgJT1iq6XuQ== | mimencode -u -b" to decode it)
> I wonder (1) what program generates this wrong encoded header. Or (if
> the program is just an ignorable spam bot)
I feel this header means 99%:spam that might use unskillful scripts.
Most Japanese mailers don't generate this header.
> (2)whether the common mail
> readers (outlook or some web mails) read this header correctly. If the
> most Japanese users can read this header by some workaround of their
> mail reader, it may be worth to patch evolution or thunderbird.
At least EZweb mailer (mobile phone by KDDI) can read this header.
It seems to be auto-detection for ISO-2022-JP, Shift_JIS and US-ASCII,
but other encodings, such as UTF-8, ISO-8859-1, EUC-JP, are unsupported.
My favorite mailers Mew and Wanderlust don't support this header,
but I don't feel inconvenience. To investigate a spam message, I
can modify the header by hand.
For message body, Mew supports auto-detection, and the other
charset name or language name can be set. e.g. `C-u C-c C-l
shift_jis RET' decodes message body as Shift_JIS even if
charset="ISO-2022-JP". `C-c C-l Japanese RET' is auto-detection
that prefers ISO-2022-JP, EUC-JP and Shift_JIS to other encodings.
BTW, before MIME was defined, most Japanese mailers used ISO-2022-JP
without MIME charset name. So, auto-detection for ISO-2022-JP is
necessary to read the old de fact standard Japanese mails.