読者です 読者をやめる 読者になる 読者になる

LocoPartners 開発ブログ

LocoPartners 開発者達によるブログです

複数言語環境への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枠がまだありますので、我こそはという方は是非!!!お申し込みいただけると嬉しいです。