1. はじめに

SMTP は、メッセージ転送プロトコル、つまり、完成した（完全な）メッセージを（必要に応じて）ルーティングし、配信する手段として定義されました。

メッセージ転送エージェント (MTA) は、[SMTP-MTA] で要求されるように 'Received'、'Return-Path'、およびその他のヘッダーフィールドを追加する場合を除き、メッセージテキストを変更してはなりません。

しかし、SMTP は現在、メッセージサブミッションプロトコル、つまりメッセージユーザエージェント (MUA) が MTA ルーティングネットワークに新しいメッセージを導入する手段としても広く使用されています。MUA からのメッセージサブミッションを受け入れるプロセスは、メッセージサブミッションエージェント (MSA) と呼ばれます。

制約のない通信を許可するために、SMTP はメッセージリレー中に認証されないことがよくあります。

初期サブミッションの認証と承認は、セキュリティ要件の変化と、サブミッションサーバが発信するメッセージトラフィックに対して責任を負うという期待の高まりにより、ますます重要になっています。

たとえば、大量のスパムを生成するワーム、ウイルス、またはその他の悪意のあるソフトウェアに感染したマシンが蔓延しているため、多くのサイトでは現在、標準 SMTP ポート (ポート 25) での送信トラフィックを禁止し、すべてのメールサブミッションをサブミッションサーバ経由にしています。

認証と承認の問題に加えて、送信されるメッセージは、完成した（完全な）メッセージである場合もあれば、1つ以上の側面で未完成（不完全）な場合もあります。未完成のメッセージは、[MESSAGE-FORMAT] およびその後の要件に準拠するように完成させる必要がある場合があります。たとえば、メッセージに適切な 'Date' ヘッダーフィールドがなく、ドメインが完全修飾されていない場合があります。場合によっては、MUA が完成したメッセージを生成できないことがあります（たとえば、タイムゾーンがわからない場合など）。送信されたメッセージが完全であっても、ローカルサイトポリシーにより、メッセージテキストを何らかの方法で検査または変更することが規定される場合があります（たとえば、ローカル名またはアドレス空間を隠すため）。このような補完または変更は、ダウンストリーム MTA（つまり、最初のホップのサブミッション MTA の後の MTA）によって実行されると害を及ぼすことが示されており、一般に標準化された MTA 機能の範囲外であると考えられています。

メッセージをサブミッションと転送に分離することで、開発者とネットワーク管理者は次のことをより簡単に行うことができます。

• セキュリティポリシーを実装し、不正なメールリレーや未承諾のバルクメールの注入を防ぐ

• 旅行者などの許可されたユーザによるオフサイトサブミッションを含む、認証されたサブミッションを実装する

• 関連するソフトウェアコードの違いを分離し、それによって各コードベースをより単純にし、リレーとサブミッションに異なるプログラムを使用できるようにする

• サイトのメールクライアントの構成上の問題を検出する

• 将来、拡張サブミッションサービスを追加するための基盤を提供する

このメモは、メッセージがサブミッションとして識別されるための低コストで決定論的な手段を説明し、サブミッションサーバがとるべきアクションを指定します。