メール運用がロストテクノロジーになっていく話

クラウドワークス Advent Calendar17日目担当のSMTPおじさんの記事です。
時間の無い人のために3行でまとめますと以下のコンテンツでお送りします。


●大規模なメール配送を安全に行うには特別なノウハウがあり罠も多い

●SendGrid便利です

●当たり前になった技術は空気のように見えなくなってインフラ化する。それがある日突然失われたときの被害は甚大。インフラ技術をキャッチアップして備えよう

メール配送今昔

さて、メール配送といえば古くはSendmailを使っていました。多くのUnixディストリビューションに標準でインストールされており、使うのが当たり前で選択肢も少なかった時代です。
Sendmailは開発が重ねられることで複雑化しセキュリティホールが頻発しました。また設定ファイルのsendmail.cfはチューリング完全であるほど高機能で複雑でまた長くなりがちでもあり今でも書きたくない設定ファイルの代名詞的存在です。

そのアンチテーゼとして単機能のプロセスを組み合わせて動作することで堅牢にし設定ファイルも簡易に書けるqmailが登場します。
シンプルなUnixらしい考え方でシェアを獲得しましたが、一方で他のサーバ系プログラムと比較しても独特すぎるディレクトリ構成、設定や長い間メンテナンスされていない︵しなくても運用できるほど安定している裏返しでもあります︶ことから最新のOSへの対応も難しくなり次の配送システムが望まれました。

そこでqmail的に複数のデーモンプログラムが協調動作するアーキテクチャでディレクトリ構成もUnixの一般的なサーバプログラムに合っているPostfixが出てくるわけですが、昨今はメール配送システムもクラウドの流れの中にあります。

SendGrid、Amazon SES、Mailchimp、Mandrillなどクラウド型のメール配送システムが台頭し自身でメールサーバーを運用しなくても簡単にメール配信できる世界になっています。

メールを安全に配送するために必要なこと

このようにメール配送についてサーバを自前で運用しなくてよくなってもメール配送の仕組みは変わりませんし、設定がWebで簡単に行えるようになった反面、どこにハマりどころがあるのか分かりにくくなっている気もします。ここではハマって痛い目にあったところを次に取り組む人が回避できるよう掘り下げていきます。

メールを送って相手まで当たり前のように届くにはいくつかの約束があります。

まずDKIMやspfといったドメイン認証を正しく設定しましょう。幸い、SendGridなどのクラウド型のメール配送システムでは正しくドメイン認証が設定されているかをバリデーションする機能があります。バリデーションで確認した上で実際にメール送信してメールヘッダーを見て認証がfailしていないか確認するのも重要です。ちょっとしたDNSの設定の違いでfailすることもあります。

次にメール配送用に利用するIPアドレスから健全なメールを配信しています、という実績を積んでいく必要があります。実績の無いIPアドレスからいきなり大量配送をかけるとスパム業者と認定されかねません。

IPアドレスを育てる

1日に何十万通も配送するようなメールサーバのIPアドレスは、メール配信の実績を積んでIPアドレスの信頼性を高めていってはじめて実現できます。信頼性を高めるにはIPアドレスから配送するメール流通量をコントロールして少しづつ増やしていきます。これをIPウォームアップやIPを育てるといったります。殺伐としたデジタルワールドで温かみのある育成が大切なのがIPアドレスです。IPウォームアップの解説はSendGridブログが詳しいです。

またSendGridには段階的なメール配送を自動でスケジューリングしてくれる非常に便利な
IP Warmup機能があります。

IP Warmupは1時間あたりの最大配送量を1日目は20通、2日目は28通のように少しづつ増やしてくれる機能です。最大配送量を越えたメールについてはSendGridの共有IPアドレスから送信します。これによって手動でメール流量を調整して実績を積む育成作業から解放されます。Webサービスからユーザーの操作に応じて送信されるようなトランザクショナルなメール送信のIP育成には最適な機能といえます。

しかしながらIP Warmupも万能ではありません。自動のスケジューリングではIP育成できないケースがいくつかあります。例をあげると以下になります。


●マーケティングメールでよくあるように配送時期に大きく波がある場合

●キャンペーン時に大量に配信したいが普段はあまり流さない



●すでに大規模に配送しているサービスから移行する場合


常時メール送信するのではなくメールマガジンのようなスタイルでメールを一度に大量配信しているケースではIP Warmupのスケジューリングが活用できません。手動で流量を調整するウォームアップ計画が必要になってきます。

