実験を終えたSPF平坦化

「SPFフラット化」は、SPFサーベイヤーの初期リリースの一部としてdmarcianによって考案された。何年もの間、この機能は “実験的 “とされてきた。今日、私たちは実験を終了し、学んだことを共有する。

センダー・ポリシー・フレームワーク（SPF）の背景
今日のSPFチャレンジ
「DNSルックアップが多すぎる」という症状
SPFフラット化の危険性
SPFフラット化実験の終わり
DMARCデータを意思決定に役立てる
無料相談開催中！

センダー・ポリシー・フレームワーク（SPF）の背景

電子メール事業者は、インターネット上で電子メールを送信する際に、SPFを使用して自分自身とそのインフラを識別します。SPFは元々、2000年頃にJoe Job攻撃への対応としてメール事業者によって作成されました。当時、スパマーは正当なメール運営者になりすましてスパムを送信し、被害者を作っていました。正当なメール事業者は、メール事業者とそのインフラを識別する簡単な方法がなかったため、単にスパムを送信しただけで非難されました。

電子メール事業者は、その電子メール・インフラストラクチャを説明するためにSPFレコードを公開する。これらのレコードは、DNSに存在する特別にフォーマットされた文字列です。電子メールを受信するとき、電子メールサーバーは、ドメインのSPFレコードを取得するために、送信事業者の電子メールアドレス（リバースパス、バウンスアドレス、エンベロープフロム、MAIL FROMなどとして知られている）のドメインを検索します。

SPFレコードによって記述されたメールインフラが、メールを配信しようとしているインフラと同じであれば、受信者はメール送信事業者とそのインフラを特定することに成功したことになります。

今日のSPFチャレンジ

SPFレコードは、3つの異なるメンテナンス上の課題に直面している。

SPFの歴史は非常に長い。
SPFがどのように機能するかは、経験豊富なIT技術者でさえ、ほとんど誤解されている。
DMARCと相互運用するために、SPFは、エンドユーザーが電子メールの “From: “ヘッダーに表示されるドメインに電子メールのオペレータが関連付けられることを要求する。

SPFは20年以上前から存在している。何年もの間、人々は自分のメール送信インフラをリストアップすることに全力を尽くしていた。サーバーはSPFレコードに追加されましたが、サーバーがまだ使われているかどうかを判断する簡単な方法がなかったため、削除されることはほとんどありませんでした。

さらに悪いことに、SPFの仕組みはほとんど誤解されている。電子メールのオペレータは、電子メールを書いたり送信したりする人とは明らかに異なるが、よくある誤解は、SPFはオペレータのドメインではなく、電子メールの「From:」ドメインをチェックするというものである。

このような誤解は広く蔓延しており、オペレータが実際にメール送信に使用していないインフラでSPFレコードが肥大化する原因となっています。最悪のケースでは、メールベンダーがクライアントのドメインを使用して自分自身を識別するため、クライアントはメールベンダーにメール操作の対価を支払っているにもかかわらず、”メールオペレーター “の役割を引き受けることになります。

DMARCが登場する以前は、メールオペレータは、自分自身の業務を指すリバースパスを使用して自分自身を識別することができました。メールオペレータが、メールアプリケーションに表示される “From: “ドメインに関連付けられる必要はなかった。

しかし、SPFはDMARCコンプライアンスを達成するために使用できる2つの技術のうちの1つであり、もう1つはDKIMである。SPFを使用してDMARCコンプライアンスを構築するために、DMARCは、電子メールオペレータのリバースパスが、電子メールの「From:」ヘッダーに表示されるものと同じドメインまたはサブドメインであることを要求します。DMARCと相互運用するために、あまりにも多くのメールベンダーがクライアントのトップレベルドメインを使用して自分自身を識別してしまい、上記のようなSPFレコード

の肥大化を引き起こしています。

「DNSルックアップが多すぎる」という症状

SPFの課題が積み重なると、SPFレコードは不正確になり、不必要に長くなり、SPFに内蔵された処理限界に達してしまう。

dmarcianのSPF Surveyorは、SPFに組み込まれた処理限界（一般に「Too many DNS lookups」問題と呼ばれる）を明らかにした最初の公開ツールです。簡単に言うと、SPFの仕様は、SPFレコードを処理してメールを配信しようとしている間に、受信サーバーに多くのリソースを消費させるようなSPFレコードから、受信メールサーバーを保護しようとするものです。

