Three Carriers

ガラケーの時代、大規模配信用の MTA を作っていた。

いまなら、Gmail と iCloud と社内アドレスを相手にしておけば、話の8割は済む。文字コードは UTF-8、RFC 5322 にだいたい従っていて、マルチパートも HTML とプレーンを multipart/alternative で並べれば終わる。当時はそうではなかった。

メールアドレスの「妥当性」がまずおかしかった。@の直前にドット。ドットの連続。abc..def@docomo.ne.jp みたいなアドレスが、現実に登録フォームから流れてきた。docomo と au は 2009年4月まで、RFC を無視したアドレスを発行していた。Google ですら 2015年まで、ezweb/docomo 宛だけ違反アドレスを通す特別措置を入れていたらしい。RFC を盾に弾けばいい、という話ではなかった。そのアドレスを毎日使っている人は、現にそこにいた。

文字コードはもっとややこしかった。ガラケーの内部コードは Shift-JIS。一方、本来のメール規格は ISO-2022-JP（いわゆる JIS）が主流。PC 同士のメールはそれで動いていた。

サーバーから docomo や SoftBank に送るぶんには、SJIS でも JIS でも通った。キャリア側のサーバーが内部で SJIS に変換して端末へ配るからだ。困るのは UTF-8 や、相手のコード表にない文字を投げたときだ。表現できなかった字は 〓（下駄）に置き換わって届く。とはいえ、docomo と SoftBank はまだマシなほうだった。

au はさらに別だった。独自に絵文字を埋め込んだ ISO-2022-JP を使っていて、対応するには各社の絵文字コード表を覚える必要があった。docomo と au と SoftBank で絵文字のコード位置がそれぞれ違う。「メールを送る」と一言で言っても、宛先のキャリアを判別して、本文の文字コードと絵文字の流儀を切り替えなければならなかった。

マルチパートはもっと厳しかった。デコメ（HTML メール）の組み立て方、添付画像の埋め込み方、Content-Type の並び順までキャリアごとに違う。「全宛先に同じものを送る」で済む話ではない。宛先ごとにバラして組み直す処理を、MTA が抱えていた。

いまなら全部 UTF-8 で書けばいい。マルチパートは multipart/alternative で済む。ガラケー全盛期の MTA に積んでいた、キャリアごとの分岐コードは丸ごと不要になった。便利になった、で終わる話のはずだ。

それでも、ふと届いたメールの文字コードを反射的に確認する瞬間がある。