透過型SMTPプロキシによる送信メールの可観測性向上

この記事は、2024年1月17日(水)に行われた「さくらの夕べ in 福岡」における発表を編集部にて記事化したものです。

はじめに

小田知央(おだともひさ)と申します。@linyowsというIDで活動しております。福岡で生活していて、Fukuoka.goというコミュニティを主催しています。最近コロナが明けて、やっとオフラインでできるようになったので、すごく楽しいコミュニティを今後もやっていこうかなと思っております。趣味は筋トレとテニスです。

さくらインターネットには去年の11月に入ったばかりなので、まだ1〜2か月ぐらいしか経っていないんですけども、本日は発表させていただきます。

発表の概要

早速本題に入るんですけども、アウトラインとしては、まずメールのシステムの現状をおさらいした上で、メールホスティング特有の事情と、そこにある課題の話をします。そして演題にもなっている透過SMTPプロキシによる送信メール可観測性向上の提案を行い、最後に今後の課題として、経路暗号化強制対応と複数IP使い分けの課題を話していきます。

メールシステムの現状

メールの話をすると、「いやもうオワコンでしょ。使わんでしょ」っていう話をよくされるので、なかなかつらい気持ちになるんですけども、一応おさらいまでにメールシステムの構成をお話しします。

図の左側にいるアリスが右側にいるボブにメールを送るとなると、途中はSMTPで通信して、最終的にはPOP/IMAPで受け取ります。この間にさまざまなメールサーバーのコンポーネントが登場します。ウェブと違ってサーバークライアントではなく、相手方がいるっていうところで多くのコンポーネントが必要ですし、プロトコルもSMTPとPOP/IMAPというのをいろいろ使い分けているっていう状態です。

最近のメールにおけるセキュリティの問題としては、例えば受験のメールが届かなくて問題になっているとかありましたけども、メールシステムを運用するっていうところが結構難しいんですよね。セキュリティに関しても同じで、メールの送信者は現状では詐称できるので、送信者が正しいかどうかを確認できないといけないし、メールが盗聴されていたり改ざんされているようなことはないという状態にしないといけないとか、あとは自分のふりをして誰かが勝手にメールを投げているとかっていうのを防止しないといけないので、通常のメールシステムにおいても追加の技術が必要になってくるわけですね。

最近よく言われてるのが送信ドメイン認証で、SPF、DKIM、DMARC、この3つをちゃんと設定しましょうということが口酸っぱく言われてるんですけども、なかなか難しいのでメールが届かないということも起きてしまうんですね。あとは経路暗号化ですね。ウェブの業界ではもうTLSがもう標準になってますけども、メールにおいてもTLSを標準にしていかないといけないという流れで、TLSやMTA-STSといった、暗号化されてることを強制するような技術っていうのがあるのでそれを導入していかないといけません。それに加えてメールはサーバ間をホップして送られるものなので、その転送の対応が必要になってきて、そこに関してもSPFだったりDKIMの問題があるので転送の対応も別で考えないといけません。メールにまつわるセキュリティは結構大変であるってことですね。

先ほどの図にセキュリティの関連のコンポーネントを増やしていくと、めっちゃいろいろ複雑になります。メールシステムがそもそも、メールを送れればいいというところからスタートしていて、それが安全に送れるかどうかっていうのは後から技術が追加されてきているので、このような複雑なシステムになってしまっています。

それから、先ほど話したように、普段皆さんがお仕事をする上ではSlackなどを使っているので、メッセージングの手段としてもうメールにあまり頼らなくなってきてるんですよね。それに加えてメール配信っていうのは安価にできるので、マーケティングのツールとして、いろいろなECサイトが広告メールをバンバン送りまくってきます。スパムっぽいけど、でもこれを送り続けることによって売り上げは伸びるので、迷惑と思われても送るみたいなことがあります。そうすると、皆さんのメールInboxには広告のメールが大量に来ていて、メール使いづらいみたいなことを思いつつも放置するので、未読が膨大になるようなことがあると思います。

あとはやっぱりセキュリティのインシデントがあって、使ってるサービスのメールとパスワードが流出しましたってなると、いろんな大量のスパムメールが着信するっていうこともあります。というわけで、メールに対するって全体的な信頼性がどんどん失われているっていうのがあるんじゃなかろうかと私は思っております。

