センダー・ポリシー・フレームワーク（SPF）の歴史は古く、1997年まで遡り、SPFプロジェクト自体は2003年6月に始まりました。しかし、SPFの仕組みにはいくつかの課題があり、混乱や誤解、誤解を招くアドバイスにつながっています。この記事では、これらの問題と、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レコードを検索する。そのSPFレコードが送信サーバーをリストアップしていれば、そのリバースパスは正当なものである。
今日、リバースパスは、バウンスアドレス、RFC5321.MailFrom、”SMTP MAIL FROM”、Return-Path、エンベロープアドレスなど、多くの名前で呼ばれています。このような多くの命名規則は、かなり混乱を招く可能性があります。
もう1つのよくある誤解は、”From: “アドレス（メール内の目に見えるアドレス）をリバースパスと取り違えることである。この不正確さが、リバースパスではなく「From:」アドレスに基づいてSPFレコードにインフラを追加してしまう原因となっている。
その結果、SPFレコードはとてつもなく大きくなり、インターネットドメインの代理として送信することをインターネットの巨大なセクションに許可することになり、肥大化したSPFレコードになることが多い。そして、人々はとてつもなく巨大なSPFレコードを管理するための解決策を模索する。
現在では、他人のドメインに代わってメールを送信するサービス（例えば、ニュースレターサービス、Google SuiteやMicrosoft Office 365のようなホスト型メールボックスプロバイダー、SaaSアプリケーションなど）が数多く存在することも相まって、SPFの仕組みやSPFレコードの管理方法を明確に理解することは、複雑な問題となっている。
DMARC以前の時代の最終的な結果として、人々はしばしば認可されるべきではないインターネットの一部を認可し、SPFの処理限界を超えて膨れ上がったSPFレコードを公開した。このエラーは、dmarcianのSPF Surveyorによって広まった「Too many DNS-lookups (DNSルックアップが多すぎます)」という通知としてよく見られます。
DMARCがSPFの見方と導入方法を変える
2012年にDMARCが登場すると、状況は変わり始めた。管理者は初めて、ドメインがインターネット向け電子メールでどのように使用されているかに関する正確なデータを提供された。DMARCレコードが導入されたことで、管理者はSPFレコードの正確性をDMARCのレポートデータと照らし合わせ、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年以上前にさかのぼる問題のあるレガシーを目の当たりにしたとき、その作業は困難だと感じるかもしれない。
dmarcianはDMARCの仕様が発表されたときから存在しています。私たちはDMARCを利用して、メールをより良いものにするための作業をしている人たちがSPFをより簡単に使えるようにしています。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
