Wikipedia

センダー・リライティング・スキーム

センダー・リライティング・スキーム（Sender Rewriting Scheme,SRS）とは、インターネットの電子メールを転送する際に送信者アドレスを書き換えてから転送する仕組みの一つ。SPF認証を破ることなく電子メールを転送する目的で、2003年に考案された[1]。

背景 編集

メールアドレス変更やメーリングリスト変更を含む多くの場合、メール転送エージェント(MTA) はローカルメールボックス宛てでなくとも転送の必要がある電子メールを受け入れる。こうした場合、誰が関連バウンスメールを受け取るのに相応かという疑問が生じる。一般に、それは作成者または転送自体の管理者（個人ないし法人）のいずれかである[2]。作成者にバウンスを送信するのは管理上単純なことで、元の送信情報（エンベロープ）を保持するだけで実現できる。ただし、作成者アドレスが厳密な SPFポリシー(-all)の対象でターゲットMTA がそれを強制実行する場合、転送処理は拒否されてしまう。回避策として、現在のMTAにバウンスバックを指示する一時的なバウンスアドレスをその時々に合成することが可能である。この手法は元のアドレスエンベロープを回復するため、バウンスが到着した場合にリバースパスを辿って転送させることが可能で、この時は送信先エンベロープが空になる。

他の回避策もあるが、SRS はかなり一般的である。パスを逆にするという考え方は、電子メール当初のルーティング処理に似ている（後述を参照）。


書き換え手法 編集

SRSは、書き換えられたアドレスのローカル部分で元の送信先情報をエンコードするのと同様の可変エンベロープ・リターン・パス(VERP) 形式である[1]。example.comが当初bob@example.com宛ての電子メールを新たなアドレス<bob@example.net>:に転送することを考えると、次のようになる[3]。 

   当初
   送信者エンベロープ:     alice@example.org
   受信者エンベロープ:  bob@example.com

   書き換え後
   送信者エンベロープ:     SRS0=HHH=TT=example.org=alice@example.com
   受信者エンベロープ:  bob@example.net

書き換え後のVERPに関して、@より前にあったローカルパート(alice)はドメイン名(example.org)の後ろに移動され、さらにプレフィックス[注釈 1](SRS0)、ハッシュ(HHH)、タイムスタンプ(TT)が追加される。これは運用上の違いを反映している。VERPアドレスへの最終的なバウンスは書き換えドメイン内で処理され、偽造されたメッセージはせいぜい一部ユーザーの登録解除ができるだけで、過去数十年間に大事件が確認されていないある種の悪用である。代わりに、SRSはバウンスの可能性をAliceに再送信することを目的としており、そのため偽造されたバウンスは書き換え送信者から最初に発信されたと思われるスパムを注入するのに魅力的な手法になる可能性があるﾍﾝ)。

  • ローカルパート（上の例だとalice）は、等号（=）を含んでいる場合があるため移動される。よって書き換えられたローカルパートの端にそれを配置すると、後半部分が解析可能となる。
  • タイムスタンプ (TT) は、数日後にアドレスを無効にするため 有効1 日である。計算されたUNIX時間⁄(60×60×24) mod 210はbase32の二文字として保存可能であり、再利用期間は約3.5年である。
  • HMAC (HHH) は、ローカルシークレットに対して計算されるが使用されるその一部のみである。例えばbase64表現の最初の四文字を格納すると24ビットの暗号強度となる。バウンスが到着した場合に備えて、ハッシュはそれを生成したドメインによってチェックされる。
  • プレフィックス(SRS0)は、書き換えられたものから正規アドレスを明確にする意味合いがある。SRS0=で始まる電子メールアドレスを持つユーザーがいないかを確認するかはexample.com 次第である。

SRSには、マルチホップにおいて既に書き換え済みのアドレスを再度書き換えるために使用される別のプレフィックスSRS0がある。 example.comがメールを順番に転送する必要がある場合、別のタイムスタンプを追加したり元のローカルパート（alice）を繰り返さなくともよい。 つまり、新なた転送先にはそれぞれ、独自のハッシュ（HHH）と前の転送ドメイン名だけを追加する。 

   更なる書き換え
   送信者エンベロープ:     SRS1=HHH=example.com==HHH=TT=example.org=alice@example.net
   受信者エンベロープ:  bob@further.example