また、大規模にメール送信しているサービスをSendGridへ移行するケースでもIP Warmup機能だけに頼るのはスパム的な配送とみなされるリスクが伴います。理由は後述しますが、ここでもっとも避けなければならないのがブロックリストに登録されて多くのISPからメール送信拒否されてしまうことです。

ブロックリスト

Spamhausに代表されるようなスパム業者のIPアドレスをリスト化してメール送信を拒否できるようにしているデータベースがあります。ブロックリストに登録されると多くのISPから配送がブロックされ送ったメールが届かなくなります。こうなってしまうとメールを送信しているサービスとしては致命的です。

ブロックリストに登録される条件は公開されていないため確実な回避方法が無いのが実情ですが、次の2点に注意すべしと言われています。

多くのIPアドレスからの配信

スパム業者がメールを配送するためによく使われるのが、多くのIPアドレスを利用してブロックリストを回避し送信する手口です。そのため同一ドメインからたくさんのIPアドレスを使ってメールを送っているとスパム的な配信とみなされる可能性があります。

大規模にメール配信しているサービスでIP Warmupを有効にすると複数IPアドレスを利用することになるためできれば避けたほうがよいです︵可能性の話で歯切れが悪くてすみません︶。またメール配信サービスによってはIPを固定できないものもあるので仕様を確認しましょう。

IPアドレスは固定して育てていくのが原則になります。

Spamtrap

他にはSpamtrapの罠があります。Spamtrapとはブロックリストを作成するためにスパムメールが送信されていないか監視するために利用されているメールアドレスです。当初は人間が利用していたアドレスでも、アドレス変更や利用しなくなったアドレスがいつの間にかSpamtrap化することもあるためメールアドレスからSpamtrapかどうかを判断するのは困難です。

Spamtrapに1通でも送るとすぐにブロックリストに登録されるわけではないようですが、送り続けているとある日突然メールが送信できなくなる日がきます。
Spamtrapを避けるには送り先が確実に人間であることを確認しながらメールを送るのが重要です。

SendGrid対応のためにやったこと

以上を踏まえてクラウドワークスでは次のようにSendGridを導入していきました。

段階的な移行

メール送信のジョブを少しづつ段階的にSendGrid経由での送信に切り替えていき流量をコントロールしながら1ヶ月ほどかけて移行しています。

都度で到達率やバウンスを確認しながら移行前と後でメール配信に問題ないかを監視して移行します。問題があったときに切り戻せるのもメリットでした。

IPアドレスを固定して用途によって分けて育てる

IPアドレスをWebサービスから送信するトランザクショナルなメールを送るIPアドレスと、マーケティングメールのふたつのグループに分けて取得しそれぞれをウォームアップしていきました。こうすることで仮にブロックリストに登録されるようなことがあったとしてもシステム全体でメール配信が停止するような最悪のシナリオを避けることができます。理想的にはサブシステム毎にIPアドレスを分けるといいですね。

Confirmキャンペーン

Spamtrapを避ける決定的な方法は無いのですが、なによりアクティブなユーザーのみにメールを送るというのを愚直にやり続けるしかないように思います。

SendGridではメールの開封やクリックをイベントとして取得することができるのでメールを送信してもよいかどうかの判定に人のアクティビティを反映して可能な限り人間にだけメール送信するようにしています。

テキストメールを利用しているユーザーはアクティビティが取得できないため、メールアドレスが正しいかどうかを確認するConfirmキャンペーンを実施してSpamtrapによるメール配信停止のリスクを低減しています。

インフラになった技術

さて、メールもそうですがDNSやEthernetなどインフラと呼ばれる当たり前に使われている技術は、それが使われている間は意識からなくなり空気のように見えなくなります。現代ではさらに技術の層が積み重なっていて、下のレイヤーほど意識しないと認識できなかったりします。
見えなくなっても無くなるわけではないのである日突然使えなくなったときに対応できるかどうか地力が試されるのではないでしょうか。

移行の中でもダッシュボードで確認しつつもTelnetで直接SMTPをしゃべったりMIMEエンコードされたメールをEmacsでデコードしたり抽象化されたレイヤーを上にいったり下にいったりネットワークやEメールの基本的な技術が役に立つ場面がありました。

動きの早い最新技術も魅力がありますが、冬休みのじっくりとれる時間を使ってマスタリングTCP/IPを手に取るのもよいのでは。

クラウドワークスも当たり前の社会インフラになるように開発を続けています。ということでクラウドワークスでは低レイヤー技術にも造詣の深いエンジニアを募集しています！

他にも活用事例を聞きたいのでSendGridを利用している会社さま同士で情報交換したいなという希望を書いて終わります。