Sender ID
その他の構文上の違いは、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%で同じ結果をもたらす。
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ポリシーの解釈を推奨していることだ。