データベースの代わり 編集

データベースの使用は、書き換えられたローカルパートにユニークキーを置くだけで十分であるため、書き換えられたアドレスの増大を確実に制御できる。また、要望に応じて再送信プロセスにおける一定の匿名性を実現させる。ただし、データベースは集中化を必要とし、単一障害点となる[5]。

ヘッダーフィールドの代わり 編集

このほかに、長い書き換えアドレスをメッセージ ヘッダーのどこかに格納することもありうる。DKIM署名の i= タグは、セキュリティを大幅に向上させるため適した場所になる場合があり、この技術は2013年時点でまさしく観察されている[6]。バックアップ機構がない限り、バウンスメッセージは標準フォーマットの場合にのみ機能する[7]。

歴史的背景 編集

従来、全てのメール転送エージェント(MTA) が自分のホスト名を戻り経路に追加した。簡易メール転送プロトコル(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情報）では以下のとおりである。

  1. MAIL FROM:<not-for-mail@other.example>
  2. MAIL FROM:<@news.server.example:not-for-mail@other.example>

1段目は送信者を、2段目は次のMTA等を反映したものである。この例では、メールが2番目のMTAから3番目のMTAへ転送され、そこで最終的に配達されると仮定する。最後のMTAはメール配信エージェント(MDA)としても知られ、メールを受信者のメールボックスへ格納する。MDAは、以下のように戻り経路をReturn-Pathヘッダの中に変換する。 

Return-Path:<@news.server.example:not-for-mail@other.example>

SMTPは配送ルート決定にMXレコードを使用する。 

RCPT TO:<@news.server.example:user@destination.example>

こうしたソースルートの明示をしてother.exampleからMTAnews.server.exampleを経由してMDAdestination.exampleへとメールの配送経路を指定するのは面倒であった。更に悪いことに、1982年の新たな形式には以下のような構成の古いUUCP転送経路(bang path)が時々混在し、これがその場しのぎの応急処置となっていた。 

destination.example!user@news.server.example
other.example!not-for-mail@news.server.example

SMTPとMXレコードはこれらを基本的に無用にした。従ってソースルート指定は1989年のRFC1123において非推奨とされた。

RFC 1123における例外は、UUCPやNetNewsのように別ネットワークとのゲートウェイの場合である。そこでは、最初にメールを送信したMTAは、TCPで直接最終的な受信者に接続できない。この問題はこれは、必要に応じてゲートウェイで外部アドレスを書き換えるMXレコードにより解決されることとなった。MXはメールエクスチェンジャ(Mail eXchanger)の略である。

またメーリングリストも例外である。メーリングリストのサーバでは、受信者から返されるエラーメール宛先を制御するため、全ての戻り経路がメーリングリスト管理者へ書き換えられる。メーリングリストサーバは、配送に失敗する受信者を自動的に退会処理する事ができる。この形のアドレス書き換えはRFC821から知られており、今日においても使われている（RFC5321とRFC282は、RFC1123にあるSMTPの章を更新したもの）。

最後に、最後に、少なくとも別アドレスへの転送は、転送MTAがメール転送および起こり得るバウンスメッセージを送信者へと返送する両方の責務を果たす場合にのみ、RCPT TOとして知られる転送パスのアドレスを書き換えることで常に機能することとなった。RFC821と以後全てのSMTP仕様は、この状況に合わせて以下のような2つの結果コードを定めている:

251 user not local (attempted forward)
551 user not local (mail rejected)

プライバシー上の理由により、メールが転送されたか（251）転送されたなかったか（551）という事を含んだ、これらの結果コードは今日においては殆ど使われない。しかしその意味と第三者への転送結果は、それぞれ結果コード250とエラーコード550と全く同等である。

RFC1123に記載のとおりソースルート指定が非推奨とされ、エラーメールの戻り経路も暗黙の内に非推奨とされた。1989年当時のインターネットは比較的小さく、メール管理者（postmaster）が知人同士である事も多かったので問題もその時々で解決された。（例えば、5xxのエラーコードを伴う拒否など）問題を示すMTAが送信者のMXへ直接エラーメールを送信する事ができる場合には、エラーメールが幾つかの転送ホストを経由して返るような経路指定は、時間と帯域幅の無駄だった。

RFC1123以降は、第三者へ転送するホストはRCPT TOアドレスの書き換えをするが、MAIL FROMはそのままの状態にされた。その副作用として、転送ホストから届いたメールを受け入れるMTAは、一般的にどのようなMAIL FROMアドレスでも受け入れる。

それから10年以上経ち、RFC1123以降のSMTPが抱えるこの欠陥をスパム送信者が不正に使い始めた。今日では大半のメールがスパムであり、大半の戻り経路が詐称されている。スパム送信者は一般的に戻り経路を詐称する点が特徴であり、戻り経路のコールバック認証やその他の妥当性チェックが怪しい場合、多くのMTAはメールを拒否する。

RFC5321は、配送責任を負うMTAが戻り経路に表示された発信元へ不達通知（エラーメール）を送付しなければならないと記載している。ただし、発信元コンテンツが敵対的な場合（スパムやウイルスメール）またはメッセージが偽造されている場合(RFC5321の6章）、バウンスメッセージが抑制される場合がある。現在の偽造検知手法はいずれも、メールボックス所有者がその情報を提供する必要がある。基準を提供しないなら、バウンスメッセージをバックスキャッターとして分類できるようにするべきではないが、そうすべきだと誤解している人もいる。

オープンリレー（第三者中継可能なメールサーバ）と転送サーバはこの問題に関連して不運な立場にあり、通常これらはMAIL FROMアドレスが発信者を表示することを保証できず、最終的に配達が成功する事も保証できない。

RFC1123の副作用として引き起こされたこのSMTP問題はSPFことセンダー・ポリシー・フレームワークによって解決が図られる。その要旨はSPFが転送を破壊する事であるが、実際にはそれは事実と異なる。SPF失敗（SPF FAIL）は受信者の境界MTAの後ではなく、受信者の境界MTAにおいてSPFをチェックするよう受信者に要請するに過ぎない。

受信者は、本質的に以下3つの戦略でSPFと連携するやり方で転送を調整している。

  1. 例えば転送ホワイトリストなどを用いて、境界MTAの後ろではSPFを検証しない。
  2. SPF失敗時はバウンスにて結果(SMTP error 550)を通知して、ただ拒否をするだけ。
  3. 転送サーバにおいてMAIL FROMを書き換える（メーリングリストでやっているように）。

センダー・リライティング・スキームは、3番目の戦略のための1つの方法である。

関連項目 編集

脚注 編集

注釈 編集

  1. ^ メールアドレスの先頭部分に付加し、何らかの意味や情報を表す短い符号部分[4]。

出典 編集

  1. ^ a b Meng Weng Wong (2003年6月). “Sender Rewriting Scheme For Forwarders and Remailers To Rewrite Sender Addresses”. OpenSPF.org. 2013年7月5日閲覧。 “SRS can be viewed as a form of VERP.”
  2. ^ "Mailing Lists and Aliases". Simple Mail Transfer Protocol (英語). IETF. October 2008. sec. 3.9. doi:10.17487/RFC5321. RFC 5321. When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list.
  3. ^ Shevek (2004年6月). “The Sender Rewriting Scheme”. Anarres.org. 2013年7月5日閲覧。
  4. ^ IT用語辞典 e-Words「プレフィックス 【prefix】 プリフィックス / 接頭辞」
  5. ^ Meng Weng Wong (2004年1月). “SRS requirements”. spf-discuss mailing list. Monharc.org. 2013年7月5日閲覧。
  6. ^ Laura Atkins (2013年6月). “Weird i= in client mail”. ietf-dkim mailing list. Mipassoc.org. 2013年7月5日閲覧。
  7. ^ Michael Deutschmann (2013年7月). “That weird i= is most probably EDSP”. ietf-dkim mailing list. Mipassoc.org. 2013年7月5日閲覧。

外部リンク 編集

「https://ja.wikipedia.org/w/index.php?title=センダー・リライティング・スキーム&oldid=97769797」から取得