センダー・リライティング・スキーム
出典: フリー百科事典『ウィキペディア（Wikipedia）』
センダー・リライティング・スキーム（SRS: Sender Rewriting Scheme）とは、インターネットの電子メールを転送する際に送信者アドレスを書き換えてから転送する仕組みである。センダー・ポリシー・フレームワークと互換性が有る転送を可能にするために考案された。
[編集] 背景
歴史的に全てのメールサーバ（MTA: Mail transfer agent）は自分のホスト名を戻り経路に追加した。Simple Mail Transfer Protocol（SMTP）では、この戻り経路はMAIL FROMとして知られているが、戻り経路はSMTPの登場以前からSMTP以外にも使用されていた。例えばUUCPやUsenet（NetNews）における転送経路（bang path）が挙げられる。全てのネットニュース記事が、まだPathヘッダを含んでいる。
Path: news.server.example!other.example!not-for-mail
同じように、RFC 821における電子メールのエンベロープ（MAIL FROMのようなSMTP情報）では以下のとおりである。
- MAIL FROM:<not-for-mail@other.example>
- MAIL FROM:<@news.server.example:not-for-mail@other.example>
最初の段階は送信者を示し、2番目の段階は次のメールサーバを示すというようにされた。この例では、メールは2番目のメールサーバから3番目のメールサーバへ転送され、そこで最終的に配達されると仮定する。最後のメールサーバは、メールを中継するメール転送エージェント（MTA: Mail Transfer Agent）としてだけでなく、メールを受信者のメールボックスへ格納するメール配送エージェント（MDA: Mail Delivery Agent）としても知られる。MDAは、以下のように戻り経路をReturn-Pathヘッダの中に変換する。
Return-Path:<@news.server.example:not-for-mail@other.example>
SMTPはDNSのMXレコードをメールの配送先を決定するために使う。明確なソースルート
RCPT TO:<@news.server.example:user@destination.example>
のように、「other.example」からMTA「news.server.example」を経由しMDA「destination.example」へと、メールの配送経路を指定する事は扱いにくかった。更に悪い事には、新しい（1982年）アドレスの形式に、以下のような構成の古いUUCP転送経路（bang path）が、時々混在した。
destination.example!user@news.server.example other.example!not-for-mail@news.server.example
そして、その他様々な場当たり的なバグ修正と。SMTPとMXレコードはこれらを基本的に無用にした。従ってソース・ルーティングは1989年のRFC 1123において非推奨とされた。
RFC 1123における例外は、UUCPやNetNewsのように別ネットワークとのゲートウェイの場合である。そこでは、最初にメールを送信したMTAは、TCPで直接最終的な受信者に接続できない。この問題はMXレコードにより解決する。ゲートウェイでは、必要に応じてネットワーク越しの宛先アドレスに書き換えられる。MXはメールエクスチェンジャ（Mail eXchanger）の略である。
またメーリングリストも例外である。メーリングリストサーバでは、受信者から返されるエラーメール宛先を制御するため、全ての戻り経路がメーリングリスト管理者へ書き換えられる。メーリングリストサーバは、配送に失敗する受信者を自動的に退会処理する事ができる。この形のアドレス書き換えはRFC 821から知られており、今日においても使われている（RFC 2821はRFC 1123のSMTPの章を更新した）。
最後に重要な点だが、転送MTAはメールを転送する事と、エラーメールが返された場合にはそれをメール送信者へ返すという事に、責任を負う必要が有る。そしてその責任を負う場合に限り、別のアドレスへの転送では常にRCPT TOとしても知られる転送経路へのアドレス書き換えが行われる。RFC 821およびその後に定められた全てのSMTP仕様は、この状況に合わせて以下のような2つの結果コードを定めている:
251 user not local (attempted forward)
551 user not local (mail rejected)
プライバシー上の理由により、メールが転送されたか（251）転送されたなかったか（551）という事を含んだ、これらの結果コードは今日においては殆ど使われない。しかしその意味と第三者への転送結果は、それぞれ結果コード250とエラーコード550と全く同等である。
RFC 1123に記載のとおりソース・ルーティングが非推奨とされ、エラーメールの戻り経路も暗黙の内に非推奨とされた。かつて1989年の時点ではインターネットは比較的小さく、メール管理者（postmaster）は互いに知り合いである事も多かった。そして問題が起こった場合にはすぐに解決された。（例えば、5xxのエラーコードを伴う拒否など）問題を示すMTAが送信者のMXへ直接エラーメールを送信する事ができる場合には、エラーメールが幾つかの転送ホストを経由して返るような経路指定は、時間と帯域幅の無駄だった。
RFC 1123以降は、第三者へ転送するホストはRCPT TOアドレスの書き換えをするが、MAIL FROMはそのままの状態にされた。その副作用として、転送ホストから届いたメールを受け入れるMTAは、一般的にどのようなMAIL FROMアドレスでも受け入れる。
それから10年以上経ち、RFC 1123後のSMTPが抱えるこの欠陥をスパマーが不正に使い始めるようになった。今日では殆どのメールがスパムであり、殆どの戻り経路が詐称されている。スパマーは一般的に戻り経路を詐称する点は注目である。戻り経路のコールバック検査やその他の妥当性確認において不合格となる場合、多くのMTAはメールを拒否する。
RFC 2821は、配送責任を負うMTAが戻り経路に表示された発信元へ不達通知（エラーメール）を送付しなければならないと記載している。これは、ごく普通に詐称されたReturn-Pathが表示される世界での矛盾である。解決のための一つの方法は、信頼できる配送元からのメールだけ配送責任を負い、疑わしいメールは拒否する事である。
第三者中継を禁止していないメールサーバ（オープンリレー）と転送サーバは、この問題に関連して不運な立場に置かれる。殆どの場合オープンリレーや転送サーバは、MAIL FROMが発信者アドレスを表示する事や、最終的に配達が成功する事を保証できない。
RFC 1123の副作用として引き起こされたこのSMTP問題はセンダー・ポリシー・フレームワークによって解決が図られる。その要旨はSPFが転送を破壊する事であるが、実際にはそれは事実と異なる。SPF失敗（FAIL）は受信者の境界MTAの後ではなく、受信者の境界MTAにおいてSPFを検証する事を受信者に尋ねるだけである。
受信者は、SPFの本質である3つの戦略を用いた方法で、転送メールに対する手筈を整えられる。その3つの戦略とは:
- 例えば転送サーバホワイトリストなどを用いて、境界MTAの後ろではSPFを検証しない。
- SPF失敗（FAIL）時は当然拒否し、結果をエラーメールで通知（SMTPエラーコード551と同様）する。
- 転送サーバにおいてMAIL FROMを書き換える（メーリングリストと同様に）。
センダー・リライティング・スキーム（SRS: Sender Rewriting Scheme）は、3番目の戦略のための一つの方法である。
[編集] 参照
- センダー・ポリシー・フレームワーク (SPF)
- Bounce message (SMTP non-delivery report)
- Bounce Address Tag Validation (BATV)
- Simple Mail Transfer Protocol (SMTP)
[編集] 外部リンク
- libsrs2 home page
- Paper on SRS (PDF)
- Historical SRS draft by Meng Weng Wong (2003)
