なぜ現代社会においてSPFはこれほどまでに奇抜なのか
Sender Policy Framework（SPF）は長い歴史を持ち、その起源は1997年に遡ります。SPFプロジェクト自体は2003年6月に始まりました。しかし、SPFの仕組みにはいくつかの課題があり、それが混乱や誤解、あるいは誤った助言を招いています。本記事では、こうした問題点と、SPFのさらなる改善を妨げている障壁について考察します。
SPFにはフィードバック機能がない
SPFの顕著な課題は、導入担当者が外部からの情報をほとんど得られない状況で導入を行わなければならない点です。SPFには、DMARCのRUAやRUFのようなレポート機能やフィードバックメカニズムが欠けています。外部からのレポートがないため、SPFレコードは管理者が直接把握している情報のみに基づいて作成・維持されなければなりません。
DMARC導入以前の時代、人々はまず、自社のインフラに関する自身の知識に基づいてSPFレコードを作成していました。公開されたSPFレコードは、ドメインを代表してメールを送信するすべての正当なインフラを認証するという点で、必ずしも正確だったとは限りませんでしたが、少なくとも、管理者が把握していたインフラについては認証されていました。 受信メールを処理する人やシステムの観点から言えば、不正確なSPFレコードは、メールを配信するかどうかという判断をSPF処理のみに基づいて行うことができないことを意味していました。
時が経つにつれ、管理者やSPFレコードへのアクセス権を持つ人々は、既存のSPFレコードに新たな設定を追加していくようになりました。誤って正当なメールの送信を妨げてしまうリスクがあったため、設定を削除することはほとんどありませんでした。SPFブロック内の既存のエントリがまだ使用されているかどうかは誰にも分からず、その情報を追跡することは多くの場合現実的ではなく、時には不可能なことさえありました。
SPF – メール運用者による、メール運用者のための
SPFレコード（承認されたサーバーのリスト）は、インターネットドメインのテキストリソースとして存在します。つまり、メール事業者は、異なるインターネットドメインを使用することで、自社および自社のインフラを区別しているのです。
同じドメインを共有するメール送信者は、事実上、そのインターネットドメインを区別のない共有のレピュテーションプールに変えてしまい、メールの受信者はそのドメインからのすべてのメールを同じように扱わざるを得なくなります。
スパム的なマーケティングメールは、人間同士の企業間メールと見分けがつかないままであり、その結果、そのメールは、セキュリティ侵害を受けたベンダーから送信されたメールとも見分けがつかないままである。
メール事業者は、自社および自社のインフラを識別・区別するために、ドメインベースのSPFを利用しています。
SPFは電子メールのリバースパスを確認します
SPFの仕組みや、メール内でどのような項目をチェックしているかについては、しばしば誤解されています。この混乱により、長年にわたり、単にSPFを導入しようとしている技術に詳しくない人々に対して誤った指針を示す記事が数多く公開されてきました。
仕組みは次のとおりです。サーバーがメールを配信する際、送信元サーバーは、そのメールに関するエラー報告や通知を送信できるメールアドレスを共有します。このアドレスは「リバースパス」と呼ばれ、主にメール運用担当者によって使用されます。
受信サーバーは、リバースパスのドメインを使用してSPFレコードを検索します。そのSPFレコードに送信サーバーが記載されている場合、そのリバースパスは正当なものとなります。
今日、リバースパスには「バウンスアドレス」、「RFC5321.MailFrom」、「SMTP MAIL FROM」、「Return-Path」、「エンベロープアドレス」など、さまざまな呼び名があります。これほど多くの呼び方が存在するため、かなり混乱を招きかねません。
もう1つよくある誤解は、メール内に表示される「From:」アドレスをリバースパスと混同してしまうことです。この誤解により、リバースパスではなく「From:」アドレスに基づいてSPFレコードに設定を追加してしまうケースが生じています。
その結果、SPFレコードが途方もなく巨大になり、多くの場合、インターネット上の広範な領域に対して特定のドメインを代表してメールを送信する権限を与えてしまい、SPFレコードが肥大化してしまう。そして、人々は、SPFの仕組みに対する誤解に基づいて、この巨大化したSPFレコードを管理する解決策を模索することになる。
さらに、他者のドメインに代わってメールを送信するサービス（ニュースレター配信サービスや、Google SuiteやMicrosoft Office 365のようなホスティング型メールサービス、SaaSアプリケーションなど）が数多く存在する現状を踏まえると、SPFの仕組みやSPFレコードの管理方法を明確に理解することは、ますます複雑な課題となっています。
DMARC導入以前の時代には、本来許可されるべきではないインターネット上の領域まで許可対象に含めることでSPFレコードが肥大化し、SPFの処理制限を超えてしまうという事態が頻発していました。このエラーは、dmarcianの「SPF Surveyor」によって広く知られるようになった「DNSルックアップが多すぎます（Too many DNS-lookups）」という通知としてよく見られますが、SPFの仕組みに対する誤解から生じているため、正確な説明とは言えません。
DMARCは、SPFに対する人々の認識と導入方法を変えた
2012年にDMARCが登場すると、状況は一変し始めました。これにより、管理者は初めて、インターネット向けの電子メールにおいてドメインがどのように使用されているかに関する正確なデータを入手できるようになりました。DMARCレコードを導入することで、管理者はDMARCのレポートデータと照らし合わせてSPFレコードの正確性を確認し、SPFを適切に導入するための指針を得ることが可能になりました。この機能により、SPFの実装や運用がどれほど不十分であったかが明らかになり、SPFの世界に小さな革命が巻き起こりました。
DMARCは「ドメイン・アラインメント」要件も導入しました。このアラインメント要件により、メール事業者はサブドメインを使用して自身を識別することが義務付けられ、それによって事業者は自身だけでなく、管理しているインフラも特定できるようになります。DMARCの要件はSPFに大きな変化をもたらし、導入上の課題やSPFの改良につながっています。
インターネット全体で、不適切なSPFに関するガイダンスの是正作業は現在も続いています。依然として、解決方法についての明確な指針がないまま、「Too many lookups」エラーに直面する人が後を絶ちません。また、サードパーティのメール送信者にとっては、SPFの管理やメンテナンスに配慮した形で他者の代わりにメールを送信する方法に関する指針が依然として不足しています。さらに、DNS管理者にとっても、技術に詳しくない人々がSPFを容易に扱えるようにするための取り組みは、依然として困難な課題となっています。
より良いSPFを実現する上での障壁
現在では明確な指針が整備されているため、SPFの整備は、主に啓発活動やより良いガイダンスの提供、そしてSPFを取り巻く不明点を解消するための機能追加といった取り組みが中心となっています。
dmarcianでは、インターネット規模の問題とその解決策について考えることを大切にしています。その中で、私たちにとって非常に役立っている考え方のひとつが、より良いインターネットを実現するための障壁は何かを考察することです。
SPFに関しては、私たちが特定した障壁には次のようなものがあります：
- 教育：SPFの仕組みについて、本来なら信頼できる情報源から誤った情報が人々に伝えられてきました。「事実を正す」には多大な労力が必要です。
- 既得権益：インターネット全体でSPFレイヤーが完全に導入・維持されれば、脅威にさらされる可能性のある商業組織が存在します。独自のメールフィルタリング技術で利益を上げている企業は、その技術への依存度が低下することに直面することになるでしょう。また、SPFの理解や維持が現在困難であることに便乗して利益を得ている企業にとっては、自社のビジネスモデルに対する直接的な脅威となるでしょう。
- DNSの管理：ほとんどのDNSソフトウェアは、一般の人には理解しがたいレベルの専門知識を必要とします。インターネットドメインを購入できるからといって、TXTレコードやSPFの設定について理解しているとは限りません。
- レガシーインフラ：現在SPFを扱っている人々の多くは、DMARCを活用してSPF運用に役立てることができることを知らない。SPFに不慣れな人が、15年以上も遡る問題を抱えたレガシーシステムを目の当たりにすると、その課題に圧倒されてしまうかもしれない。
SPFは長い間存在しています。dmarcianはDMARC仕様が公開されて以来活動しており、私たちはDMARCを活用することで、メール環境の改善に取り組む人々がSPFをより容易に扱えるようにしています。
SPFについて理解するのに助けが必要な場合は、ぜひ当社のリソースをご利用ください。
この会話を続けたいですか？dmarcianフォーラムへどうぞ
