<< BPMエンジンとしてのJIRA #augj | Home

これまで体験してきたメール送信の難しさ #SendGrid_jp

SendGrid Advent Calendar 2016の12月22日分です。

メールを送る際、プロトコルとしてSMTPが使われていてメールサーバにはPostfixやGoogleのメールサーバなどを使えば簡単というのは割と有名です。
が、送るのは簡単だけど何かと問題が発生するものです。

私のこれまでの経験をちょっとメモしておこうと思います。

メール配信周りの運用経験


1. 自宅サーバ運用の掲示板(James、2000年〜)
2000年くらいから自宅サーバで掲示板を運用していました。Tomcatで動くServlet + JSPのアプリケーションで、メールアドレスを登録しておくと新規書き込みがメールで通知されるというものです。
メールの配信にはPure JavaのメールサーバであるJamesを使っていました。
自宅サーバで運用してた(今も動いてるけど)のは勉強、練習みたいなもので特にサーバの運用が好きなわけではありません。なんかガラケーで届かないと訴える人が多いなーと思いながらなんとなく運用していました。

2. 自宅サーバ運用の掲示板(Google Apps、2007年〜)
たしか自宅サーバのマシンを更改するタイミングでJamesの運用が面倒になり、Google Apps for Domainからメールを送るようにしました。
なんとなくガラケーにも届きやすくなったような??

3. いくつかのドメインでのメール運用(Google Apps)
友人知人のWebサイトやドメインを運用する中、もちろんたいしてお金はもらっておらず責任はとれないということで自宅サーバでの運用ではなくGoogleでメールの送信をしていました。

4. 会社のメール運用(Google Apps、2013年〜)
会社のメールもやはりGoogle Apps(現G Suite?)を使ってます。

勉強不足で、ボンヤリと「メール配信はなんとなく自前でサーバを建ててもよいし、GoogleのSMTPサーバを使うも良いし、なんでも良い」と長年思っていました。時々配信に失敗しているなーと思いつつ。

起きたトラブル


1. ガラケーに配信されないことがある
ガラケーの、いわゆる「キャリアメール」については「届かないことがある」「全く届かない」という話がボチボチありました。自宅掲示板サーバは商用環境の運用ではないので大して調べもせず、ドメインのホワイトリストに入っていないからとか、リンク入りのメールは全部拒否する設定になっているとか、PCメールは受け付けない設定になっているから、といった理由だと思っていました。(それらの理由による不達も多いにあると思いますが
実感的にJamesからGoogle Appsにしてから到達率は少し増えたように感じます。

2. ガラケーじゃなくても配信されないことがある
Google Apps for Domainを使っていればガラケー以外は大丈夫だろうとたかをくくっていましたが、会社のメールもたまにとどいてないらしいことが分かりました。長い間、相手側のサーバの不具合だと決めつけていました。

3. 文字化けが起きる
メールのエンコーディングは日本語を送るのに一番無難(と思っている)ISO-2022-JPで送っていました。UTF-8に固定しているような人でないかぎり正常に読んでいただけます。
が、お客様のお名前で「山﨑」といった異体字が使われているとJavaのプログラム内では正常に扱えても、ISO-2022-JPに変換するタイミングで"?"に化けてしまいます。

4. 24時間メールが配信できなくなる
オフィスを移転した際、移転のお知らせをお客様にメールで一斉に送付しました。自作のプログラムで、顧客リストをグルグル回しながら順に送っていったのですが、途中から送信できなくなりました。エラーメッセージを調べると、どうやらGoogle Apps for Domainではメール配信数に上限があることがわかりました。(無料だと24時間で500、有料では2000件)
移転のお知らせを送れないのは全く困りませんが、受注の確認や、ライセンスが送付出来ないのは大問題です。

とった対策


1. / 2. SPFレコードを設定しました。知っている人からすればビックリでしょうが、なんと会社を立ち上げて2年もの間SPFレコードを設定していませんでした。

SPFレコードはDNSに設定するもので、「このドメインからはこのIPアドレスからメールを配信するよ」という宣言です。得体の知れない人(送信元IPアドレス)が「これが株式会社サムライズムからのメールです」と主張して手渡してきても確証が得られないので、「これは送信元ドメインを偽装しているのでは?」と疑われてしまうわけです。
SPFレコードを設定しておけば「弊社からのメールはGoogleのSMTPサーバから配信されますよ」と宣言できるので、疑われにくくなるという仕組みです。
「メール配信はPostfixでもなんでも、メールサーバがあれば送れるさ!」と思っているエンジニアは結構多いので気をつけましょう。

3. 「必要に応じて」UTF-8にする
異体字に対応すべく、ある時期からメールを全部UTF-8で配信するようにしました。イマドキさすがにUTF-8が読めないクライアントはないだろう、と踏んでのことです。
が、それなりの数のお客様から「化けていて読めない」という声を頂くようになりました。異体字が含まれるメール以上の数なので問題です。
そこで今では「基本的にISO-2022-JP、ISO-2022-JPで表せない異体字が含まれる場合はUTF-8」で送信するようにしています。以降文字化けは起きていません(聞く限りは)。

4. 大量配信しない
問題解決ではなく、消極的な回避ですがまとめて配信することは移転のお知らせで一回やっただけでやめにしました。

以上、SendGridとは間接的にしか関係ないけれども「メール配信をナメてかかると痛い目に遭うよ」という話でした。
文字だらけで申し訳ないですが、経験に学ぶのは愚か者なので、これからメール配信をする可能性のある方は歴史に学んでいるSendGridを初めとするメール配信サービスを利用することをお勧めします。
株式会社サムライズムでは少しずつ検証を重ねながら、今週から全面的にSendGridでメール配信をするように切り替えました

現状どのように使っているか、どういう点につまずいたのか、などはまた別途まとめたいと思います。




コメント追加 トラックバック送信