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

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

1. 背景
-----

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

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

2. 書き換え手法
---------

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

書き換え後 送信者エンベロープ}}: 受信者エンベロープ}}:

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

ローカルパートは、等号を含んでいる場合があるため移動される。よって書き換えられたローカルパートの端にそれを配置すると、後半部分が解析可能となる。
タイムスタンプ  は、数日後にアドレスを無効にするため 有効1 日である。計算されたfracはbase32の二文字として保存可能であり、再利用期間は約3.5年である。
HMAC  は、ローカルシークレットに対して計算されるが使用されるその一部のみである。例えばbase64表現の最初の四文字を格納すると24ビットの暗号強度となる。バウンスが到着した場合に備えて、ハッシュはそれを生成したドメインによってチェックされる。
プレフィックスは、書き換えられたものから正規アドレスを明確にする意味合いがある。1=SRS0=}}で始まる電子メールアドレスを持つユーザーがいないかを確認するかは//example.com// 次第である。SRSには、[1]において既に書き換え済みのアドレスを再度書き換えるために使用される別のプレフィックスSRS0}}がある。 //example.com}}//がメールを順番に転送する必要がある場合、別のタイムスタンプを追加したり元のローカルパートを繰り返さなくともよい。 つまり、新なた転送先にはそれぞれ、独自のハッシュと前の転送ドメイン名だけを追加する。

更なる書き換え 送信者エンベロープ}}: 受信者エンベロープ}}:

2.1. データベースの代わり
---------------

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

2.2. ヘッダーフィールドの代わり
------------------

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

3. 歴史的背景
--------

従来、全てのメール転送エージェント が自分のホスト名を戻り経路に追加した。簡易メール転送プロトコルでは、この戻り経路はMAIL FROMとして知られているが、戻り経路はSMTPの登場以前からSMTP以外にも使用されていた。例えばUUCPやUsenetにおける転送経路が挙げられる。全てのネットニュース記事には、依然として下のようなPathヘッダが付いている。

Path: news.server.example!other.example!not-for-mail

同じように、821}}における電子メールのエンベロープでは以下のとおりである。

MAIL FROM:<not-for-mail@other.example>
MAIL FROM:<@news.server.example:not-for-mail@other.example>1段目は送信者を、2段目は次のMTA等を反映したものである。この例では、メールが2番目のMTAから3番目のMTAへ転送され、そこで最終的に配達されると仮定する。最後のMTAはメール配信エージェントとしても知られ、メールを受信者のメールボックスへ格納する。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転送経路が時々混在し、これがその場しのぎの応急処置となっていた。

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はメールエクスチェンジャの略である。

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

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

251 user not local 
551 user not local 

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

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

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

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

RFC5321は、配送責任を負うMTAが戻り経路に表示された発信元へ不達通知を送付しなければならないと記載している。ただし、発信元コンテンツが敵対的な場合またはメッセージが偽造されている場合(RFC5321の6章）