SPFレコードがToo Many DNS Lookups問題にぶつかる理由は以下の通りです。

SPFレコードのエントリを削除することなく、SPFレコードに何かを追加する、
SPFの組み込み制限に達するまで、トップレベルのSPFレコードに「include:」インフラを追加するよう指示される。
DMARCと相互運用する必要があるため、SPFレコードが極端に肥大化する可能性がある。

dmarcianでは、「DNSルックアップが多すぎる」というエラーとして最も一般的に経験される大きくて扱いにくいSPFレコードを、より大きな問題の症状として理解しています。これには、SPFの動作に対する誤解、組織を代表してメールを送信するベンダーの管理が不完全であること、および組織内でのベストプラクティスに基づいたメールセグメンテーションの欠如が含まれます。

SPFフラット化の危険性

SPF平坦化は、「Too Many DNS Lookups（DNSルックアップが多すぎる）」エラーを回避しようと試みますが、そもそもエラーの原因となった根本的な問題には対処しません。根本的な問題に注意を払うことなくエラーを解消しようとすると、悪い方向に向かう可能性がある。組織のITスタッフは、知らず知らずのうちに、組織のトップレベルドメインを使用して電子メールを送信するすべてのベンダー/電子メール運用者の動作とインフラストラクチャに責任を負うことになります。

レピュテーションの観点から、受信者は異なるタイプのメールを簡単に区別することができません。例えば、請求書とニュースレターは同じドメインを共有しているため、受信者が同じドメインから送信されたメールを見ただけで、スパムメールのニュースレターが請求書をスパムフォルダーに入れてしまう可能性があります。
運用の観点からは、ベンダーは組織の代わりに送信するメールを効果的に管理するために必要なシグナルを受け取ることができません。例えば、ベンダーがバウンスメッセージが発生するような悪い受信者にメールを送信した場合、そのバウンスメッセージはベンダーではなくITスタッフに流れます。原則として、ITスタッフはこの種のシグナルをベンダーに転送しないため、ベンダーは「盲目的に飛び回る」ことになり、次第に組織の評判に悪影響を与えることになる（上記参照）。
セキュリティの観点からは、肥大化したSPFレコードによる過剰な認証は、「SPFレコードの不要なエントリーが攻撃面を作り出す」という言い方をする。もし敵対者がSPFレコードに記載されているインフラに侵入（または単にレンタル）できれば、その敵対者はDMARCに準拠したメールを送信することができ、効果的にコントロールを回避し、そのコントロールを利用して組織の評判を乗っ取って詐欺を行うことができます。

サイバー攻撃における電子メールの支配的な役割を考えると、根本的な問題に対処せずにSPFの対症療法的なエラーメッセージを回避することは、情報セキュリティとリスク管理の専門家の使命に反する。

dmarcianは、SPFフラット化を製品やサービスに変える誘惑に抵抗しています。主に、組織がベストプラクティスを採用し、ベンダーやメールストリームをセグメント化すると、SPFフラット化の必要性がなくなるためです。この方向に進む組織は、より良いコントロール、攻撃対象面の縮小、運用効率、およびベンダーを区別し、潜在的なサイバーインシデントの影響を限定することによる評判の回復力を得ることになります。

SPFフラット化実験の終わり

dmarcianは、一部のITチームが、チケット対応や既存グループのサポートにとどまらない領域で変化に影響を与える能力に制約があることを学びました。これらのチームは、ビジネスプロセスを改善したり、セキュリティやリスク管理の問題に取り組んだりする権限を与えられていないため、dmarcianスタイルのベストプラクティス（グループをまたがる可能性がある）の展開には手が届きません。

このようなチームにとって、dmarcianは「SPFフラット化」を、ITチームが経験する現在の負荷や問題を軽減できるベストプラクティスを採用するために組織が整うまでの一時しのぎの解決策と見なしている。この「一時しのぎ」の部分は、このような状況にあるITチームが、他のグループと協力してより実質的で持続可能な変更を展開するためには、SPFエラーのない時間が必要であることを認識している。

dmarcian氏がこのような状況で感じる危険は、ITチームがその場しのぎの解決策をそのままにしておき、根本的な問題（これは間違いなく、彼らに対処する権限はない）の解決に手をつけないことである。