一般的なスパムメール対策って何だろうと考えたときに、一番多いのはスパムフィルターですね、OSSだとSpamAssassinとかAmavisがありますけども、このスパムフィルターを使うことで、迷惑メールが迷惑メールフォルダに入ります。あとはDNSBLというブロックリストを使ってメールを受け取らなくするっていうものですね。他にも、メールの流量が多いとスロットリングといって一時的に受信拒否をしたり、レスポンスを著しく遅延させてスパムメールを送らせないようにするタールピットという手法もあります。過去にはグレイリストっていう手法も多く見られたと思います。再送を要求して、botから送られていないことを確認するやつですね。

最近だとGmailがちょっと本腰を上げて、このスパムメールを削減するために、2024年2月から送信ドメイン認証の強制と経路暗号化の強制と、加えてここがたぶん新しいところだと思うんですけどワンクリック配信解除の強制ですね。例えばECサイトで登録した際に、ECサイトからメールを送信していいですよっていう設定にしたとして、後々になってやっぱりこれいらないってなったときにすぐ解除できるようなワンクリック配信解除をやりなさいということを言われていて、それができなければ受信拒否になるっていうやつですね。

メールホスティングの事情と課題

ここからはメールホスティングの事情と課題に入っていきます。

メールホスティングは送信のみの話なんですけども、複数のドメインを収容してビジネスをすることになるので、ドメイン単位、もっと言えば細かくアカウント単位とかでIPアドレスを振り分けるってことは現実的ではないわけですね。なので基本的には、送信に使用するIPアドレスは集約したいっていうところがあります。ただ集約しすぎると、例えば乗っ取られたアカウントがスパムメールをバンバン送って、そのためにこのIPアドレスからはもう受け付けないというIPスロットリングが発生したときに影響範囲が大きくなるという問題があります。

同様にメール送信キューも集約しすぎると、何か悪さをしたメールに関して滞留が発生して、影響が全体的に波及するということになるので、かなり運用が大変になります。

これら2つの事情を考慮すると、メールキューは分散して、IPアドレスは適切な分量で集約するのが良いっていう考えになっていきます。

そうすると、送信MTAをコンテナ化して、ホストごとにIPアドレスを集約して、キューは分散しつつもIPアドレスをある程度まとめることが考えられます。

そこで何が起きるかっていうと、複数のMTAを分散して使うので、ログを集約することになるんですけども、ログをパースして使わないといけないので、システム全体で何が起きてるのかっていうのは把握しにくくなるんですね。なので、システム全体で何が起きているかっていうのをリアルタイムで知りたいというところが課題としてあります。もっと言えば、把握した現状に対して自動的に修復するっていうところもやっていきたいです。例えばIPスロットリングが発生していて、それを検知して、発生の引き金となったドメインからの送信を止めて、他のドメインに関しては正しい使い方をされているので、送信に使うIPアドレスを付け替えるっていうのは運用的にはあると思うんですけども、その辺をシステム的にやってしまうことができればいいなと考えています。

透過プロキシによる送信メール可観測性向上の提案

そこで、透過プロキシによる送信メール可観測性の向上の提案です。

先ほどコンテナ化したホスト内でMTAを分散させるっていう話があったと思うんですけども、メールが出て行くところに透過型のプロキシを置きます。ルーティングを変えて透過型プロキシに全部行くようにして、そこから全部出て行くっていうようなことをやります。そうすると、出て行く通信の内容が全部取れるので、それを全部DBに蓄積します。これによって、リアルタイムで何が発生してるのかを検知できますし、検知したものに対する対応として何か処理を行うということが簡単になります。透過型プロキシは同一ホスト内に設置するため、このコンテナのMTAとプロキシ間は平文でも通信できます。

一般的なSMTPプロキシは、私の観測する範囲では送信用はないと思っておりまして、そこで今回はGo言語で自作しました。WARPというものです。Githubに置いてあるので、興味がある方は見てください。

仕組みとしては、MTAのプロセスから出ていく25番ポートを宛先とするパケット(先ほどの図で外部に出ていくパケット)を、iptablesでDNATして全部ねじ曲げてしまって、それを今回開発したWARPというミドルウェアで受け取って、本当の宛先をシステムコールから取り出すっていうふうになっております。なので対向のMXからのEHLOレスポンスに含まれるSTARTTLSを削除して、バックエンドのMTAに返すっていう処理が必要になっていますので、そのような実装になっております。相手のMXとはプロキシがTLS接続をするっていうことですね。

