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

3. SMTP手順の概要 (The SMTP Procedures: An Overview)

このセクションでは、セッション初期化、メールトランザクション、アドレス検証、リレー、ゲートウェイ処理、およびセッション終了を含む、SMTP操作の概要を提供する。

3.1. セッション初期化 (Session Initiation)​

SMTPセッション (SMTP session) は、送信SMTP (クライアント) が受信SMTP (サーバー) への双方向伝送チャネルを確立することによって開始される。チャネルは完全に非同期であり、データフローの制限はない。TCP接続を完了した後、サーバーは通常「220 Service ready」(サービス準備完了) 応答を送信する。クライアントは通常、この挨拶を受信した後に操作を開始する。

3.2. クライアント初期化 (Client Initiation)​

トランスポートサービスが初期化チャネルを提供し、サーバーが220サービス準備完了挨拶を送信した後、クライアントは通常、EHLOコマンド (EHLO command) を送信して自身を識別し、利用可能なサービス拡張をサーバーに通知するよう要求する。サーバーが拡張をサポートしていない場合、EHLOに対して500エラーで応答し、クライアントはHELOコマンド (HELO command) にフォールバックすべきである (SHOULD)。

EHLOコマンドの例:

S: 220 smtp.example.com ESMTP Postfix
C: EHLO client.example.com
S: 250-smtp.example.com
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 HELP

3.3. メールトランザクション (Mail Transactions)​

メールトランザクション (mail transaction) は、クライアントからサーバーへメッセージを転送する一連のコマンドで構成される。メールトランザクションには以下が含まれる:

  1. MAILコマンド - メッセージ発信者を識別する
  2. 1つ以上のRCPTコマンド - メッセージ受信者を識別する
  3. DATAコマンド - メッセージコンテンツを送信する

完全なトランザクションの例:

C: MAIL FROM:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: RCPT TO:<[email protected]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: [email protected]
C: To: [email protected]
C: Subject: Test message
C: 
C: This is a test message.
C: .
S: 250 Ok: queued as 12345

MAILコマンドはメールトランザクションを開始する。このコマンドが正常に完了すると、受信者はすべてのバッファと状態テーブルをクリアし、RCPTコマンドを受信する準備をする。

RCPTコマンドは、そのメールの単一の受信者を識別する。特定のメッセージに対して複数のRCPTコマンドを発行できる。成功したRCPTコマンドは、受信者をバッファに追加する。

DATAコマンドは、後続の行をコマンドではなくメッセージテキストとして扱わせる。メッセージは、ピリオド (.) のみを含む行で終了される。

3.4. アドレス訂正または更新のための転送 (Forwarding for Address Correction or Updating)​

一部のサーバーは、元の受信者アドレスではなく、訂正または更新されたアドレスにメールを転送することを希望する場合がある。SMTPは、この目的のために251および551応答コード (response codes) を提供する。これらのコードにより、サーバーは、ユーザーアドレスが変更されたが、サーバーがメッセージを転送しようとする (251) か、転送できない (551) ことをクライアントに通知できる。

3.5. アドレスのデバッグ用コマンド (Commands for Debugging Addresses)​

3.5.1. 概要 (Overview)​

SMTPは、ユーザー名とメーリングリストを検証するための2つのコマンドを提供する:

  • VRFY - ユーザー名またはメールボックスを検証する
  • EXPN - メーリングリストを展開する

これらのコマンドは主にデバッグ目的であり、多くのサーバーはセキュリティとプライバシーの理由でこれらを無効化または制限している。

3.5.2. VRFYの通常応答 (VRFY Normal Response)​

VRFYコマンドへの成功応答は通常、コード250であり、その後にユーザーのフルネームとメールボックスアドレスを含むテキストが続く。

例:

C: VRFY Jones
S: 250 Fred Jones <[email protected]>

3.5.3. VRFYまたはEXPN成功応答の意味 (Meaning of VRFY or EXPN Success Response)​

VRFYおよびEXPNコマンドへの成功応答は、そのアドレスがメールを受信できること、またはメールが配信されることを保証するものではない。それは単に、そのアドレスがサーバーに知られており、構文的に有効であることを示すだけである。

3.5.4. EXPNのセマンティクスとアプリケーション (Semantics and Applications of EXPN)​

EXPNコマンドは、メーリングリストまたはエイリアスを展開するために使用される。リスト内のすべてのアドレスを返す。

例:

C: EXPN staff
S: 250-Alice <[email protected]>
S: 250-Bob <[email protected]>
S: 250 Charlie <[email protected]>

3.6. リレーとメールルーティング (Relaying and Mail Routing)​

3.6.1. ソースルートとリレー (Source Routes and Relaying)​

ソースルーティング (source routing) (中間ホストを経由するパスを明示的に指定すること) は、現代のSMTPでは非推奨である。メールルーティングは、DNS MXレコードに依存すべきである (SHOULD)。

