メール転送

電子メール転送とは、一般的に、ある電子メールアドレスに以前配信された電子メールを 1 つ以上の別の電子メール アドレスに再送信する操作を指します。

転送という用語は、電子通信よりずっと前からメールに使用されており、特別な技術的な意味はありませんが、^[1]電子メールが新しい宛先に「転送」されたことを意味します。

メール転送では、特定のアドレス宛てのメールをリダイレクトして、1 つ以上の他のアドレスに送信することもできます。逆に、複数の異なるアドレス宛てのメール アイテムを転送によって 1 つのアドレスの受信トレイにまとめることもできます。^{[説明が必要]}

電子メール ユーザーと電子メール システムの管理者は、サーバー ベース転送とクライアント ベース転送の両方について話すときに同じ用語を使用します。

ドメイン名（電子メールアドレスの@の右側に表示される部分）は 、対応するアドレスのクラスのターゲットサーバー^{[2]を定義します。ドメインは}バックアップサーバーを定義することもできます。バックアップサーバーにはメールボックスがなく、エンベロープの一部を変更せずにメッセージを転送します。 ^[3]対照的に、プライマリサーバーは、メッセージをユーザーのメールボックスに配信したり、エンベロープアドレスの一部を変更して転送したりできます。~/.forwardファイル（以下を参照）は、異なる受信者へのサーバーベースの転送の典型的な例を示しています。

電子メール管理者は、サーバーベースの電子メールを異なる受信者に転送することの同義語としてリダイレクトという用語を使用することがあります。プロトコルエンジニアは、転送サーバーを指すためにメディエーターという用語を使用することがあります。 ^[4]

スパムのせいで、異なるドメイン間でメールを確実に転送することがますます困難になってきており、可能な限りそれを避けることを推奨する人もいます。^[5]

役割アドレス

info、sales、postmaster、および類似の名前^{[6]は、電子メールアドレスの}@の左側に表示されることがあります。組織は、特定の役割宛てのメッセージを、現在その役割またはオフィスで機能している人物のアドレスに転送することができます。

仮名アドレス

ほとんどのドメイン名ホスティング施設は、ユーザーのインターネット サービス プロバイダーのメールボックスなどの別の電子メール アドレスにメールを転送する機能を提供します。また、メール転送サービスを提供する別のプロバイダーもあります。これにより、ユーザーはメールボックス プロバイダーを変更しても電子メール アドレスが変わらないようになります。

複数のアドレス、または廃止されたアドレス

ユーザーが電子メール アドレスを変更したり、複数のアドレスを持っている場合、ユーザーまたは管理者は、メッセージが失われないように、これらのアドレス（まだ有効である場合）から現在の 1 つのアドレスに転送するように設定できます。

プレーン メッセージ転送では、エンベロープ受信者が変更され、エンベロープ送信者フィールドは変更されません。「エンベロープ送信者」フィールドは、電子メール クライアント ソフトウェアが通常表示するFrom ヘッダーと同じではありません。これは、 SMTPプロトコルの初期段階で使用され、その後Return-Pathヘッダーとして保存されるフィールドを表します。このフィールドには、メール システムがバウンス メッセージを送信するアドレス(配信の失敗 (または成功) がある場合に報告) が保持されます。

対照的に、再メールや再配布という用語は、メッセージの再送信と「エンベロープ送信者」フィールドの書き換えも意味する場合があります。電子メール リストは典型的な例です。作成者は、各リスト アドレスへの再メールを実行するリフレクタにメッセージを送信します。この方法では、バウンス メッセージ(リスト サブスクライバへのメッセージ配信の失敗を報告するもの) はメッセージの作成者に届きません。ただし、設定が誤っている迷惑な不在時の自動返信は作成者に届きます。

通常、単純なメッセージ転送はエイリアス拡張を行いますが、適切なメッセージ転送は、転送tout-court ^{[1]とも呼ばれ、メーリングリストで使用されます。メッセージに追加の変更が行われ、}メールユーザーエージェントが新しいメッセージを送信する動作に似せられる場合、転送という用語は誤解を招き、再送信のほうが適切であると思われます。

Sender Policy Framework (SPF)では、エンベロープ送信者のドメイン名はポリシー制限の対象となります。そのため、SPF は一般にプレーンメッセージ転送を許可しません。転送の場合、メールは転送サーバーから送信されますが、転送サーバーは元の送信者のドメインにメールを送信する権限がありません。そのため、SPF は失敗します。^[7] ドメイン内リダイレクトは、関連するサーバーが一貫した構成を共有している限り、SPF に準拠しています。ドメイン間メッセージ転送を実行するメールサーバーは、SPF を実装していなくても、つまり SPF チェックを適用せず、SPF レコードを公開しない場合でも、SPF に違反する可能性があります。^[8] 送信者書き換えスキームは、 SPF と互換性のある汎用転送メカニズムを提供します。

クライアント転送は、メール検索エージェントなどの非対話型クライアントを使用して自動的に行うことができます。検索エージェントはクライアントプロトコルを使用しますが、この転送は、同じメッセージIDを保持するという点でサーバー転送に似ています。エンベロープ送信者に関する懸念が適用されます。^[8]

