|
===================================== 〔語彙分解〕的な部分一致の検索結果は以下の通りです。 ・ ー ： [ちょうおん] (n) long vowel mark (usually only used in katakana) センダー・リライティング・スキーム（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 5321は、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 5321は、配送責任を負うMTAが''戻り経路に表示''された''発信元''へ不達通知（エラーメール）を送付しなければならないと記載している。これは、ごく普通に詐称されたReturn-Pathが''表示''される世界での矛盾である。解決のための1 つの方法は、信頼できる配送元からのメールだけ配送責任を負い、疑わしいメールは拒否する事である。 第三者中継を禁止していないメールサーバ（オープンリレー）と転送サーバは、この問題に関連して不運な立場に置かれる。殆どの場合オープンリレーや転送サーバは、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番目の戦略のための1 つの方法である。 抄文引用元・出典: フリー百科事典『 ウィキペディア（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情報）では以下のとおりである。」の詳細全文を読む スポンサード リンク
|