複数言語環境へのEメール送信で気をつけていること
こんにちは、Loco Partnersのプログラマ、大須賀です。
宿泊予約サイト reluxの開発をしています。
先日、弊社にて開催をしたLoco Partners x VELTRA 技術交流会というイベントでLTの時間をいただき、Eメール送信時に使用するcharset及びContent-Transfer-Encodingについて発表をしました。
内容について、このブログでも簡単にご紹介します。
charsetについて
送信先が特殊な環境でない限り、charsetについてはUTF-8一択で良いと思います。
日本語Eメールで使用する文字コードはISO-2022-JPに限る、という時代もありましたが、それは過去のものです。
Content-Transfer-Encodingについて
charsetがUTF-8の場合、Content-Transfer-EncodingはBase64かQuoted-Printableの2択(あるいは8bitも含めて3択)になります。
- US-ASCIIの文字が多ければQuoted-Printable
- そうでなければBase64
- 8bitは使うべきではない
という結論としました。
Eメールの送信数が多ければ、Content-Transfer-Encodingの選択によって通信量に差が出ます。 reluxでは、日本語・中国語など非ASCII文字のメールを送ることが多いため、Base64を使用しています。
Content-Transfer-Encoding: 8bit について
- レガシーなMTAを経由した場合に問題が起こる(かもしれない)
- 8bitをスパムフィルタの条件としている環境がある(という情報を見たことがある)
上記のような曖昧なものを、Content-Transfer-Encodingに8bitを使用すべきではない理由として挙げています。
問題が起こる環境がどれだけ存在するのか、実際に調べたことはありませんし、どうすれば調べられるのかもわかりません。
リスクの大きさがよくわからないため、避けるべきとしました。
reluxの開発に使用しているCakePHP2のCakeEmailクラスは、UTF-8のテキストを Content-Transfer-Encoding: 8bit で送信します。
弊社ではCakeEmailを継承したラッパークラスを作成し、Base64にエンコードして送信するようにしております。
個人的には、安心して8bitを選択できる時代が来ることを望んでいます。
最後に
弊社では、共にreluxの開発をする仲間を探しています。
reluxに少しでも興味を持っていただけましたら、オフィス見学や弊社主催の勉強会にお越しください。
直近ですと、5月26日(木)にコード改善 meetup #1の開催が決まっています。 一般参加枠では補欠となってしまいますが、LT枠がまだありますので、我こそはという方は是非！！！お申し込みいただけると嬉しいです。
