Email::MIME is nice and handy. With header_str and body_str (since 1.900), you don't need to encode everything by yourself. Just pass flagged (decoded) utf-8 strings, and you'll get what you want. However, it only works when you send utf-8 encoded emails. In Japan, there're still some email clients that only understand iso-2022-jp (jis) encoded emails, and its popularity persuaded the Encode maintainer (who's also Japanese) to include its support (since version 2.11, with Encode::MIME::Header::ISO_2022_JP written by Makamaka). I want it to be supported by Email::MIME, but it's too specific and nonsense for the rest of the world. That's why I write this mixin instead of asking to add extra bit to Email::MIME.

As of this writing, this mixin doesn't care the tangled issues in the Japanese cellular phone industry (thus not ::Japanese). If you need finer control, just use header/body and encoded string/octets, or send me a patch.

Both work almost the same as Email::MIME's methods do, with one exception. If you pass utf-8 stings to header_str attribute or header_str_set method, they'll be encoded by Encode::MIME::Header::ISO_2022_JP, instead of Encode::MIME::Header.

Actually you don't need to use these directly. As shown in the SYNOPSIS, when this module is used, Email::MIME's original create and header_str_set are replaced with these methods internally. If you want to use the orignal methods again, unimport this module (with no pragma, or unimport method), and they'll be restored.