メインコンテンツまでスキップ

2. SMTPモデル (The SMTP Model)

2.1. 基本構造 (Basic Structure)​

SMTPの設計は次のように図示できる:

                  +----------+                +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server

SMTPクライアント (SMTP client) が送信するメッセージを持つ場合、SMTPサーバー (SMTP server) への双方向伝送チャネルを確立する。SMTPクライアントの責任は、メールメッセージを1つ以上のSMTPサーバーに転送すること、またはその失敗を報告することである。

メールメッセージがSMTPクライアントに提示される手段、およびそのクライアントがメールメッセージが転送されるべきドメイン (domains) の識別子 (「名前」) をどのように決定するかは、ローカルな問題であり、本文書では扱わない。

すべてのトラフィックを対象ドメインに関係なく転送するSMTPクライアント、またはメッセージ送信の再試行のためのキューを維持しないSMTPクライアントは、本仕様に適合することができるが、完全な能力を持つとは見なされない。完全な能力を持つSMTP実装は、本仕様で議論されるすべてのキューイング、再試行、および代替アドレス機能をサポートすることが期待される。

SMTPサーバーは、最終的な宛先、または中間の「リレー (relay)」(メッセージを受信した後にSMTPクライアントの役割を引き受ける)、または「ゲートウェイ (gateway)」(SMTP以外のプロトコルを使用してメッセージを転送する) のいずれかである可能性がある。SMTPコマンド (SMTP commands) はSMTPクライアントによって生成され、SMTPサーバーに送信される。SMTP応答 (SMTP replies) は、コマンドに応答してSMTPサーバーからSMTPクライアントに送信される。

サーバーがメールデータの終了時に成功応答を発行すると、メッセージに対する責任の正式な引き渡しが発生する: プロトコルは、サーバーがメッセージを配信するか、またはそれに失敗したことを適切に報告する責任を受け入れなければならない (MUST) ことを要求する。

2.2. 拡張モデル (The Extension Model)​

2.2.1. 背景 (Background)​

1990年に開始された取り組みで、元のSMTP要件を超えた共有機能を利用することにクライアントとサーバーが合意できるようにする「サービス拡張 (service extensions)」モデルでプロトコルが修正された。

現代のSMTP実装は、基本的な拡張メカニズムをサポートしなければならない (MUST)。サーバーは、特定の拡張を実装していなくてもEHLOコマンドをサポートしなければならず (MUST)、クライアントはHELOではなくEHLOを優先的に利用すべきである (SHOULD)。ただし、古い適合実装との互換性のため、SMTPクライアントとサーバーは、フォールバックとして元のHELOメカニズムをサポートしなければならない (MUST)。

2.2.2. 拡張の定義と登録 (Definition and Registration of Extensions)​

SMTP拡張メカニズムは、拡張SMTPクライアントとサーバーが互いを認識し、サーバーがサポートするサービス拡張をクライアントに通知できる手段を定義する。

2.2.3. 拡張に関する特別な問題 (Special Issues with Extensions)​

拡張は、基本的なSMTPモデルを変更してはならず (MUST NOT)、既存の標準と上位互換性がなければならない (MUST)。

2.3. SMTP用語 (SMTP Terminology)​

2.3.1. メールオブジェクト (Mail Objects)​

SMTPは、以下で構成されるメールオブジェクト (mail object) を転送する:

  • 伝送パラメータを含むエンベロープ (envelope)
  • ヘッダーセクション (header section)
  • 本文 (body) (コンテンツ)

2.3.2. 送信者と受信者 (Senders and Receivers)​

メールメッセージを発信する当事者は「送信者 (sender)」または「発信者 (originator)」と呼ばれる。メールが配信される当事者は「受信者 (receiver)」または「受取人 (recipient)」と呼ばれる。

2.3.3. メールエージェントとメッセージストア (Mail Agents and Message Stores)​

メールユーザーエージェント (Mail User Agent, MUA): メールの読み取りと作成のためのユーザーインターフェースを提供する。

メール送信エージェント (Mail Submission Agent, MSA): MUAからメッセージを受け入れ、ローカルサイトポリシーを適用する。

メール転送エージェント (Mail Transfer Agent, MTA): あるシステムから別のシステムへメールを転送する。

メール配信エージェント (Mail Delivery Agent, MDA): 受信者のメールボックスにメールを配信する。

2.3.4. ホスト (Host)​

インターネット (または他のネットワーク) に接続されたコンピュータシステム。

2.3.5. ドメイン名 (Domain Names)​

RFC 1034、RFC 1035、およびRFC 1123で説明されているドメイン名。

2.3.6. バッファと状態テーブル (Buffer and State Table)​

SMTPセッションはステートフル (stateful) である。サーバーは、セッション情報とプロトコルの現在の状態を記憶しなければならない (MUST)。

2.3.7. コマンドと応答 (Commands and Replies)​

コマンド (Commands) は、クライアントからサーバーに送信される要求である。応答 (Replies) は、サーバーからクライアントに送信されるレスポンスである。

2.3.8. 行 (Lines)​

SMTPデータは、CRLF (キャリッジリターン、ラインフィード: \r\n) で終了する行で送信される。

2.3.9. メッセージ内容とメールデータ (Message Content and Mail Data)​

メッセージコンテンツは、DATAコマンドを使用して送信される。メッセージデータの終了は、ピリオド (.) のみを含む行で示される。

2.3.10. 発信、配信、リレー、およびゲートウェイシステム (Originator, Delivery, Relay, and Gateway Systems)​

  • 発信システム (Originator): 元のメッセージを作成する
  • 配信システム (Delivery): 最終的な宛先システム
  • リレーシステム (Relay): SMTPを使用して転送する中間システム
  • ゲートウェイシステム (Gateway): 異なるプロトコルを使用する中間システム

2.3.11. メールボックスとアドレス (Mailbox and Address)​

メールボックス (mailbox) は、電子メールメッセージの宛先である。アドレス (address) は、local-part@domain の形式でメールボックスの場所を指定する。

2.4. 一般的な構文原則とトランザクションモデル (General Syntax Principles and Transaction Model)​

SMTPコマンドと応答は、特定の構文規則に従う:

  • コマンドは4文字の単語 (一部は8文字に拡張)
  • 応答は、オプションのテキストを伴う3桁のコード
  • すべてのコマンドと応答は大文字小文字を区別しない
  • 行は指定された長さ制限を超えてはならない (MUST NOT)

基本的なメールトランザクションは次のもので構成される:

  1. 接続確立
  2. クライアント挨拶 (EHLO/HELO)
  3. MAILコマンド (送信者を指定)
  4. RCPTコマンド (受信者を指定、繰り返し可能)
  5. DATAコマンド (メッセージを送信)
  6. QUITコマンド (接続を閉じる)