Sender ID

Sender IDとは

Sender IDは、メールの送信元詐称（スプーフィング）に対抗するために提案された技術規格です。当初、MARID IETFワーキンググループによって提案され、Sender Policy Framework（SPF）とCaller IDを統合することを目指していました。しかし、8年間の実験フェーズを経た後、SPFが優位性を保ったため、Sender IDは廃止され、「歴史的（historic）」なステータスへと移行しました。主に実験的なRFC 4406で定義されており、RFC 4405、RFC 4407、およびRFC 4408で追加の定義がされています。

動作原理

Sender IDはSPFを基盤とし、いくつかの改良を加えられています。SPFは、メールの送信者を特定するヘッダーアドレスを検証しないという課題がありました。これらのヘッダーアドレスは、ユーザーに表示され、メールへの返信に使われることが多いですが、SPFが検証するアドレス（エンベロープ送信者アドレス、または「MAIL FROM」アドレス）とは異なる場合があります。

Sender IDは、この問題を解決するために、RFC 4407で「Purported Responsible Address（PRA）」という概念を導入しました。PRAは、メールの様々なヘッダーから、送信者の責任があると思われるアドレスを特定するヒューリスティックな規則に基づいています。

構文上、Sender IDはSPFとほぼ同じですが、`v=spf1`が以下のいずれかに置き換えられる点が異なります。

`spf2.0/mfrom`: SPFと同様に、エンベロープ送信者アドレスを検証します。
`spf2.0/mfrom,pra` または `spf2.0/pra,mfrom`: エンベロープ送信者アドレスとPRAの両方を検証します。
`spf2.0/pra`: PRAのみを検証します。

また、Sender IDは、SPFではサポートされていない位置修飾子という機能を提供しますが、実際の実装では位置修飾子はほとんど使用されていません。

実際には、PRAスキームは、正当なメールの場合には保護を提供しますが、スパムやフィッシングの場合にはほとんど役に立ちません。正当なメールの場合、PRAは通常、`From:` ヘッダーフィールドや、メーリングリストの場合は `Sender:` ヘッダーフィールドになります。しかし、フィッシングやスパムメールでは、PRAはユーザーには表示されない `Resent-` ヘッダーフィールドに基づいていることが多くなります。したがって、Sender IDを効果的なフィッシング対策ツールとして利用するには、メールクライアント（MUA）を変更し、Sender IDのPRAまたはSPFの`Return-Path:` ヘッダーフィールドを表示する必要があります。

SPFや`mfrom`は、スパムバウンスや自動応答の問題に対処するために鍛造された `Return-Path` を使用しますが、PRAはフィッシング詐欺に対処しようとしています。つまり、異なる問題に対して、異なる解決策を提案しているのです。しかし、10億件のメッセージ分析によれば、Sender IDとSPFは、約80%のケースで同じ結果になります。

標準化の問題点

PRAには、フォワーダーやメーリングリストがメールヘッダーを変更する必要があるという欠点があります。たとえば、 `Sender` や `Resent-Sender` ヘッダーを追加する必要があります。特に、後者はRFC 2822に違反し、RFC 822との互換性がないという問題があります。

SPFでは、メーリングリストは問題なく機能します。フォワーダーも、メールの内容ではなくSMTPの `MAIL FROM` と `RCPT TO` を変更するだけで済むため、SPFのサポートを希望しています。これは、SMTPフォワーダーは常にホスト名を `MAIL FROM` のリバースパスに追加するという、RFC 821の概念に基づいています。

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

2012年にSPFが実験的ステータスから標準へと移行した際に実施された調査によると、SPFを使用しているメールドメインは約40〜50%であったのに対し、PRAを使用するための要件を満たしているメールドメインは3%未満でした。

知的財産に関する論争

Sender IDの提案は、知的財産ライセンスの面で論争がありました。マイクロソフトがSender IDの重要な部分に関する特許を保有しており、GNU General Public License（GPL）と互換性のない条件でライセンスを付与していたため、自由ソフトウェアでの実装が困難であると指摘されました。2006年10月23日、マイクロソフトはこれらの特許をOpen Specification Promiseの対象としました。これは一部のフリーおよびオープンソースライセンスと互換性がありますが、GPLライセンスの最新バージョン（バージョン3.x）とは互換性がありません。

外部リンク

ASF Position Regarding Sender ID
IAB appeal about Sender ID's reuse of v=spf1 for PRA
Debian project unable to deploy Sender ID
IETF Decides on SPF / Sender-ID issue
Is Sender ID Dead in the Water?
MARID Co-Chairs Clarify Consensus Statement
MARID to close mailing list thread
Sender ID: A Tale of Open Standards and Corporate Greed?
SPF: SPF vs Sender ID
Sender Id Types in Different Countries
Sender Id

もう一度検索