3.6.2. メール交換レコードとリレー (Mail eXchange Records and Relaying)​

DNS MX (Mail eXchanger) レコードシステムは、ドメインのメールを受け入れる責任を持つメールサーバーを識別するために使用される。メールを配信する際:

  1. 宛先ドメインのMXレコードを検索する
  2. 優先度で並べ替える (数値が小さいほど優先度が高い)
  3. 優先度順にサーバーへの配信を試みる
  4. すべてのMXレコードが失敗した場合、A/AAAAレコードへの直接配信を試みる

DNS MXレコードの例:

example.com.  IN MX 10 mail1.example.com.
example.com.  IN MX 20 mail2.example.com.
example.com.  IN MX 30 mail3.example.com.

3.6.3. リレーとしてのメッセージ送信サーバー (Message Submission Servers as Relays)​

メッセージ送信エージェント (Message Submission Agents, MSAs) は、以下を行う特殊なリレーとして機能する:

  • メールユーザーエージェント (Mail User Agents, MUAs) からメールを受け入れる
  • 送信ポリシーを適用する
  • 必要なヘッダーを追加する
  • 送信者を認証する
  • 適切なMTAに転送する

3.7. メールゲートウェイング (Mail Gatewaying)​

メールゲートウェイ (mail gateway) は、SMTPインフラストラクチャを他のメールシステム (例: X.400、UUCP) に接続する。ゲートウェイはプロトコルとフォーマット間を変換する。

3.7.1. ゲートウェイングにおけるヘッダーフィールド (Header Fields in Gatewaying)​

ゲートウェイは、必須のヘッダーフィールドを保持しなければならず (MUST)、ゲートウェイ固有のフィールドを追加してもよい (MAY)。変換は、可能な場合、意味的等価性を維持しなければならない (MUST)。

3.7.2. ゲートウェイングにおける受信行 (Received Lines in Gatewaying)​

ゲートウェイは、メッセージパスを追跡するために、Receivedヘッダーフィールドを追加しなければならない (MUST):

  • ゲートウェイ識別
  • タイムスタンプ
  • プロトコル情報

3.7.3. ゲートウェイングにおけるアドレス (Addresses in Gatewaying)​

アドレス変換は複雑で、ゲートウェイ固有である。ゲートウェイは以下を行うべきである (SHOULD):

  • 元のアドレス情報を保持する
  • 双方向のアドレスマッピングを提供する
  • 変換規則を文書化する

3.7.4. ゲートウェイングにおける他のヘッダーフィールド (Other Header Fields in Gatewaying)​

ゲートウェイは、さまざまなヘッダーフィールドを適切に処理しなければならない (MUST):

  • From、To、Cc、Bcc (アドレスフィールド)
  • Subject、Keywords (テキストフィールド)
  • Date (タイムスタンプ変換)
  • Message-ID (一意の識別子の保持)

3.7.5. ゲートウェイングにおけるエンベロープ (Envelopes in Gatewaying)​

SMTPエンベロープ (MAIL FROMおよびRCPT TO) は、ヘッダーアドレスと異なる場合がある。ゲートウェイは両方を正しく処理しなければならない (MUST)。

3.8. セッションと接続の終了 (Terminating Sessions and Connections)​

SMTPセッションは、QUITコマンドで終了される:

C: QUIT
S: 221 smtp.example.com closing connection

221応答を送信した後、サーバーはTCP接続を閉じる。クライアントは、閉じる前に221応答を待つべきである (SHOULD) が、サーバーが最初に閉じることに備えなければならない (MUST)。

異常終了: 重大なエラーが発生した場合、いずれの当事者も接続を直ちに閉じることができる。サーバーは、閉じる前にサービスが利用できないことを示すために応答コード421を使用してもよい (MAY)。

3.9. メーリングリストとエイリアス (Mailing Lists and Aliases)​

3.9.1. エイリアス (Alias)​

エイリアス (alias) は、解決されると1つ以上の他のメールボックス名を参照するメールボックス名である。エイリアス展開は送信者に対して透過的である。

例: [email protected] は [email protected] のエイリアスかもしれない

3.9.2. リスト (List)​

メーリングリスト (mailing list) はエイリアスに似ているが、通常は以下の特徴がある:

  • リスト管理ソフトウェアによって管理される
  • サブスクリプション/サブスクリプション解除を許可する
  • メッセージを変更する可能性がある (ヘッダー、フッターを追加)
  • サブスクライバーデータベースを維持する

メールがリストに送信されると、それは展開され、すべてのサブスクライバーに配信される。リストソフトウェアは通常:

  • リスト固有のヘッダーを追加する (List-ID、List-Unsubscribe)
  • モデレーションを要求する場合がある
  • バウンス処理を処理する
  • アーカイブを維持する
に最終更新