エンドユーザーは、電子メール クライアントを使用してメッセージを手動で転送できます。インライン転送では、新しいメッセージの本文の下にメッセージが引用され、通常は元の添付ファイルと選択したヘッダー (元のFromやReply-Toなど) が保持されます。この方法で転送されたメッセージの受信者は、元のメッセージに返信できる場合があります。返信できるかどうかは元のヘッダーが存在するかどうかによって決まり、関連する宛先アドレスを手動でコピーして貼り付ける必要がある場合があります。

添付ファイルとして転送すると、すべてのヘッダーと添付ファイルを含む完全な元のメッセージを含むMIME添付ファイル (タイプmessage/rfc822 )が作成されます。すべてのヘッダーを含めると、メッセージを送信したサーバーやメールボックスに追加されたクライアント タグなど、メッセージに関する多くの情報が公開されることに注意してください。この方法で転送されたメッセージの受信者は、添付されたメッセージを開いてシームレスに返信できる場合があります。

この種の転送は、実際には、エンベロープ送信者と受信者の観点からは 再送信に相当します。メッセージの ID も変更されます。

1982 年にJonathan B. Postelが作成したRFC 821 ( Simple Mail Transfer Protocol)では、各受信者の転送パスが、たとえば、オプションのホスト リストと必須の宛先メールボックスの形式で提供されていました。ホスト リストが存在する場合、それはソース ルートとして機能し、各ホストがリスト上の次のホストにメールを中継する必要があることを示しています。そうでない場合、宛先情報が不十分でもサーバーが正しい宛先を知っている場合は、次のように応答してメッセージを配信する責任を引き受けることができます。 @USC-ISIE.ARPA, @USC-ISIF.ARPA: Q-Smith@ISI-VAXA.ARPA

S:  RCPT  TO: <Postel@USC-ISI.ARPA> 
R:  251 ユーザーはローカルでは ありません 。<Postel@USC-ISIF.ARPA>に転送 されます。   

当時のコンセプトでは、メッセージが 1 つの SMTP サーバーから別の SMTP サーバーに中継されるときに、転送パス(ソース ルート) の要素がリターン パス(エンベロープ送信者)に移動することが想定されていました。システムでソース ルーティングの使用が推奨されていなかったとしても、 ^[9]リターン パス を動的に構築することは、転送中に「エンベロープ送信者」の情報が元の形式のままでは維持できないことを意味していました。したがって、RFC 821 では、もともとプレーン メッセージ転送は許可されていませんでした。

MXレコード^[10]の導入により、ソースルーティングは不要になりました。1989年、RFC 1123は、後方互換性のためだけにソースルーティングを受け入れることを推奨しました。その時点で、プレーンメッセージ転送^[8]がエイリアス拡張の推奨アクションになりました。2008年、RFC 5321では、そうしないと機密情報が誤って公開される可能性があることを考慮して、「システムは必要に応じてリターンパスを削除し、再構築してもよい」とまだ言及されています。[ 11 ]^実際 、プレーンメッセージ転送は、同じサーバーまたは調整されたサーバーのセット内でのエイリアス拡張に便利に使用できます。

1980 年代初頭のSMTP の標準実装はsendmailであり、これは~/.forward特定のユーザーのターゲット電子メール アドレスを保存できるファイルを提供しました。この種のサーバー ベースの転送は、ドット転送と呼ばれることもあります。^[12] 一部の電子メール プログラムフィルターを設定して、受信後すぐに転送または返信アクションを自動的に実行することができます。転送ファイルにはシェル スクリプトも含まれる可能性があり、これが多くのセキュリティ問題の原因となっています。以前は、信頼できるユーザーだけがコマンドライン スイッチを使用してエンベロープ送信者を設定できました。一部のシステムでは、セキュリティ上の理由からこの機能が無効になっていました。^[13]-f arg

電子メールは、1990 年代にクライアント サーバーアーキテクチャが形式化される前から存在していました。 ^{[14]そのため、}クライアントとサーバー の区別は必然的に強引なものに思えます。元々の区別は、同じマシンで実行されるデーモンとユーザー制御のプログラムを対比するものでした。sendmail デーモンはルート 権限で実行されていたため、メールを管理する任意のユーザーになりすますことができました。一方、ユーザーは自分のメール ファイルや設定ファイルにアクセスできます。これには が含まれます~/.forward。クライアント プログラムは、特定のユーザーのサーバー設定ファイルの編集を支援する場合があり、それによって各プログラムの役割について混乱が生じます。

「仮想ユーザー」という用語は、メール サーバー システムにログオンせず、リモート クライアントを使用してのみメールボックスにアクセスする電子メール ユーザーを指します。メール サーバー プログラムは、仮想ユーザーと通常のユーザーの両方で動作する場合もあれば、仮想ユーザーが同じシステムIDを共有することが多いという事実を利用するために、若干の変更が必要になる場合もあります。後者の状況では、サーバー プログラムはシステム アクセス制限に従う必要がないため、一部の機能をより簡単に実装できます。同じ操作原則が適用されます。ただし、良くも悪くも、仮想ユーザーは構成ファイルへのアクセスがより困難になります。

• チェーンメール
• 電子メールリスト
• メールエイリアス
• メールレター
• メールの件名の略語
• メールスパム
• メール ユーザー エージェント(MUA)、別名電子メール クライアント
• メッセージ転送エージェント(MTA)
• メールの嵐
• 送信者書き換えスキーム