このミドルウェアWARPにはフックイベントが作ってあるので、プラグインからいろいろな処理の追加が可能となっております。WARPはカナリアリリースで本番に導入したという実証もあります。

アーキテクチャ的にはこんな感じですね。左側がメール送信エージェントで、サブミッションポートに接続してメールを送信するっていうものです。MTA的には外部のMXに対して送っているんだけども、自動的にWARPの方に転送されて、WARPが外のMTAと接続して送信します。WARPにはプラグイン機構があって、現在はFileとMySQLとSQLiteとSlackっていうのを用意してるんですが、さまざまな処理ができるという形になっております。

どんなデータが取れるのかっていうと、これはMySQLとSQLiteプラグインの例なんですけども、コネクションテーブルとコミュニケーションテーブルがあって、コミュニケーションテーブルの中ではSMTPのコマンドが全部入っているっていうものです。詳しい人ならヘッダー情報も全部入っていくんじゃないかというのがわかると思うんですけども、今は研究段階なので全部入ってきます。この辺は、サービスに適用させるってなると、いろいろなプライバシーの問題とかも出てくるので、消すようにしたりとかっていうのが必要になってくると思います。

これは私達の研究で使っている研究環境での事例です。有名なメールベンダーに対して、SMTPセッション数10で100通を送るっていう実験をやったんですけども、何か面白いものがあったので、いくつか挙げております。一つは同時最大接続数制限に引っかかったっていうところですね。あとはレピュテーションの低さから受信拒否の判断をされました。

それから、スロットリングといいますか、応答遅延が観測されたっていうことがありました。このように、コマンドを発行して、それがどれぐらいで返ってくるかっていうところも記録されるので、かなり状態がわかるような仕組みになっているかと思います。

経路暗号化強制対応と複数IP使い分けの課題

今後の課題になるんですけども、TLS通信はこの透過SMTPプロキシがやるので、経路暗号化の強制、つまりMTA-STSっていうのはこのプロキシがやることになります。よって、その実装をしないといけないっていうのがあります。それから、最初に申し上げた理想であるいろいろな自動化、IPの付け替えや高度な機能というのはこれから作っていかないというといけないという課題があります。

発表は以上です。ありがとうございます。

質疑応答

質問者A：これすごく面白いんですけど、わざわざ各MTAをコンテナで動かすよりも、トータルな新しいMTAを作っちゃうっていう方向の方が正しいような気がするんですけど。

小田：なるほどですね。もちろんそれでもいいと思うんですけども、やはり既存資産というのはなかなかその変えにくいものであるということが前提にあるので、既存資産を生かしながら、うまくできる方法はないかなというところでこういう手法を提案しています。

質問者A：単純にログを集めるだけだったら、例えばログコレクターみたいのを使うっていう方法の方が楽ですよね。

小田：そうですね。

質問者A：でもやっぱり細かくSMTPのやり取りを見たいからプロキシを立てたということですか？

小田：そうです。

質問者B：冒頭の方で最近メールってあんまり使われないよねっていうふうな話だったんですけど、最近パスワードリカバリーとかTeamsのログインとかで、やたらメールで解錠コードを送らせるっていうのがあって、結構あれが届かないっていう事象を聞いたりするんですよね。そういうときにこういう透過型プロキシがあれば、トラブルシューティングをするときにすごい楽になるんじゃないかと思ったんですけどいかがでしょうか。

小田：そうですね。メールを使わないっていう話があったとしても、やはりそういうリセットだったりパスワード再設定というのはメールを使ってることが結構多いので、透過型プロキシを入れるとデバッグはしやすくなるんですけども、やはりセキュリティ的な、あるいはプライバシー的な観点で情報を取得していいっていうのを、使ってるお客さんに対して許可を得られないとなかなか情報を出力しにくいっていうのはあるので、サービスのポリシーにはなると思うんですけど、難しいかなって思ったりはしています。

質問者B：確かに、通信の秘密ってちょっと難しいなと思います。

発表を終えて

JANOG53の開催期間中でしたので、想定よりも多くの方がイベントに参加され発表を見てくださった気がします。発表後の質問はもちろんのこと、懇親会においても多くの方から声を掛けてもらって質問を受けました。ありがとうございます！ このような普段関わりがない人との出会いが生まれるのは、オフラインミーティングの良さだなと改めて思いました。また、私の口頭発表をこのような記事にしていただいた、さくらのナレッジ編集部にも大感謝です。