実際の化ける・詐欺メールで動作確認してから公開しようと思っていたが、どちらも いつ来るか分からないので(分かっているのは文字化けが今月末)、とりあえず公開する。誤りや修正があれば、その都度更新する。
文字化けの暫定対処
メーラーは(Thunderbirdに業を煮やしたため)Evolutionを使っていて、概ね問題なく使えている。が、ある会社から来るメールが文字化けすることがある。分かっている限り、化けるパターンは2つあって、以下である(文頭を抜粋)。
- 「㈱クレ」 → 「螢レ」
- 「コス」 → 「●(I:=」
- 注: ●は(とIに重なっている。
最初はEvolutionの日本語対応が今一つなのかと思い、もしかして送信するメールも化けることがあるのかと思って、心配していた。が、近頃 やる気が出て詳細に調べたら、そうではなかった。上の2種類の問題は、元のメールのcharsetがISO-2022-JP(7ビットJIS)の時に起こり、化ける原因は以下だった。
- 「㈱」のような特殊な文字※がある場合(?)、なぜかその先頭と次の文字の最後の1バイトが抜ける。
- 元のコード:
2d6a 252f25 6c : 「㈱クレ」 (下線のまとまりで それぞれ1文字。取り消し線の文字が抜けて化ける↓。) - 化けたコード: 6a 25 25 6c : 螢レ
- ※「文字コード表 JISコード(ISO-2022-JP)」によれば、これはJIS X 0208 (1990) to Unicode変換表にない文字で、それらが駄目なようだ。
- 元のコード:
- 半角カナ(正確にはISO-2022-JP-MS)は非サポート(正しく表示できず、全角に変換も されない)。
- 元のコード: 1b 28 49 3a 3d : 「ESC (Iコス」 (ESC ( IはISO-2022-JP-MSの開始を示すらしい。 (→ 参照) コスは半角カナ)
- (化けた)コード: 1b 28 49 3a 3d (元の半角カナのISO-2022-JP-MSのコードがそのまま出る。 → ESCは●になり、そのあとの記号とカナはASCII文字と解釈される。)
元はと言えば、メールを送って来る会社が「ちゃんと」(特殊な文字や半角カナは使わない)すればいいのだが、そもそも、メールにそれらを使うことを禁止する規則はない(ないこともないが、強制力はない)ので、一般的なアプリ(例: Windowsやスマフォ)で ちゃんと出るようにしているなら文句は言えない。
その会社にしても、情報提供元からのテキストを勝手に変換して誤変換などでトラブルが起こるリスクを抱える気・価値はないだろうから、元のまま送るのが適当だろう。
それで、簡単な対処(ちゃんとやるには それなりの手間が掛かる)を試行錯誤したところ、nkfコマンドで何とかなることが分かった。下のようにすれば、ちゃんと表示できるようだ。 (注: 本物の化けるメールでは未確認)
- ヘッダのContent-TypeのcharsetがISO-2022-JPの場合は特殊な文字があるかも知れないので、本文をnkfに通す。(nkfが「うまく」やってくれるようだ)
- 上に加えてContent-Transfer-Encodingがquoted-printableの場合は半角カナがあるかも知れないので、本文をnkf -mQに通す。(上と同様にnkfが「うまく」やってくれる)
- 上のいずれかの結果をEvolutionに入れる(メールとして送る)。
そして、Evolutionのメッセージフィルタの機能でメールを外部コマンドにパイプで送ることができるので、上の処理をするスクリプトに送り、化けた可能性のあるメールを修正(nkfでコード変換)して自分(のデスクトップのローカルなアカウント)にメールで送るようにした(それを再度Evolutionが受信して、正しく表示される)。
処理を簡易にしているためと化けるメールがマルチパートなので、変換した本文の先頭にContent-Typeなどが入ってしまうが、まあ使えそうだ。
書いたあとに確認していて「ISO-2022-JPとISO-2022-JP-MS」というページを見付けて気付いたが、「㈱」の化けの原因もISO-2022-JP-MSなのかも知れない。「㈱」も変換表にないことから「環境依存文字」で、ISO-2022-JP-MSで追加された文字なのではないだろうか? そうであれば、メールを送る側がcharsetに"ISO-2022-JP"と書くのが良くないのだろう。
それなら、nkfで変換するのでなく、charsetを"ISO-2022-JP-MS"に置換すればうまく行くのかも知れないが、Evolutionが対応しているか不明なので、今は何とも言えない。
詐欺メールチェックの補助
それから、近頃Amazonを騙るメールが時々来るようになった。全部中国のドメインからなので、AliExpressか その店、または、そのあとで握力計を買った楽天の店(中国製品を扱っている)から漏れたのではないかと想像している。
そういうメールは、最初に詐欺と見抜いたらEvolutionのスパムフィルタに指示すれば、以後は自動で判別されて見えなくなるから、大きな手間やストレスではない。が、もう少し補助したくなった。
詐欺メールのヘッダを見ていたら、DKIM-Signatureがある場合があることに気付いた。その内容をdkimverifyコマンド(→ 参照1, 2)でチェックしたら※"ERROR:root:missing public key: default._domainkey.Xyz.co.jp."(ドメイン名は架空)のようなエラーになった。
※dkimverifyには-vを指定すること。
わざわざ、チェックしてエラーになるsignature(署名)を付けるのも間抜けだが、更に間抜けなアプリは騙せるのかも知れない。
そこで、上の文字コード変換と同じような段取りで受信メールのDKIM-Signatureをチェックするスクリプトを作り、Evolutionのメッセージフィルタは戻り値がエラーだったら「DKIM不正」のラベルを付けるようにした。
なお、Evolutionが文字コード変換をするのか、正常なメールでもbody hash(本文のハッシュ)が合わないというエラーが出るので、それは無視するようにした。それだと本文が改ざんされても分からないが、さすがに そこまで手の込んだものは少ないのではないだろうか。
↑ Evolutionの設定を見て気付いた。: Bogofilterのオプションの"Convert message text to Unicode"のせいでメール本文が変換されてハッシュが合わなくなっているかも知れないので、スパムフィルタを(変換する設定のない)SpamAssasinにしてみた。: 次のDKIMがあるメールで本文のハッシュが合うかで分かる。
→ SpamAssasinにしても合わなかったので、Convert message-は関係なかった。そもそも、BogofilterでもSpamAssasinでも、Evolutionから送られて来るメールはUnicodeではなくISO-2022-JP(-MS)だった。 (10/9 6:39)
Bogofilterのためにメール本文をUnicodeに変換しているのなら、文字化けもそれが原因かも知れない。EvolutionがISO-2022-JP-MSをそのまま(Unicode(UTF-8?)に変換せずに)表示できるなら、化けないのではないか?: 次の化けそうなメールで分かる。
→ 上述のとおり、Evolutionから送られて来るメールはUnicodeではなくISO-2022-JP(-MS)だったので、関係なかった。 (10/9 6:39)
また、想像や期待だが、SpamAssasinの"Include remote tests"を有効にすれば(しなくても?)、ひょっとしてDKIMのチェックもしてくれる気がしたので、有効にしてみた。: これも次の詐欺メールで分かるはずだ。
↑ Wikipediaによれば、SpamAssasinはSPFやDKIMにも対応しているようだ。
でも、今後は本文を改ざんするものが出るかも知れない。メールの中継サーバを乗っ取ればできるだろうか。
こうすれば、不正なDKIM署名を付けた間抜けな詐欺メールはメールのラベル(色)だけで分かるので、自分で判断する手間が省け、誤認する可能性が減りそうだ。 (注: 本物の詐欺メールでは未確認)
PS. Ama.を詐称するメールをAma.のそういう窓口に転送すれば何かしてくれるかと期待して数通送ったが、結局また来た。別のところから来ているのかも知れないが(確かに、今までのものは大きく2種類ある)、それも含めて意味がないと感じた。
不正アクセスと同様に、そういう組織を根絶やしにしない限り、ゴキブリのように次々と現れる。「来たら対処する」のような対症療法では駄目だ。
(10/8 6:53 いろいろ修正; 10/9 6:39 Bogofilterの"Convert message text to Unicode"を止めた結果(関係なし)を記載)
