センダー・リライティング・スキーム
SRSは、書き換えられたアドレスのローカル部分で元の送信先情報をエンコードするのと同様の可変エンベロープ・リターン・パス(VERP) 形式である。example.comが当初bob@example.com宛ての電子メールを新たなアドレス<bob@example.net>:に転送することを考えると、次のようになる。
書き換え後のVERPに関して、@より前にあったローカルパート(alice)はドメイン名(example.org)の後ろに移動され、さらにプレフィックス(SRS0)、ハッシュ(HHH)、タイムスタンプ(TT)が追加される。これは運用上の違いを反映している。VERPアドレスへの最終的なバウンスは書き換えドメイン内で処理され、偽造されたメッセージはせいぜい一部ユーザーの登録解除ができるだけで、過去数十年間に大事件が確認されていないある種の悪用である。代わりに、SRSはバウンスの可能性をAliceに再送信することを目的としており、そのため偽造されたバウンスは書き換え送信者から最初に発信されたと思われるスパムを注入するのに魅力的な手法になる可能性があるヘン)。
ローカルパート(上の例だとalice)は、等号(=)を含んでいる場合があるため移動される。
プライバシー上の理由により、メールが転送されたか(251)転送されたなかったか(551)という事を含んだ、これらの結果コードは今日においては殆ど使われない。しかしその意味と第三者への転送結果は、それぞれ結果コード250とエラーコード550と全く同等である。
RFC1123に記載のとおりソースルート指定が非推奨とされ、エラーメールの戻り経路も暗黙の内に非推奨とされた。1989年当時のインターネットは比較的小さく、メール管理者(postmaster)が知人同士である事も多かったので問題もその時々で解決された。(例えば、5xxのエラーコードを伴う拒否など)問題を示すMTAが送信者のMXへ直接エラーメールを送信する事ができる場合には、エラーメールが幾つかの転送ホストを経由して返るような経路指定は、時間と帯域幅の無駄だった。
RFC1123以降は、第三者へ転送するホストはRCPT TOアドレスの書き換えをするが、MAIL FROMはそのままの状態にされた。その副作用として、転送ホストから届いたメールを受け入れるMTAは、一般的にどのようなMAIL FROMアドレスでも受け入れる。
それから10年以上経ち、RFC1123以降のSMTPが抱えるこの欠陥をスパム送信者が不正に使い始めた。今日では大半のメールがスパムであり、大半の戻り経路が詐称されている。スパム送信者は一般的に戻り経路を詐称する点が特徴であり、戻り経路のコールバック認証やその他の妥当性チェックが怪しい場合、多くのMTAはメールを拒否する。
RFC5321は、配送責任を負うMTAが戻り経路に表示された発信元へ不達通知(エラーメール)を送付しなければならないと記載している。
従来、全てのメール転送エージェント(MTA) が自分のホスト名を戻り経路に追加した。簡易メール転送プロトコル(SMTP)では、この戻り経路はMAIL FROMとして知られているが、戻り経路はSMTPの登場以前からSMTP以外にも使用されていた。例えばUUCPやUsenet(NetNews)における転送経路(bang path)が挙げられる。全てのネットニュース記事には、依然として下のようなPathヘッダが付いている。
同じように、RFC 821における電子メールのエンベロープ(MAIL FROMのようなSMTP情報)では以下のとおりである。
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)としても知られ、メールを受信者のメールボックスへ格納する。MDAは、以下のように戻り経路をReturn-Pathヘッダの中に変換する。
SMTPは配送ルート決定にMXレコードを使用する。
こうしたソースルートの明示をしてother.exampleからMTAnews.server.exampleを経由してMDAdestination.exampleへとメールの配送経路を指定するのは面倒であった。更に悪いことに、1982年の新たな形式には以下のような構成の古いUUCP転送経路(bang path)が時々混在し、これがその場しのぎの応急処置となっていた。