独自開発、送信ドメイン認証フィルタENMAの無償公開

ENMAの設計

IIJでは、送信ドメイン認証技術の仕様が決まってからあまり時間が経たないうちに、サービスとして送信ドメイン認証の提供を始めました。そのため、IIJの過酷なサービス環境での動作に耐えうるソフトウエアは、自社で開発する必要がありました。後にENMAと呼ばれるこのソフトウエアの開発には、IIJが提供する様々なメールサービスへの適用に向け、送信ドメイン認証技術の仕様への忠実さと、過酷な環境での動作に耐えうる堅牢さを特に重視して取り組みました。

MTA（Message Transfer Agent）を多段に組むタイプの大規模なメールシステムでは、インターネット境界で動作するMTAが、大量送信やサイバー攻撃の影響を最も受けやすくなります。この境界MTAは常に高負荷と隣り合わせの過酷な環境なので、ここで動作させるソフトウエアは、軽快かつ堅牢な、信頼のできるものでなければなりません。また、高負荷を避けるため、処理の内容もできるだけシンプルな方が望ましいです。
一方、送信ドメイン認証の、特にDKIM（DomainKeys Identified Mail）の検証処理では、メールをインターネットから受け取った直後、つまり自システムのMTAによって改変される前のメールに対して検証を行うと、検証エラーが発生しにくくなります。正確な認証結果を提供するという観点からは、境界MTAで検証ソフトウエアを動作させる構成が望ましいのですが、そのような構成は、境界MTAが高負荷に陥るリスクを高めることになります。
この、DKIM検証処理をメールシステムに組み込む際に、メールシステム側をDKIMの検証フェーズまでにメールの改変が発生しないような設計にするか、境界MTAでの動作に耐えうる堅牢さと軽快さを備えたソフトウエアを開発するかの選択が、メールシステム設計における重要なポイントになります。IIJでは後者を選択しました。後者の方がソフトウエア開発自体のハードルは高くなりますが、IIJの様々なメールシステムに組み込むことを考慮すると、それぞれのメールシステムに対して構成の見直しを行うよりは、全体としてのコストが低いと判断したためです。

ENMAの特徴の1つとして、SPF（Sender Policy Framework）とDKIMというまったく異なる認証方式の評価を、1つのモジュールの中で行っている点が挙げられます。ENMAはMTAと連携するモジュールとして動作するため、SPFとDKIMをそれぞれ別のモジュールとして実装するという選択肢もあったのですが、両方式の評価を行う1つのモジュールとして実装した方が、MTAと連携するためのオーバーヘッドが少なくて済む点を重視しました。また、システムへの組み込みが簡単になる、認証結果をまとめられるという副次的なメリットもありました。

設計や実装に際しては一貫して堅牢さを目指し、厳しい負荷テストを行いましたが、IIJのサービス環境での運用が初めから順風満帆だったわけではありません。しかし、開発者と稼働中のシステムとの距離が近く、即座にトラブルに対応できるという環境のおかげで、安定して稼働するようになっていきました。そして、IIJの過酷なサービス環境においても、長期に渡ってその存在を忘れるくらい安定して稼働していることこそが、堅牢さの何よりもの証明だと思っています。