原文：ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt
訳注：transfer を「通信」とすべきか「転送」とすべきか……悩んだ末に混在させています。それ以外にも原文では同じ単語を別々の日本語に対応させている部分がたくさんあります。正確な理解を望むなら原文を参照されることを強くお勧めします。
2005/12/30 0.1.0 初版
ソーシャルブックマーク：
サイト内関連リンク：
RFC 5321 SMTP (日本語訳、SMTPの最新の仕様はこちらになります)/
RFC 5322 インターネットメッセージフォーマット(日本語訳)/
RFC 2554 SMTP-AUTH(日本語訳)
この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案とを求めている。このプロトコルの標準化の状態と状況は、最新版の "Internet Official Protocol Standards"(STD 1)を参照して欲しい。この文書の配布は無制限である。
Copyright (C) The Internet Society (2001). All Rights Reserved.
この文書は、インターネットの電子メール転送向け基本的プロトコルの自己完結した仕様である。これは以下の既存機能を確固たるものにし、更新し、明確にするが、追加や変更は行わない：
この文書は RFC 821 と RFC 974 とを廃止し、RFC 1123 を更新(メール転送の題材を置換)する。しかしながら RFC 821 は、1990 年代半ばまではインターネットにおいて重要な使われ方をしていなかったいくつかの機能と、(補遺において)いくつかの追加の転送モデルとを規定している。明確さと簡潔さのため、ここではそれらのセクションは省略されている。それらを必要とする読者は RFC 821 を参照すべきである。
またこの文書は、拡充を必要とした RFC 1123 由来の追加題材をいくつか含んでいる。その題材は複数の方法で特定されてきたが、大部分は、SMTP 拡張が採用されたときに現れた様々なメーリングリストおよびニュースグループのフレーミングと、例外的な読み物や解説による議論とを追跡することによって特定される。この文書の中で、整理統合を超えて変更され、以前の文書と明らかに異なる部分は、その文章と同時に、技術的にもそれらを置き換えるものである。
SMTP はメールの転送および配送のためのプロトコルとして設計されたが、POP [3, 26] と IMAP [6] とのために推奨されている 'メール投入' プロトコルとしての利用に重要な情報も含んでいる。投入に付随する問題は RFC 2476 で議論されている。
この文書特有の用語はセクション 2.3 で定義されている。明確性のために歴史的な用語が必要な場合を除き、この文書では SMTP の送信・受信の各プロセスを特定するために、現在一般に通用している 'クライアント'・'サーバー' という用語を使用する。
メッセージヘッダとメッセージボディ、それらのフォーマットと構造、およびそれらの関係は、関連文書 [32] で議論されている。
1. 導入
2. SMTP モデル
2.1 基本構造
2.2 拡張モデル
2.2.1 背景
2.2.2 拡張の定義と登録
2.3 用語
2.3.1 メールオブジェクト
2.3.2 送信者と受信者
2.3.3 メールエージェントとメッセージストア
2.3.4 ホスト
2.3.5 ドメイン
2.3.6 バッファと状態テーブル
2.3.7 行
2.3.8 送信者・配送・リレー・ゲートウェイシステム
2.3.9 メッセージ内容とメールデータ
2.3.10 メールボックスとアドレス
2.3.11 リプライ
2.4 一般的な文法原則とトランザクションモード
3. SMTP の手続き：概観
3.1 セッション開始
3.2 クライアントの開始
3.3 メールトランザクション
3.4 アドレスの訂正または更新のための転送
3.5 アドレスデバッグのためのコマンド
3.5.1 概観
3.5.2 VRFY の通常レスポンス
3.5.3 VRFY または EXPN の成功レスポンスの意味
3.5.4 EXPN の適用性と意味論
3.6 ドメイン
3.7 リレー
3.8 メールゲートウェイg
3.8.1 ゲートウェイ中のヘッダフィールド
3.8.2 ゲートウェイ中の Received 行
3.8.3 ゲートウェイ中のアドレス
3.8.4 ゲートウェイ中の他のヘッダフィールド
3.8.5 ゲートウェイ中のエンベロープ
3.9 セッションと接続の終了
3.10 メーリングリストとエイリアス
3.10.1 エイリアス
3.10.2 リスト
4. SMTP 仕様
4.1 SMTP コマンド
4.1.1 コマンドの動作と文法
4.1.1.1 拡張された HELLO(EHLO)、または HELLO(HELO)
4.1.1.2 MAIL (MAIL)
4.1.1.3 RECIPIENT (RCPT)
4.1.1.4 DATA (DATA)
4.1.1.5 RESET (RSET)
4.1.1.6 VERIFY (VRFY)
4.1.1.7 EXPAND (EXPN)
4.1.1.8 HELP (HELP)
4.1.1.9 NOOP (NOOP)
4.1.1.10 QUIT (QUIT)
4.1.2 コマンド引数の文法
4.1.3 アドレスリテラル
4.1.4 コマンドの順序
4.1.5 プライベートコマンド
4.2 SMTP リプライ
4.2.1 リプライコードの深刻度と理論
4.2.2 機能グループ毎のリプライコード
4.2.3 数値順のリプライコード
4.2.4 リプライコード 502
4.2.5 DATA と 後続の <CRLF>.<CRLF> との後のリプライコード
4.3 コマンドとリプライとの順序付け
4.3.1 順序付け概観
4.3.2 コマンド-リプライ シーケンス
4.4 トレース情報
4.5 追加の実装問題
4.5.1 最小限の実装
4.5.2 透過性
4.5.3 サイズとタイムアウト
4.5.3.1 サイズの限界と最低限
4.5.3.2 タイムアウト
4.5.4 リトライ戦略
4.5.4.1 送信戦略
4.5.4.2 受信戦略
4.5.5 空の reverse-path を伴うメッセージ
5. アドレス解決とメール処理
6. 問題の発見と処置
6.1 信頼できる配送とメールによるリプライ
6.2 ループ検出
6.3 不正を補う
7. セキュリティ考察
7.1 メールのセキュリティとなりすまし
7.2 "ブラインド(Blind)" コピー
7.3 VRFY、EXPN、そしてセキュリティ
7.4 アナウンスにおける情報開示
7.5 トレースフィールドにおける情報開示
7.6 メッセージ転送における情報開示
7.7 SMTP サーバーの運用範囲
8. IANA 考察
9. 参考文献
10. 著者のアドレス
11. 謝辞
付録
A. TCP トランスポートサービス
B. RFC 822 ヘッダ由来の SMTP コマンドを生成する
C. ソースルート
D. シナリオ
E. その他のゲートウェイ問題
F. RFC 821 の非推奨機能
Full Copyright Statement
Simple Mail Transfer Protocol (SMTP) の目的は、効率良く確実にメールを転送することである。
SMTP は特定の通信サブシステムからは独立しており、信頼できる規則正しいデータストリームチャネルだけを必要とする。この文書では具体的に TCP 上での転送を議論するが、他のトランスポートも利用可能である。それらの一部に付いて、RFC 821 の補遺で説明されている。
SMTP の重要な機能のひとつはネットワーク越しにメールを転送する能力であり、通常それは "SMTP メールリレー(SMTP mail relaying)" として言及される(セクション 3.8 参照)。ネットワークは、公のインターネット上で相互に TCP アクセス可能なホスト、またはファイアウォールで分離された TCP/IP イントラネット上の相互に TCP アクセス可能なホスト、または非 TCP のトランスポートレベルプロトコルを利用する他の LAN または WAN 上のホストから構成される。SMTP を使用すると、あるプロセスは同じネットワーク上の別のプロセスにメールを送信したり、双方のネットワークからアクセス可能なリレープロセスやゲートウェイプロセスを経由して別のネットワーク上のホストにメールを送信したりすることが出来る。
このように、メールは送信者から最終受信者までの経路上で、多くの中間リレーや中間ゲートウェイを経由する可能性がある。転送されるメッセージのための適切なネクストホップを特定するために、ドメインネームシステム [22, 27] の Mail eXchanger メカニズム(およびこの文書のセクション 5)が使用される。
SMTP のデザインは以下のように描写することが出来る：
+------------+ +----------+
+---------+ | | | |
| ユーザ |<-->| | SMTP | |
+---------+ |クライアント|コマンド/応答 | サーバー |
+---------+ | -SMTP |<-------------->| -SMTP | +--------+
|ファイル |<-->| | メール | |<-->|ファイル|
|システム | | | | | |システム|
+---------+ +------------+ +----------+ +--------+
SMTP クライアント SMTP サーバー
送信するメッセージを持っているクライアントは、SMTP サーバーへの双方向通信チャネルを確立する。SMTP クライアントの責任は、１つまたは複数の SMTP サーバーにメールメッセージを送信するか、その際の失敗を報告することである。
メールメッセージが SMTP クライアントに提供される方法と、メールメッセージが送信されるべきドメイン名を決定する方法とはローカルの問題であり、この文書では示されていない。場合によっては、SMTP クライアントに送信されたドメイン名、または SMTP クライアントによって決定されたドメイン名が、そのメールメッセージの最終宛先を表すだろう。それ以外の場合、例えば POP [3, 26] または IMAP [6] の実装が使われている SMTP クライアントの場合や、分離されたトランスポートサービス環境の内側にある SMTP クライアントの場合、決定されたドメイン名は、全てのメールメッセージをリレーする仲介の宛先を表すだろう。それ以外の、個々のメッセージの宛先ドメインとは無関係に全てのトラフィックを送信する SMTP クライアント、または初回に完了しなかったメッセージを再送するためのキューを保持しないクライアントは、この仕様には従うかもしれないが、完全に機能するものとは見なされない。完全に機能する SMTP 実装(より貧弱な実装によって使用されるリレーを含む)とその送信相手は、この仕様で議論されているキューイング・リトライ・代替アドレスの各機能を全てサポートすることを期待される。
この仕様は、SMTP クライアントが(目的のドメイン名を決定した後に)メッセージのコピーを送信するべき SMTP サーバーを特定し、その後送信を実行するまでの方法を網羅している。SMTP サーバーへメールを送信するために、SMTP クライアントはその SMTP サーバーへの双方向通信チャネルを確立する。宛先ドメイン名を Mail eXchanger ホストまたは最終目的ホストの何れかへと解決することで、SMTP クライアントは SMTP サーバーを実行している適切なホストのアドレスを決定する。
SMTP サーバーは、最終的な宛先か、中間 "リレー(relay)" (すなわち、このホストはメッセージ受信後に SMTP クライアントの役割を担う可能性がある)か、"ゲートウェイ(gateway)" (すなわち、このホストは SMTP 以外のプロトコルを使用して、さらに先へとメッセージを転送する可能性がある)か、何れかである可能性がある。SMTP コマンドは SMTP クライアントによって生成され、SMTP サーバーへと送信される。SMTP リプライは、コマンドへの応答として SMTP サーバーから SMTP クライアントへと送信される。
言い換えるとメッセージ送信は、送信元 SMTP 送信者と最終 SMTP 受信者との間の単一コネクションにおいてか、または中間システムを通す一連のホップにおいてか、何れかで起こる可能性がある。どちらの場合も、そのメッセージに対する責任の、公式なハンドオフが発生する：このプロトコルは、メッセージの配送か、配送時のエラーの適切な報告か、何れかの責任をサーバーが受け入れることを必要とする。
この通信チャネルが確立され最初のハンドシェイクが完了した時点で、通常 SMTP クライアントはメールトランザクションを開始する。このようなトランザクションは、メールの送信者と宛先とメッセージの内容(ヘッダまたはその他の構造を含む)とを特定する一連のコマンドから構成される。同じメッセージが複数の受信者に送られる場合、このプロトコルは、同じ宛先ホスト(または中間リレー)上の全ての受信者に対しては、データのコピーを１つだけ送信することを推奨する。
各コマンドに対し、サーバーはリプライで応答する。リプライは、コマンドが受け付けられたこと、または追加コマンドが期待されること、一時的または永続的なエラー状態が発生していることを表す可能性がある。送信者または受信者を特定するコマンドは、セクション 2.2 で議論されているような、サーバーが許可する SMTP サービス拡張リクエストを含むことができる。コマンドのパイプライン[13]のような相互に同意された拡張リクエストによって変更可能ではあるが、この対話は意図的に、一度に１つずつ(one-at-a-time)直列形式(lock-step)になっている。
メールメッセージを送信した後のクライアントは、接続を終了するか、別のメールトランザクションを開始することが出来る。さらに SMTP クライアントは、SMTP サーバーへの接続を、電子メールアドレスの照合やメーリングリストの購読者のアドレス取得などの補助的なサービスに使用しても良い。
前述の通り、このプロトコルはメール送信のためのメカニズムを提供する。２つのホストが同じトランスポートサービスに接続している場合、通常この送信は送信ユーザーのホストから受信ユーザーのホストへと直接行われる。２つのホストが同じトランスポートサービスに接続していない場合、送信は１つ以上のリレー SMTP サーバーを経由して行われる。何らかの他の通信環境へのゲートウェイとして、または SMTP リレーとして振舞う中間ホストは、通常ドメインネームサービス(DNS)の Mail eXchanger メカニズムを利用して選択される。
一般に中間ホストは、明示的な"ソース"ルーティングによってではなく、 DNS の MX レコードによって決定される(セクション 5、付録 C および F.2 参照)。
1990 年に始まり RFC 821 の完成から約十年間の努力において、クライアントとサーバーとがオリジナルの SMTP 要件以上の共有機能を利用することを合意可能にする "サービス拡張(service extensions)" モデルによって、このプロトコルは変更された。SMTP 拡張のメカニズムは、拡張された SMTP クライアントとサーバーとが互いに認識し合い、サーバーがサポートするサービス拡張をクライアントに知らせることを可能にする手段を定義する。
最新の SMTP 実装は、基本的な拡張メカニズムをサポートしなければならない(MUST)。例えば特別な拡張を全く実装していない場合でも、サーバーは EHLO コマンドをサポートしなければならない(MUST)し、クライアントは HELO ではなく EHLO を優先的に使用するべきである(SHOULD)。(しかしながら古い実装との互換性のために、SMTP のクライアントとサーバーは、代替手段としてオリジナルの HELO をサポートしなければならない(MUST))。互換性のために HELO の特徴を意識しなければならない場合を除き、この文書では EHLO についてのみ議論する。
SMTP は広く採用されており、高品質の実装は非常に堅牢であることが立証されている。しかしながら現在のインターネットコミュニティは、このプロトコルが最初に設計された時には予想していなかったサービスが重要になったと考えている。そのようなサービスのサポートを追加する場合、古い実装でも正しく動作するような方法で行わなければならない。この拡張のフレームワークは以下の要素から成る：
SMTP の強さは、主にその簡潔さによるものである。多くのプロトコルにおける経験により、少数のオプションを持つプロトコルは広まる傾向があるのに対し、多数のオプションを持つプロトコルはあいまいな状態になる傾向があることが明らかになっている。
全ての拡張機能は、その恩恵に関係なく、その実装・展開・互換性のコストに付いて注意深く精査されなければならない。多くの場合、SMTP サービスを拡張するためのコストは、それによる恩恵を上回るだろう。
SMTP サービス拡張のレジストリは、IANA によって保守されている。キーワード EHLO に関連する値は各拡張に対応する。IANA により登録された各サービス拡張は、公式なスタンダードトラックまたは IESC 認可の実験プロトコルの文書において定義されなければならない。その定義は以下の内容を含まなければならない：
加えて、大文字または小文字の "X" で始まる EHLO キーワードの値は、双方の合意によって排他的に使用されるローカルの SMTP サービス拡張を示す。"X" で始まるキーワードを公式のサービス拡張に使用してはならない(MUST NOT)。逆に言えば、"X" で始まらない EHLO レスポンスのキーワード値は、IANA によって登録された標準・標準トラック・IESG 認可の実験的 SMTP サービス拡張、この何れかに該当しなければならない(MUST)。適合するサーバーは、公式な拡張に記述が無く "X" で始まらないキーワード値を提供してはならない(MUST NOT)。
追加のコマンドとパラメータ名は EHLO キーワードと同じ規則に縛られるが、"X" で始まるコマンドは、公式または標準化されなくても良いローカルの拡張である。逆に言うと、"X" で始まらない拡張は、通常公式なものでなければならない。
この文書におけるキーワード "MUST" "MUST NOT" "REQUIRED" "SHALL" "SHALL NOT" "SHOULD" "SOULD NOT" "RECOMMENDED" "MAY" "OPTIONAL" は、以下のように解釈される。
SMTP はメールオブジェクトを転送する。メールオブジェクトには、エンベロープと内容とが含まれる。
SMTP エンベロープは一連の SMTP プロトコルユニットとして送信される(セクション 3 で説明されている)。それには送信者のアドレス(エラーレポートが送られるべきアドレス)、１つ以上の受信者のアドレス、任意のプロトコル拡張の要素が含まれる。歴史的に、受信者アドレスを特定するコマンド(RCPT TO)のバリエーションは、代替の配送モードを指定するために使用することが出来たが、現在ではそのようなバリエーションは非推奨となっている(付録 F のセクション F.6 参照)。
SMTP の内容は SMTP DATA プロトコルユニットの中で送信され、２つの部分、ヘッダとボディとを持つ。その内容が現在の別の標準に従う場合、ヘッダはメッセージフォーマット仕様[32] にあるようなフィールド/値のペア構造を形成し、ボディは(構造化されている場合) MIME[12] に従って定義される。また内容は本質的にテキスト表現であり、US-ASCII [1] を使って表現される。ボディのこの制限は SMTP 拡張(例えば "8BITMIME" [20])により緩和されても良いが、ヘッダは通常 US-ASCII を使ってエンコードされる。MIME 拡張 [23] は、ヘッダを US-ASCII でエンコードしながら、US-ASCII 範囲外のヘッダ値を表現するアルゴリズムを定義している。
RFC 821 では、SMTP トランザクションに参加している２つのホストはそれぞれ、"SMTP-送信者(SMTP-sender)" および "SMTP-受信者(SMTP-receiver)" として記述されていた。この文書では現在の業界用語を繁栄するためにそれを変更し、それぞれ "SMTP クライアント"(または単に "クライアント")、"SMTP サーバー"(または単に "サーバー")として言及する。リレーする状況においては、あるホストがサーバーとクライアントとの両方の動作をする可能性があるため、明確性のために必要な場合は "受信者(receiver)"・"送信者(sender)" という用語も使用されている。
RFC 821 の公開以降、追加のメールシステムテクノロジーが一般的になっており、有用な場合にはこの仕様でも使用されている。具体的には、SMTP のサーバーとクライアントはメール転送サービスを提供しており、従って "メール転送エージェント(Mail Transfer Agents)"(MTA) として振る舞う。また "メールユーザーエージェント(Mail User Agents)"(MUA または UA)は、一般にメールの送信元および送信先と見なされる。送信元では MUA は送信されるべきメールをユーザーから収集し、それを MTA へと渡すだろう。最終("配送") MTA は、MUA(または少なくとも、MUA へと(例えばメッセージを "メッセージストア" に入れることにより)転送する責任者)へとメールを渡すと考えられるだろう。しかしながら、他の環境においてこれらの用語は少なくともかなり似た意味で使用されるとはいえ、MUA と MTA との暗黙的な境界は、しばしばインターネットメールの通例や適合、慣例に正確には一致しない。従って読者は、これらの用語が別の場所で使われている場合には、そこに暗示されているかもしれない強い関連性と責任とを推測することに注力するべきである。
この仕様の目的のためには、ホストはインターネット(またはプライベートの TCP/IP ネットワーク)に接続しており、SMTP プロトコルをサポートするコンピュータシステムである。ホストは名前で知られる("ドメイン" 参照)ものであり、数字のアドレスにより識別することは推奨されない。
ドメイン(あるいはドメイン名)は、ドットで区切られた１つ以上の要素から構成される。SMTP の目的のために、これらの構成要素(DNS 用語では "ラベル" [22])は、ASCII 文字セット [1] から抜粋された文字・数字・ハイフンから構成されるように制限されている。ドメイン名はドメイン名階層におけるホストの名前、およびその他のエンティティの名前として使用される。例えばドメインは、ホスト名を表す代わりに、別名(CNAME RR ラベル)またはメール配送に使用されるメールエクスチェンジャのラベルを参照しても良い。[22] とこの仕様のセクション 5 とを参照してほしい。
この文書と [22] とで説明されているように、ドメイン名は完全で、省略されていない名前(しばしば "FQDN" と言及される)である。FQDN 形式ではないドメイン名はローカルの別名にすぎない。どのような SMTP トランザクションであれ、ローカルの別名が現れてはならない(MUST NOT)。
SMTP セッションはステートフルであり、両参加者が注意深く現在の状態の共有ビューを保持する。この文書ではその状態を、サーバー上の仮想の "バッファ" と "状態テーブル(state table)" とによりモデル化する。クライアントはこれを、例えば "バッファクリア(clear the buffer)"(バッファ内の情報を破棄する) や "状態テーブルのリセット(reset the state table)"(以前の状態に戻す) のように使用して良い。
SMTP コマンドおよび(サービス拡張によって変更されない限り)メッセージデータは、"行" 単位で送信される。行は、ASCII 文字 "CR"(16 進 0D)の直後に ASCII 文字 "LF" (16 進 0A) が続くシーケンスによって終了するゼロ個以上のデータ文字から成る。この文書では、この終端シーケンスを "CRLF" と表現する。適合する実装は、行終端としてこれ以外の文字や文字のシーケンスを認識、または生成してはならない(MUST NOT)。サーバーによって行の長さに制限が課されても良い(MAY)(セクション 4.5.3 参照)。
加えて、テキスト中への "CR" または "LF" "そのもの(bare)" の出現(つまり、どちらか単独の文字)は、メール実装とツールとしてメールシステムを使用するアプリケーションとにおいて、問題を起こしてきた長い歴史がある。SMTP クライアントの実装は、行終端を意図する場合を除いてこれらの文字を送信してはならず(MUST NOT)、したがって前述のように、必ず <CRLF> というシーケンスとして送信しなければならない。(MUST)。
この仕様では、電子メール転送においてシステムが果たす役割に基づき、SMTP システムを４種類に区別する。"送信(originating)" システム(時に SMTP 送信者と呼ばれる)は、インターネット(またはより一般的にはトランスポートサービス環境)へとメールを送り込む。"配送(delivery)" SMTP システムはトランスポートサービス環境からメールを受け取り、それをメールユーザエージェントに渡すか、後にメールユーザエージェントがアクセスするであろうメッセージストアへとメールを投入する。"リレー(relay)" SMTP システム(通常は単に "リレー" と呼ばれる)は SMTP クライアントからメールを受け取り、トレース情報の追加以外にはメッセージに変更を加えず、更なるリレーまたは配送のために別の SMTP サーバーへとそのメールを転送する。
"ゲートウェイ(gateway)" SMTP システム(通常は単に "ゲートウェイ" と呼ばれる)は、あるトランスポート環境のクライアントシステムからメールを受け取り、それを別のトランスポート環境にあるサーバーシステムへと転送する。ゲートウェイの両側のトランスポート環境間のプロトコルやメッセージの動作の違いは、SMTP リレーシステムには許可されていないメッセージ変換を行うゲートウェイシステムを必要とする可能性がある。この仕様のためには、アドレスを書き換えるファイアウォールは、例えそのファイアウォールの両側で SMTP が使われている場合でも、ゲートウェイと見なされるべきである[11]。
DATA コマンドが受け付けられてからデータ終了指示が送信されるまでに転送される内容を説明するために、この文書では用語 "メッセージ内容" および "メールデータ" が同義的に使用される。メッセージ内容は、メッセージヘッダと、場合によっては構造化されたメッセージボディとを含む。MIME 仕様 [12] は構造化メッセージボディのための標準的メカニズムを提供している。
この仕様で使用される限りにおいて、"アドレス" とは、メールが送信されるユーザー、またはメールが投入される場所を識別する文字列である。用語 "メールボックス" はその保管場所を表す。メールが置かれる場所(メールボックス)とその参照(アドレス)との区別が重要ではない限り、この２つの用語は同義的に使用される。アドレスは通常、ユーザーとドメインの指定から成る。標準的なメールボックスの命名規則は、"local-part@domain" と定義されている： 最新の使用法は、単純な "ユーザー名" よりさらに広範囲な応用を許可している。その結果、および中間ホストがそれらを修正することで転送を最適化しようとする場合の問題の長い歴史の結果、loca-part の意味の解釈および割り当ては、そのアドレスのドメイン部で指定されているホストによってのみ行われなければならない。(MUST)
SMTP リプライは、コマンドへの応答として受信者から送信者へと通信チャネル経由で送信される通知(肯定または否定)である。リプライの一般的な形式は、数字の完了コード(成功か失敗かを表す)と、通常はそれにテキスト文字列が続く。コードはプログラムによって使用されること、テキストは人間の利用者向けに使用されることを意図されている。最近の著作物 [34] はリプライ文字列のさらなる構造化を規定しており、補助的かつより具体的な完了コードを表す。
SMTP のコマンドとリプライは厳格な文法を持つ。全てのコマンドはコマンド動詞で始まる。全てのリプライは 3 桁の数字コードで始まる。一部のコマンドとリプライは、その動詞またはリプライコードの後に引数が続かなければならない(MUST)。一部のコマンドは(その動詞の後に)引数を受け取らず、一部のリプライコードの後には(時に任意で)フリーフォームのテキストが続く。どちらの場合でもテキストが現れる場合、コマンドまたはリプライコードとテキストとは空白文字で区切られる。コマンドとリプライの完全な定義はセクション 4 に示されている。
動詞と引数(例えば RCPT コマンド中の "TO" または "to"、および拡張名キーワード)は、大文字・小文字を区別されない。唯一の例外はメールボックスの local-part の仕様である(SMTP 拡張は大文字･小文字を区別する要素を明示的に規定しても良い)。すなわちこれは、コマンド動詞、メールボックスの local-part 以外の引数の値、フリーフォームテキストは、それぞれその意味に影響を与えることなく、大文字、小文字、あるいは大文字・小文字の任意の組み合わせにエンコードされて良い(MAY)ということである。これはメールボックスの local-part には当てはまらない。メールボックスの local-part は大文字･小文字が区別されなければならない(MUST)。したがって SMTP 実装は、メールボックスの local-part の大文字・小文字を保持するように注意しなければならない(MUST)。メールボックスのドメイン名は大文字・小文字を区別しない。具体的に一部のホストでは、ユーザー "smith" とユーザー "Smith" とは異なる。しかしながらメールボックスの local-part の大文字・小文字の区別を乱用することは相互運用性を低下させるため、推奨されない。
この仕様(および RFC 821)に違反して、少数の SMTP サーバーは、クライアントによってコマンド動詞が大文字にエンコードされることを必要とする。実装はそのようなサーバーに適応するために、そのようなエンコードを採用することを望んでも良い(MAY)。
引数フィールドは可変長の文字列から成り、行端(すなわち文字シーケンス <CRLF>)で終わる。受信者はこのシーケンスを受信するまで何のアクションも起こさないだろう。
各コマンドの文法は、それぞれのコマンドに関する議論と共に示されている。共通の要素と引数はセクション 4.1.2 で示されている。
コマンドとリプライは、ASCII 文字セット[1] から構成される。トランスポートサービスが 8 ビットバイト(オクテット)の通信チャネルを提供する場合、7 ビット文字はそれぞれ最上位ビットが 0 で右詰される。より具体的に言うと、拡張されていない SMTP サービスは 7 ビットのトランスポートのみを提供するということである。特定のサーバーとの適切な拡張の交渉に失敗した送信 SMTP クライアントは、オクテットの最上位ビットに情報を入れたメッセージを送信してはならない(MUST NOT)。この規則に違反してそのようなメッセージが送信された場合、受信側 SMTP サーバーは最上位ビットをクリアするか、そのメッセージを無効であるとして拒否するかして良い(MAY)。一般にリレー SMTP は、受信したメッセージの内容を有効であると見なし、エンベロープがリレーを許可している前提で、内容を調べることなくリレーするべきである(SHOULD)。当然ながら、その内容が間違ってラベル付けされており、かつそのデータパスが実際の内容を受け付けない場合、酷く文字化けしたメッセージを受信者へ配送することになるだろう。配送 SMTP システムはそのようなメッセージを配送するのではなく、拒否("バウンス")しても良い(MAY)。送信を行わない SMTP システムが US-ASCII 以外の任意の文字セットによるエンベロープコマンドを送信することは許されない。通常、受信システムはそのようなコマンドを、リプライ "500 syntax error - invalid character" を使用して拒否するべきである(SHOULD)。
8 ビットの内容を含むメッセージの送信は、拡張 SMTP 能力(特に "8BITMIME" 拡張 [20])を使用するクライアントによってサーバーに要求されてもよい(MAY)。SMTP サーバーは 8BITMIME をサポートするべきである(SHOULD)が、それは 8 ビット要素を無制限に送信することを許可されたものと見なされてはならない(MUST NOT)。送信者は、最上位ビットがオンであるが適切なコンテンツ転送エンコードを用いた MIME フォーマットには従っていない要素のために、8BITMIME を要求してはならない(MUST NOT)。サーバーはそのようなメッセージを拒否しても良い(MAY)。
この文書で使用されているメタ言語表記法は、他のインターネットメールシステムの文書で使用されている "拡張 BNF(Augmented BNF)" と一致している。その文法に精通していない読者は ABNF 仕様 [8] を参考にするべきである。本文中で使用されているメタ言語用語は、それを明確にするために、小なり記号・大なり記号で囲われている(例 <CRLF>)。
このセクションでは SMTP で使用される手続き、セッション開始・メールトランザクション・メール転送・メールボックス名の検証とメーリングリストの展開・手続きの開始と終了について説明している。リレーに関するコメント、メールドメインに対する注意、役割の変更に関する議論は、このセクションの最後に書かれている。付録 D にいくつかの完全なシナリオが示されている。
SMTP セッションはクライアントがサーバーへの接続を開いたときに始まり、サーバーはオープニングメッセージで応答する。
SMTP サーバー実装は、コード 220 に続く接続挨拶のリプライ中に、そのソフトウェアとバージョンとを識別する情報を含めても良い(MAY)(あらゆる問題のより効率的な切り分けと回復とを可能にする習慣である)。セキュリティの懸念がある場合のために、実装はソフトウェアとバージョンのアナウンスを SMTP サーバーが無効にする方法を提供しても良い(MAY)。一部のシステムはここでメールトラブルのための連絡先を指定するが、これは必須である "postmaster" アドレスを保守することの代替ではない(セクション 4.5.1 参照)。
SMTP プロトコルは次のように、サーバーが初期接続を許可する一方で公式にトランザクションを拒否することを許可している：サーバーは初期接続のオープニングメッセージ中に 220 の代わりに 554 の応答を返しても良い(MAY)。この方法を採用するサーバーは、接続を閉じる前にクライアントが QUIT (セクション 4.1.1.10 参照)を送信するのを待たなければならず(MUST)、間に入る全てのコマンドに対して "503 bad sequence of commands" を返すべきである(SHOULD)。このようなシステムへの SMTP 接続の試みはほぼ確実にエラーになるため、接続開始時に 554 レスポンスを返すサーバーは、送信側システムのデバッグ作業を容易にするために、リプライテキスト中に十分な情報を提供するべきである(SHOULD)。
一旦サーバーがウェルカムメッセージを送信しクライアントがそれを受信した時点で、クライアントは通常 EHLO コマンドをサーバーに送信することで自身の身元を明らかにする。セッションを開いた上でさらに EHLO を使用することは、そのクライアントにサービス拡張を処理する能力があることを表し、サーバーがサポートしている拡張の一覧を提供するように要求していることになる。サービス拡張をサポートする能力のない古い SMTP システムや、サービス拡張を必要としないクライアントがメールセッションを開始する場合、EHLO の代わりに HELO を使用しても良い(MAY)。HELO コマンドに対し、サーバーは拡張された EHLO スタイルのレスポンスを返してはならない(MUST NOT)。ある接続の試行において EHLO に対しサーバーが "command not recognized" を返した場合、クライアントはフォールバックし、HELO を送信するべきである(SHOULD)。
EHLO コマンドを送信するホストは、そのコマンドの中で自分自身の身元を明らかにする。そのコマンドは "Hello, I am <domain>(こんにちは、私は <domain> です)" (EHLO の場合はさらに "and I support service extension requests(私はサービス拡張リクエストをサポートしています)")と解釈されるだろう。
SMTP のメールトランザクションには３つのステップが存在する。トランザクションはまず、送信者の識別を与える MAIL コマンドで始まる(一般に MAIL コマンドはメールトランザクションが処理中でないときにのみ送信して良い。セクション 4.1.4 参照)。受信者情報を与える１つ以上の RCPT コマンドがそれに続く。そして DATA コマンドがメールデータの送信を開始し、"メール終了(end of mail)" を表すデータインジケータで終了する(これはトランザクションの承認も行う)。
この手続きにおける第一のステップは、MAIL コマンドである。
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
このコマンドは新しいメールトランザクションを開始することを SMTP-受信者に伝え、また、状態テーブルとバッファ(全ての受信者やメールデータを含む)とを全てリセットするように伝える。最初の、あるいは唯一の引数である <reverse-path> は、送信元メールボックス("<" と ">" との間)を含んでおり、これはエラーを報告するために使用できる(セクション 4.2 のエラーレポートに関する議論参照)。これが受け入れられる場合、SMTP サーバーは 250 OK リプライを返す。何らかの理由によりそのメールボックスの指定が受け入れられない場合、サーバーは、その失敗が永続的なもの(つまり、クライアントが再度同じアドレスを送信しても再び発生するであろうエラー)なのか、一時的なもの(つまり、後でクライアントがリトライした時にはそのアドレスが受け入れられるかもしれないエラー)なのかを表すリプライを返さなければならない(MUST)。この要求の明確な意図にもかかわらず、(RCPT コマンド中の)１つ以上の forward-path が検査可能になるまで reverse-path の受け入れ可能性が確認されない環境が存在する。そのような環境の場合、サーバーは合理的に、reverse-path を(250 リプライにより)受け入れ、次に forward-path を受け取って確認した後で問題を報告しても良い(MAY)。一般に失敗は 550 リプライ、または 553 リプライを生成する。
歴史的に <reverse-path> は１つのメールボックス以上の内容を含むことが出来るが、最新のシステムはソースルーティングを使用するべきではない(SHOULD NOT)(付録 C 参照)。
オプションである <mail-parameters> は、交渉済み SMTP サービス拡張に関連する(セクション 2.2 参照)。
この手続きにおける第二のステップは、RCPT コマンドである。
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
このコマンドの最初の、あるいは唯一の引数は、１つの受信者を識別する forward-path (通常はメールボックスとドメインであり、常に "<" と ">" とで囲まれている)を含む。これが受け入れられる場合、SMTP サーバーは 250 OK リプライを返し、その forward-path を保存する。その受信者が配送不能であると分かった場合、SMTP サーバーは 550 リプライ(典型的には "no such user - " にメールボックス名が続く文字列)を返す(これ以外の事情やリプライコードも可能である)。このステップは任意の回数繰り返すことが出来る。
<forward-path> には１つのメールボックス以上の内容を含むことが出来る。歴史的に、<forward-path> はソールルーティングのリストと宛先メールボックスとであることが出来るが、最新の SMTP クライアントはソースルーティングを利用するべきではない(SHOULD NOT)(付録 C 参照)。サーバーは forward-path 内でソースルートのリストに遭遇する準備が出来ていなければならない(MUST)が、そのルートを無視するべき(SHOULD)であり、あるいはそのリレーのサポートを拒否しても良い(MAY)。また同様にサーバーは、他のホストやシステム宛てのメールの受け付けを拒否しても良い(MAY)。これらの制限によりそのサーバーは、完全な SMTP 機能をサポートしないクライアントのためのリレーとしては使えないものになる。従って機能が制限されているクライアントは、インターネット上の全ての SMTP サーバーが、メールを処理する(リレーする)サイトとして利用可能であると仮定してはならない(MUST NOT)。MAIL コマンド無しに RCPT コマンドが現れた場合、サーバーは503 "Bad sequence of commands" レスポンスを返さなければならない(MUST)。オプションである <rcpt-parameters> は、交渉済み SMTP サービス拡張に関連する(セクション 2.2 参照)。
この手続きにおける第三のステップは、DATA コマンド(またはサービス拡張で規定された何らかの別のコマンド)である。
DATA <CRLF>
受け入れられる場合、SMTP サーバーは中間リプライ 354 を返し、以降に続く全ての行(ただしメールデータの終わりを表すインジケータは含まない)をメッセージテキストと見なす。テキストの終了が正常に受信・保存されると、SMTP-受信者は 250 OK リプライを送信する。
メールデータは通信チャネル上を送信されるため、コマンドとリプライとによる対話が続けられるように、メールデータの終わりが示されなければならない。SMTP では "."(ピリオド、または終止符) だけを含む行を送信することでメールデータの終了を表す。これがユーザーの文章に干渉しないように、透過的な手続きが使用される(セクション 4.5.2 参照)。
またメールデータ終了インジケータは、メールトランザクションを承認し、保存されている受信者とメールデータとを処理するように SMTP サーバーに伝える。受け入れられる場合、SMTP サーバーは 250 OK リプライを返す。このプロトコル交換において、DATA コマンドは次の２点でのみ失敗し得る：
しかしながら、実際のところ一部のサーバーは、メッセージテキストの受信後まで受信者の確認を行わない。このようなサーバーは、１つ以上の受信者の失敗を "事後障害(subsequent failure)" として扱い、セクション 6 で議論されているようなメールメッセージを返すべきである(SHOULD)。データ受け付け後にリプライコード "550 mailbox not found" を使用することは、どの受信者が失敗したのかをクライアントが判断することを困難、または不可能にする。
RFC 822 フォーマット [7, 32] が使われる場合、メールデータには Date、Subject、To、Cc、From などの記録用ヘッダ項目が含まれる。サーバー SMTP システムは、RFC 822 または MIME [12] のメッセージヘッダやメッセージボディ内で認識された欠陥に基づいてメッセージを拒否するべきではない(SHOULD NOT)。特に、Resent-field の数が合わないメッセージや、Resent-from / Resent-date 無しに Resent-to が現れるメッセージを拒否してはならない(MUST NOT)。
メールトランザクションのコマンドは、上記で議論されている順序で使用されなければならない(MUST)。
転送サポートは、企業内部の(または企業に関連する)アドレスを単純化かつ強化するために非常にしばしば、また頻度は低いものの、ある人の以前のアドレスと現在のアドレスとを関連付けるために必要とされる。セキュリティや非公開の目的のため、現在のインターネットではメッセージのサイレント転送(サーバーから送信者への通知がない転送)が一般的である。
企業の場合も "新規アドレス(new address)" の場合も、転送動作の副作用として SMTP プロトコルを通して "最終(final)" アドレスを公開することは、情報隠蔽(時にセキュリティ)の配慮と相反する。これは、送信者でさえ最終アドレスに到達できない可能性がある場合に特に重要である。その結果として、RFC 821 のセクション 3.2 で説明されている "転送" メカニズムと、特に RCPT からの 251 リプライ(訂正済み宛先)と 551 リプライとは、実装者によって、また(それらが利用可能な場合には)システムをそのように構成する人によって、注意深く評価されなければならない。
詳細：
代替
リプライコードの 251 や 551 をサポートする SMTP サーバー実装は、情報公開を望ましくないと判断したサイトが、それらの使用を無効化または制限するための設定メカニズムを提供することが強く推奨される。
SMTP は、ユーザー名を確認したり、メーリングリストの内容を取得したりするためのコマンドを提供している。これは VRFY コマンドおよび EXPN コマンドで実現され、それぞれ文字列の引数を取る。実装は VRFY と EXPN とをサポートするべきである(SHOULD)(ただし、セクション 3.5.2 と 7.3 参照)。
VRFY コマンドの場合、文字列はユーザー名、またはユーザー名とドメインである(下記参照)。通常のレスポンス(すなわち 250)が返される場合、そのレスポンスにはそのユーザーのメールボックスを含まなければならず(MUST)、そのユーザーのフルネームを含んでもよい(MAY)。これは以下の形式の何れかでなければならない(MUST)。
User Name <local-part@domain> local-part@domain
VRFY の引数の名前から２つ以上のメールボックスが特定可能な場合、サーバーはその不明確さを指摘するか、代替案を指定してよい(MAY)。言い換えると、以下の何れかが VRFY への正当な応答である。
553 User ambiguous
または
553- Ambiguous; Possibilities are 553-Joe Smith <jsmith@foo.com> 553-Harry Smith <hsmith@foo.com> 553 Melvin Smith <dweep@foo.com>
または
553-Ambiguous; Possibilities 553- <jsmith@foo.com> 553- <hsmith@foo.com> 553 <dweep@foo.com>
通常の環境では、553 リプライを受け取ったクライアントは、その結果をユーザーに公開したいだろう。与えられた形式(およびキーワード "user ambiguous" または "ambiguous")の正確な使用は、おそらく [34] で説明されているような拡張リプライコードによって補完され、必要に応じて他の言語に自動的に翻訳されるのを容易にするだろう。もちろん、高度に自動化されたクライアントや、英語以外の言語で運用されているクライアントは、その応答を翻訳したり、リプライのリテラルテキスト以上の何らかの指示をユーザーに返したり、ユーザーに報告する前に追加情報のためにディレクトリサービスを参照するなどの自動的な動作を行ったりしようとしても良い。
EXPN コマンドの場合、引数の文字列はメーリングリストを表し、成功(つまり 250)の複数行のレスポンスはメーリングリスト上のメールボックス名を含まなければならず(MUST)、ユーザーのフルネームを含んでもよい(MAY)。
一部のホストでは、メーリングリストと単一のメールボックスへのエイリアスとの区別は、共通のデータ構造がこの両方の種類のエントリーを保持してもよく、またただ１つのメールボックスを含むメーリングリストを持つことも可能なため、ややあいまいである。あるリクエストによりメーリングリストに VRFY が適用された場合、メッセージがそのリスト上の全員に配送される場合には肯定レスポンスを与えられて良い(MAY)が、そうでなければエラーが報告されるべきである(SHOULD)(例えば "550 That is a mailing list, not a user" または "252 Unable to verify members of mailing list")。リクエストがユーザー名に適用された場合、サーバーは１つの名前だけを含むリストから構成される肯定レスポンスを返しても良い(MAY)し、エラーを報告しても良い(MAY)(例えば "550 That is a user name, not a mailing list")。
成功の複数行リプライ(EXPN では普通である)の場合、そのリプライの各行毎に正確に１つのメールボックスが特定される。あいまいなリクエストの場合については上記で議論されている。
"ユーザー名(User name)" はあいまいな用語であるが、故意に使用されてきた。VRFY または EXPN の実装は、少なくともローカルのメールボックスを "ユーザー名" として認識しなければならない(MUST)。しかしながら現在のインターネットの慣例は、複数ドメインや複数ホストのメールを処理する単独のホストを生じさせているため、特にこの機能を提供するホストは、"ユーザー名" として "local-part@domain" 形式を受け入れるべきである(SHOULD)。またホストは、"ユーザー名" として別の文字列を認識するという選択をしても良い(MAY)。
メールボックスのリストを展開する場合、次のような複数行のリプライが要求される：
C: EXPN Example-People S: 250-Jon Postel <Postel@isi.edu> S: 250-Fred Fonebone <Fonebone@physics.foo-u.edu> S: 250 Sam Q. Smith <SQSmith@specific.generic.com>
または
C: EXPN Executive-Washroom-List S: 550 Access Denied to You.
ユーザー名とメールボックスリストとの概念の実装の多様性のため、VRFY コマンドと EXPN コマンドとの文字列引数をこれ以上制限することは出来ない。一部のシステム上では、メーリングリストを含むファイルのファイル名を EXPN コマンドの引数に当てるのが適切かもしれないが、インターネット上には様々なファイル命名規則が存在する。同様に、これらのコマンドによって返される内容の歴史的なバリエーションもそのようなものであるので、そのレスポンスは非常に注意して解釈されるべき(SHOULD)であり、もし解釈されるとしても、一般に診断目的でのみ使用されるべきである(SHOULD)。
VRFY または EXPN から通常レスポンス(2yz または 551)が返されるとき、そのリプライは通常メールボックス名(すなわち "<local-part@domain>"("domain" は完全限定ドメイン名)を構文内に含まなければならない(MUST))を含む。この仕様の目的に違反するのを正当化するのに十分なほど例外的な環境では、フリーフォームのテキストが返されても良い(MAY)。コンピュータと人間との両方による解析を容易にするために、アドレスは小なり記号・大なり記号の内側に置かれるべきである(SHOULD)。(フリーフォームのデバッグ情報ではなく)アドレスが返される場合、EXPN と VRFY は、SMTP の RCPT コマンドで使用可能な有効なドメインアドレスのみを返さなければならない(MUST)。したがって、アドレスがプログラムまたは他のシステムへの配送を示唆している場合、その目的地へ到達するために使用されるメールボックス名が与えられなければならない(MUST)。VRFY または EXPN によって経路(明示的なソースルート)が返されてはならない(MUST NOT)。
サーバー実装は VRFY と EXPN とを両方サポートするべきである(SHOULD)。セキュリティを理由に、構成オプションまたはそれと同等な手段を通じて、実装はこれらのコマンドの何れか、または両方を無効にするローカルな手段を提供しても良い(MAY)。これらのコマンドがサポートされる場合、リレーがサポートされるのであれば、リレーを超えて動作する必要はない。RFC 821 においてこれらは 共にオプションであるため、サポートされる場合には EHLO レスポンスのサービス拡張として挙げられなければならない(MUST)。
実際にアドレスが確認されない限り、VRFY コマンドまたは EXPN コマンドへの応答としてコード 250 が返されてはならない(MUST NOT)。特に、文法が有効であることを確認しただけの場合、サーバーは 250 を返してはならない(MUST NOT)。その場合 502 (Command not implemented(コマンドが実装されていない))または 500 (Syntax error, command unrecognized(文法エラー、コマンドは認識されない))が返されるべきである(SHOULD)。別のところで述べられている通り、(実際にアドレスの有効性を確認することと情報を返すこと、という意味において) VRFY の実装と EXPN の実装とは強く推奨される。従って、VRFY に対して 500 または 502 を返す実装は、この仕様に完全には適合しない。
特に、サーバーが別のサーバーまたはドメインのためのメールエクスチェンジャとして動作しているような場合、あるアドレスが有効だと思われるが、リアルタイムには合理的に確認できないような環境が存在するかもしれない。通常このような場合の "明白な正当性(Apparent validity)" とは、最低でも文法チェックを含み、指定されたドメインがそのホストによりリレー可能なものであることの確認も含むかもしれない。このような状況では、リプライコード 252 が返されるべきである(SHOULD)。これらのケースは、セクション 2.1 で議論されている RCPT の検証の議論と同等である。同じようにセクション 3.4 での議論は、認識はされたが転送またはバウンスされるかもしれないアドレスが、そのために受信されたメールであったことを示すために、VRFY(または EXPN) に対してリプライコード 251 と 551 とを使用する場合に適用される。一般に実装は、たとえ多少時間がかかるとしても、VRFY の場合のアドレス確認には RCPT の場合よりも積極的になるべきである(SHOULD)。
メーリングリストと複数アドレスへのエイリアスとに伴う問題の理解とデバッグとにおいて、EXPN はしばしば非常に便利である。一部のシステムは、重複を削減する手段としてメーリングリストのソース展開を利用することを試みてきた。インターネット上でのメールのエイリアスシステム(ホスト向け(一般的に DNS レコードの MX と CNAME)、メールボックス向け(様々な種類のローカルホストエイリアス機能)、そして様々なプロキシ処理において)の普及は、このような戦略が一貫して正しく動作することをほとんど不可能にした。メールシステムはこれを試みるべきではない(SHOULD NOT)。
SMTP においてドメイン名が必要とされる場合、解決可能な完全限定ドメイン名(FQDN)のみが許される。言い換えると、MX RR または A RR (セクション 5 で議論されている)に解決され得る名前が許可される。MX RR または A RR に解決可能な CNAME RR も同様に許可される。ローカルのニックネームや限定されない名前が使われてはならない(MUST NOT)。FQDN を要求するこの規則には、２つの例外が存在する：
一般にドメインネームシステム [22, 27] における Mail eXchanger レコードの可用性は、インターネットのメールシステムにおける明示的なソースルーティングの利用を不要なものとする。その解釈に伴う多くの歴史的問題は、その利用を好ましくないものにした。例外的な環境を除き、SMTP クライアントは明示的なソースルーティングを生成するべきではない(SHOULD NOT)。SMTP サーバーは、メールリレーとして動作したり、ソースルーティングが指定されたアドレスを受け付けたりすることを拒否しても良い(MAY)。ルート情報に出くわした場合、SMTP サーバーはそのルート情報を無視して、そのルートの最終要素として指定されている最終的な宛先へと単純に送信することも許可されており、そうするべきである(SHOULD)。ソースルーティングに指定された中間ホストを問題解決の当てにして、DNS に現れない名前を宛先名として使用するという正しくない慣例が存在した。ソースルーティングが取り除かれると、この試みは失敗するだろう。SMTP クライアントが無効なソースルーティングを決して生成してはならない(MUST NOT)理由、または名前の逐次的解決に頼ってはならない(MUST NOT)理由のひとつがこれである。
ソースルーティングが使用される場合、forward-path から reverse-path を構築するのに RFC 821 で説明されている手順は適用されず、配送時の reverse-path がそのまま MAIL コマンド内に現れるアドレスになるだろう。
一般にリレー SMTP サーバーは、最終的な配送システムではなく、リレーサーバーを指定する DNS MX のターゲットとなる。ローカルユーザーへのメールを受け付けたり拒否したりするのと同様に、リレーサーバーはメールをリレーするタスクを受け付けたり拒否したりして良い。そのタスクを受け付ける場合、その後そのサーバーは SMTP クライアントとなり、(セクション 5 の規則に従い)DNS で指定されている次の SMTP サーバーへの通信チャネルを確立し、そこにメールを送信する。ポリシーを理由に特定アドレスへのメールのリレーを拒否する場合、550 レスポンスが返されるべきである(SHOULD)。
この仕様の一部(例えば連続的な配送試行のためのメッセージのキューイング)をサポートする能力が限られているメール送信クライアントが数多く存在する(特に POP3 や IMAP 経由でメールを受信する能力を併せ持つクライアント)。このようなクライアントのために、メールの処理とその後の配送とを行う単一サーバーを用意し、全てのメッセージをそのサーバーに送信するというのが一般的な慣例である。ここで規定されている SMTP はこの役割に理想的には適合せず、最終的に現在の慣例に取って代わるであろう標準化されたメール投入プロトコルが作成中である。いずれにしても、このようなサーバーの手配はプライベートなものであり、この仕様の範囲に入らないため、この文書では説明されない。
MX レコードは SMTP リレーや最終配送システムを指すだけではなく、別環境へのゲートウェイとして動作している SMTP サーバーを指すことも出来ることに注意することは重要である。
SMTP サーバーがメールをリレーするタスクを受け付けた後に宛先が間違っていることが分かったり、何らかの理由により配送でき無かったりした場合、サーバーは "undeliverable mail(配送不能)" 通知メッセージを作成し、その配送不能メールの(reverse-path により指定されている)送信元にそのメッセージを送信しなければならない(MUST)。可能であれば、別の標準(例えば [24, 25] 参照)によって規定されている配送不能レポート(non-delivery report)の書式が使用されるべきである(SHOULD)。
この通知メッセージは、リレーホスト上の SMTP サーバーからか、配送が不可能であることを最初に判断したホストの SMTP サーバーから送られなければならない。当然ながら SMTP サーバーは、通知メッセージ転送中の問題に関する通知メッセージを送信してはならない(MUST NOT)。エラー報告中のループを避ける１つの方法は、通知メッセージの MAIL コマンドに空の reverse-path を指定することである。このようなメッセージが送られる場合、その reverse-path には空がセットされなければならない(MUST)(追加議論についてセクション 4.5.5 を参照)。空の reverse-path を伴う MAIL コマンドは、以下のようになる：
MAIL FROM:<>
セクション 2.4.1 で議論されているように、リレー SMTP はメッセージデータのヘッダ部やボディ部を検査したり、それに基づいて動作したりする必要はなく、自分自身の "Received:" ヘッダを追加する場合(セクション 4.4 参照)と、任意でメールシステムのループを検出する試みを行う場合(セクション 6.2 参照)とを除き、そうしてはならない(MUST NOT)。
前述のリレー機能はインターネットの SMTP トランスポートサービス環境内で動作する一方、MX レコードや明示的なルーティングの様々な形式は、あるトランスポートサービスと別のトランスポートサービスとの間での翻訳機能を実行する中間 SMTP サーバーを必要とする可能性がある。セクション 2.3.8 で議論されているように、そのようなシステムが２つのトランスポートサービス環境の境界に位置する場合、私達はそれを "ゲートウェイ(gateway)" または "ゲートウェイ SMTP(gateway SMTP)" と言及する。
異なるメール環境間でメールをゲートウェイすることは複雑で、簡単に標準を作成することが出来ない。しかしながら、インターネットと他のメール環境とのゲートウェイのために、いくつかの一般的な要求事項が示されている。
メール環境の境界をまたいでメッセージがゲートウェイされる場合、必要ならヘッダフィールドが書き換えられても良い(MAY)。これにはメッセージ本文の調査や、セクション 2.4.1 の禁止事項にもかかわらず、宛先アドレスのローカル部(loca-part)の解釈を含んでも良い。
インターネットにゲートウェイされている他のメールシステムは、しばしば RFC 822 のサブセットを使用するか、異なる文法で同様の機能を提供する。しかしそのようなメールシステムの一部は、SMTP エンベロープと同等の機能を持たない。従ってあるメッセージがインターネット環境を離れる場合、SMTP エンベロープ情報はそのメッセージヘッダに保持される必要があるだろう。可能な解決策は、エンベロープ情報を運ぶための新しいヘッダフィールド(例えば "X-SMTP-MAIL:" と "X-SMTP-RCPT:")を作成することだろう。しかしながらこれは、別環境内のメールプログラムの変更を必要とし、機密情報を公開するリスクがあるかもしれない(セクション 7.2 参照)。
インターネット環境から、またはインターネット環境へとメッセージを転送する場合、ゲートウェイは Received: 行を先頭に追加しなければならない(MUST)が、すでにヘッダ内に存在する Received: 行を変更してはならない(MUST NOT)。
別環境によって生成されたメッセージの "Received:" フィールドは、この仕様に正確に従う必要はない。しかしながら Received: 行の最も重要な用途はメール障害のデバッグであり、Received: 行を "調節(fix)" しようとする善意のゲートウェイによって、このデバッグが妨げられる可能性がある。非 SMTP 環境内で生成されるトレースフィールドの別の結果として、受信側システムはトレースフィールドの書式に基づいてメールを拒否してはならず(MUST)、これらのフィールド内の予期しない情報や書式を考慮して、極めて堅牢であるべきである(SHOULD)。
ゲートウェイは、自身が提供する Received フィールドの "via" 節内で、その環境とプロトコルとを示すべきである(SHOULD)。
ゲートウェイは、インターネット側からの SMTP コマンド内および RFC 822 ヘッダ内、全ての有効な RFC 822 メッセージ内の、全ての有効なアドレス形式を受け入れるべきである(SHOULD)。ゲートウェイによって生成されるアドレスとヘッダは、適切なインターネット標準(この仕様や RFC 822 を含む)に従わなければならない(MUST)。当然ながらゲートウェイは、他の SMTP システムのために、セクション 3.3 で説明されているようなソースルートを扱うための同じ規則に従う。
ゲートウェイは、インターネットメール環境に転送されるメッセージの全てのヘッダフィールドが、インターネットメールの必要条件を満たすことを確認しなければならない(MUST)。特に "From:"、"To:"、"Cc:" などの中に現れる全てのアドレスは、RFC 822 の文法を満たすように(必要なら)変換されなければならず(MUST)、また完全限定ドメイン名のみを参照しなければならず(MUST)、返信を送るために効率的かつ実用的でなければならない(MUST)。インターネットプロトコルから別環境のプロトコルへとメールを変換するのに使用される変換アルゴリズムは、他のメール環境からのエラーメッセージが(RFC 822 メッセージの "From:" フィールド(または他のフィールド)内にリストされている送信者ではなく) SMTP エンベロープ由来のリターンパスへと配送されることを確実にするべきである(SHOULD)。
同様に、別環境からインターネット環境へとメッセージを転送するとき、他環境によってリターンアドレスが提供されている場合は、ゲートウェイはそのエラーメッセージリターンアドレスに従って、エンベロープのリターンパスを設定するべきである(SHOULD)。他環境が同等の概念を持たない場合、ゲートウェイは最適な近似アドレスを選択して(最終手段としてはメッセージ送信者のアドレスを)使用しなければならない。
クライアントが QUIT コマンドを送信したとき、SMTP 接続は終了する。接続を閉じた後、サーバーは肯定リプライコードで応答する。
以下の場合を除き、SMTP サーバーは故意に接続を閉じてはならない(MUST NOT)：
特に、理解できないコマンドへの応答として接続を閉じるサーバーは、この仕様に違反することになる。不明なコマンドに対しては 500 リプライを発行し、クライアントからの追加の指示を待ち受けることで、サーバーは不明なコマンドへの耐性を持つことを期待される。
外部の手段により強制的に停止される SMTP サーバーは、終了する前に SMTP クライアントにレスポンスコード 421 を含む１行を送信することを試みるべきである(SHOULD)。SMTP クライアントは、次のコマンドを送信した後に、そのレスポンスコード 421 を通常通りに読み取るだろう。
接続の終了やリセット、またはクライアントの制御下にない環境要因による他の接続障害(この仕様の意図には違反するが、時にこれは避けられない)に直面した SMTP クライアントは、そのメールシステムの堅牢性を維持するために、451 レスポンスを受信したかのようにそのメールトランザクションを扱い、それに従って動作するべきである(SHOULD)。
SMTP 能力を持つホストは、複数配送のためのアドレス展開モデルとして、エイリアスとリストとの両方をサポートするべきである(SHOULD)。展開されたリストの各アドレスへとメッセージが配送または転送される場合、そのエンベロープのリターンアドレス("MAIL FROM:")は、そのリストを管理している人、またはその他の実体のアドレスに変更されなければならない(MUST)。しかしながらこの場合、メッセージヘッダ [32] は変更されずに残されなければならず(MUST)、特にメッセージヘッダの "From" フィールドは影響を受けない。
重要なメール機能は、仮想メールボックスアドレスを宛先メールボックスアドレスのリストへと変換(または "展開(expanding)" または "拡大(exploding)")することにより、単一メッセージを複数の宛先へ配送するメカニズムである。このような仮想メールボックス(時に "エクスプローダ(exploder)" と呼ばれる)にメッセージが送信された場合、展開されたリスト内の各メールボックスへとコピーが転送、または再配布される。サーバーはリスト上のアドレスを単純に利用するべきであり(SHOULD)、一部のアドレス(例えば送信者のアドレス)を除外するために発見的アルゴリズムのようなマッチング規則を適用することは、強く推奨されない。その展開規則に従って、私達はそのような仮想メールボックスを "エイリアス(alias)" または "リスト(list)" と分類する。
エイリアスを展開するために、受信メーラーはエンベロープ内の仮想メールボックスアドレスを、展開された各アドレスへと順番に単純に置換する。エンベロープの残りの部分とメッセージボディとは未変更のまま残される。その後メッセージは、展開された各アドレスへと配送、または転送される。
メーリングリストは "転送(forwarding)" ではなく、"再配布(redistribution)" による操作だと言って良い。リストを展開するために、受信メーラーはエンベロープ内の仮想メールボックスアドレスを、展開された全てのアドレスに置換する。最終配送者により生成される全てのエラーメッセージが、そのメッセージの送信者(通常はリストの内容を管理しておらず、一般にエラーメッセージを不快に思うだろう)ではなく、リストの管理者に返されるように、エンベロープ内のリターンアドレスが変更される。
SMTP コマンドは、ユーザーにより要求されるメール転送機能またはメールシステム機能を定義する。SMTP コマンドは <CRLF> で終わる文字列である。コマンドそのものは、引数が続く場合は <SP> で終わり、そうでない場合は <CRLF> で終わる。(より一層の相互運用性の利益を得るために、SMTP 受信者は最後の <CRLF> の前の空白を容認することが推奨される。) メールボックスの local-part 部分の文法は、受信側サイトの慣例と、セクション 4.1.2 で規定されている文法とに従わなければならない。SMTP コマンドは以下で議論されており、SMTP リプライはセクション 4.2 で議論されている。
メールトランザクションには、種々のコマンドの引数として伝えられる幾つかのデータオブジェクトが含まれる。reverse-path は MAIL コマンドの引数、forward-path は RCPT コマンドの引数、メールデータは DATA コマンドの引数である。これらの引数またはデータオブジェクトは送信され、トランザクションを終了させるメールデータ終了指示により伝えられる承認が行われるまで、保留されなければならない。このためのモデルは、データオブジェクトを保持するために、独立したバッファ(すなわち、reverse-path バッファ、forward-path バッファ、メールデータバッファ)が提供されるということである。特定のコマンドにより、特定のバッファへの情報追加や、１つ以上のバッファのクリアが発生する。
一部のコマンド(RSET、DATA、QUIT)は、引数を許可されないものと規定されている。サーバーにより特定の拡張が提案され、クライアントがそれを受け入れた場合を除き、クライアントはそのような引数を送信してはならず(MUST)、サーバーはそれらを含むコマンドを無効な文法として拒否するべきである(SHOULD)。
これらのコマンドは、SMTP サーバーに SMTP クライアントを識別させるために使用される。SMTP クライアントの完全限定ドメイン名が利用可能な場合、この引数フィールドにはそれが含まれる。SMTP クライアントが意味のあるドメイン名を持たない状況の場合(例えば、アドレスが動的に割り当てられており、逆引きレコードが利用不可能な場合)、クライアントはアドレスリテラル(セクション 4.1.3 参照)を送信するべき(SHOULD)であり、任意でクライアントの識別を手助けする情報を後に続ける。接続の最初の挨拶であるリプライの中と、このコマンドへの応答の中とで、SMTP サーバーは自分自身を SMTP クライアントに識別させる。
クライアント SMTP は EHLO コマンドの発行によって SMTP セッションを開始するべきである(SHOULD)。SMTP サーバーが SMTP サービス拡張をサポートする場合、そのサーバーは成功応答または失敗応答またはエラー応答を返す。この仕様に違反して SMTP サーバーが SMTP サービス拡張をサポートしていない場合、そのサーバーはエラー応答を返す。古いクライアント SMTP システムは、EHLO の代わりに HELO(RFC 821 で規定されている)を使用しても良く(MAY)、サーバーは HELO コマンドをサポートし、適切に応答しなければならない(MUST)。いずれにしてもクライアントは、メールトランザクションの開始前に HELO または EHLO を発行しなければならない(MUST)。
これらのコマンド(および、その１つへの "250 OK" リプライ)は、SMTP クライアントと SMTP サーバーとが共に初期状態にあり、従って処理中のトランザクションは無く、全ての状態テーブルと全てのバッファとがクリアされていることを確かにする。
文法：
ehlo = "EHLO" SP Domain CRLF helo = "HELO" SP Domain CRLF
一般に EHLO への応答は複数行になる。その応答の各行は、キーワードと、任意で１つ以上の引数とを含む。複数行応答の一般的な文法に従い、これらのキーワードは、最後の行以外はコード (250) とハイフンとに続き、最後の行はコードとスペースに続く。ABNF 記法と [8] の終端記号とを用いた肯定応答の文法は以下の通り：
ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF )
/ ( "250-" domain [ SP ehlo-greet ] CRLF
*( "250-" ehlo-line CRLF )
"250" SP ehlo-line CRLF )
ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127)
; CR、LF 以外の任意の文字の文字列
ehlo-line = ehlo-keyword *( SP ehlo-param )
ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
; ehlo-keyword に依存する ehlo-params の追加文法
ehlo-param = 1*(%d33-127)
; <SP> と全ての制御文字(US-ASCII 0-31 を含む)とを除く
; 任意の CHAR
EHLO キーワードは大文字でも小文字でも、またその混在でも良いが、常に大文字・小文字を区別しない方法で認識され、処理されなければならない(MUST)。これは、RFC 821 とセクション 2.4.1 とで規定されている習慣を単純に拡張したものである。
このコマンドは、メールデータを SMTP サーバーに配送するためのメールトランザクションを初期化するために使用される(SMTP サーバーはそのメールデータを順に１つまたは複数のメールボックスに配送するか、(おそらく SMTP を使用して)別のシステムに渡す)。引数フィールドは reverse-path を含み、任意で引数を含んでも良い。一般に MAIL コマンドは、メールトランザクションが処理中ではない時にのみ送信されて良い(セクション 4.1.4 参照)。
reverse-path は送信者のメールボックスから成る。歴史的には、メールボックスの前に任意でホストのリストが置かれても良かったが、現在ではその動作は推奨されない(付録 C 参照)。メールループを発生させる可能性があるレポートメッセージ(例えば、メールの配送通知や配送不能通知)の場合、reverse-path は空であっても良い(セクション 3.7)。
このコマンドは reverse-path バッファと forward-path バッファとメールデータバッファとをクリアし、このコマンドからの reverse-path 情報を reverse-path バッファに挿入する。
サービス拡張が交渉されている場合、MAIL コマンドは特定のサービス拡張に関連するパラメータを渡しても良い。
文法：
"MAIL FROM:" ("<>" / Reverse-Path)
[SP Mail-parameters] CRLF
このコマンドはメールデータの個々の受信者を特定するために使用される。複数の受信者は、このコマンドを複数使用することで特定する。引数フィールドは forward-path を含み、任意でパラメータを含んでも良い。
一般に forward-path は、必須の宛先メールボックスから成る。送信システムは、ソースルートとして知られるホストのリストを生成するべきではない(SHOUD NOT)。受信システムはソースルートの文法を理解しなければならない(MUST)が、そのソースルート指定を取り除き、ソースルートが指定されていなかったかのように、メールボックスに対応するドメイン名を使用するべきである(SHOULD)。
同様にリレーホストは、ソースルートを取り除くか無視するべき(SHOULD)であり、reverse-path にそれらの名前をコピーしてはならない(MUST NOT)。メールが最終宛先に届いた(forward-path に宛先メールボックスだけが含まれる)とき、SMTP サーバーは、そのホストのメールの慣例に従って、宛先メールボックスにそれを挿入する。
例えば、リレーホスト xyz.com 上で以下のエンベロープコマンドと共に受信されたメールは、
MAIL FROM:<userx@y.foo.org> RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
通常、以下のエンベロープコマンドと共にホスト d.bar.org へと直接送信される。
MAIL FROM:<userx@y.foo.org> RCPT TO:<userc@d.bar.org>
付録 C で提供されているように、xyz.com は以下のエンベロープコマンドを使用して、そのメッセージを hosta.int にリレーすることを選択をしても良い。
MAIL FROM:<userx@y.foo.org> RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>
あるいは以下のエンベロープコマンドを使用して jkl.org にリレーしても良い。
MAIL FROM:<userx@y.foo.org> RCPT TO:<@jkl.org:userc@d.bar.org>
当然ながら、ホストがメールをリレーすることは必須ではないため、この RCPT コマンドを受信したとき、xyz.com はコード 550 を使用してこのメッセージを拒否しても良い。
サービス拡張が交渉されている場合、RCPT コマンドは、サーバーによって提供されている特定のサービス拡張に対応する引数を渡しても良い。クライアントは、サーバーからの EHLO レスポンスによって提供されたサービス拡張に対応する引数以外の引数を送信してはならない(MUST NOT)。
文法：
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" / Forward-Path)
[SP Rcpt-parameters] CRLF
通常、受信者は DATA に対して 354 レスポンスを送信し、このコマンドに続く行(セクション 2.3.7 で説明されているように、シーケンス <CRLF> で終了する文字列)を送信者からのメールデータとして扱う。このコマンドにより、メールデータバッファへのメールデータの追加が発生する。メールデータには 128 の ASCII 文字コードの何れが含まれても良いが、経験的に SP・HT・CR・LF 以外の制御文字は問題を起こす可能性があるため、可能なら避けるべきである(SHOULD)。
メールデータは、ピリオドのみを含む行、つまり文字シーケンス "<CRLF>.<CRLF>" で終了する(セクション 4.5.2 参照)。これはメールデータの終了指示である。この終了シーケンスの最初の <CRLF> は、データ(メッセージテキスト)の最終行を終了させる、またはデータがない場合には DATA コマンド自身を終了させる <CRLF> でもあることに注意してほしい。メッセージに空行を追加してしまうため、余分な <CRLF> が追加されてはならない(MUST NOT)。この規則の唯一の例外は、<CRLF> で終了しない最終 "行" を持つメッセージ本文が SMTP 送信者に渡された場合に発生する。その場合送信側 SMTP システムは、そのメッセージを無効として拒否するか、受信側 SMTP サーバーが "データの終了(end of data)" 条件を認識できるように <CRLF> を追加するかしなければならない(MUST)。
一部の UNIX システム上での振舞いを許容するために <LF> のみで終了する行を受け入れるような習慣は、それが解決するよりも多くの相互運用性の問題を引き起こすことが立証済みであるため、たとえ堅牢性の向上という名においてであっても、SMTP サーバーシステムはそれを行ってはならない(MUST NOT)。具体的に言うと、シーケンス "<LF>.<LF>" (改行のみで復帰がない)は、メールデータの終了指示である <CRLF>.<CRLF> と同等のものとして扱われてはならない(MUST NOT)ということである。
このメールデータ終了指示の受信は、保存されているメールトランザクション情報を処理することをサーバーに要求する。この処理は reverse-path バッファ、forward-path バッファ、メールデータバッファを使用し、このコマンドの完了時、これらのバッファはクリアされる。この処理が成功した場合、受信者は成功リプライを送信しなければならない(MUST)。この処理が失敗した場合、受信者は失敗リプライを送信しなければならない(MUST)。現時点の SMTP モデルは部分的な失敗を許可しておらず、メッセージは、配送のためにサーバーによって受け入れられて肯定レスポンスが返されるか、受け入れられずに失敗リプライが返されるか、どちらかとなる。データ終了指示に対する肯定の完了リプライを送信したとき、その受信者はメッセージの完全な責任を負う(セクション 6.1 参照)。セクション 4.4 で議論されているように、その後に診断されたエラーはメールメッセージで報告されなければならない(MUST)。
最終配送またはリレーのために SMTP サーバーがメッセージを受け入れたとき、サーバーはメールデータの先頭にトレースレコード("タイムスタンプ行(time stamp line)" または "Received" 行としても同義的に言及される)を挿入する。このトレースレコードは、メッセージを送信したホストの識別、メッセージを受信した(そしてそのタイムスタンプを挿入する)ホストの識別、そしてメッセージを受信した日付と時刻とを表す。リレーされたメッセージは複数のタイムスタンプ行を持つだろう。これらの行の書式に関する詳細(その文法も含む)は、セクション 4.4 で規定されている。
DATA コマンドの操作に関する追加の議論がセクション 3.3 に示されている。
文法：
"DATA" CRLF
このコマンドは、現在のメールトランザクションの中止を指示する。保存されている送信者、受信者、メールデータは破棄されなければならず(MUST)、全てのバッファと状態テーブルはクリアされる。受信者は RSET コマンドに対し、引数無しの "250 OK" リプライを送信しなければならない(MUST)。クライアントはリセットコマンドをいつ発行しても良い。EHLO の直後や EHLO の発行前、データ終了指示が送信され確認された後、QUIT の直前では、これは NOOP と同じ効果を持つ(すなわち、何の効果もない)。SMTP サーバーは RSET 受信の結果として接続を閉じてはならない(MUST NOT)。その動作は QUIT のために予約されている(セクション 4.1.1.10 参照)。
EHLO はサーバーに追加の処理と応答とを課すため、たとえ公式な動作は同じであっても、一般に RSET は EHLO の再発行よりも効率的である。
この仕様の意図に反して、下層の TCP 接続が閉じられたかリセットされたという兆候を SMTP サーバーが受け取る可能性がある環境が存在する。メールシステムの堅牢性を維持するために、SMTP サーバーはこの状況への準備が出来ているべきであり(SHOULD)、接続が終了する前に QUIT を受信したかのように扱うべきである(SHOULD)。
文法：
"RSET" CRLF
このコマンドは、その引数がユーザーまたはメールボックスを特定するかどうかの確認を受信者に依頼する。ユーザー名の場合、その情報はセクション 3.5 で規定されている通りに返される。
このコマンドは reverse-path バッファ、forward-path バッファ、メールデータバッファに何の影響も与えない。
文法：
"VRFY" SP String CRLF
このコマンドは、その引数がメーリングリストを特定するかどうかを確認し、もしそうであればそのリストのメンバーを返すことを受信者に依頼する。このコマンドが成功した場合、セクション 3.5 で説明されている情報を含むリプライが返される。リストのメンバーが１人の場合を除き、このリプライは複数行を持つ。
このコマンドは reverse-path バッファ、forward-path バッファ、メールデータバッファに何の影響も与えず、いつ発行されても良い。
文法：
"EXPN" SP String CRLF
このコマンドにより、サーバーはクライアントに有益な情報を送信する。このコマンドは、引数(例えば任意のコマンド名)を取り、より詳細な情報を応答として返しても良い(MAY)。
このコマンドは reverse-path バッファ、forward-path バッファ、メールデータバッファに何の影響も与えず、いつ発行されても良い。
SMTP サーバーは引数なしの HELP をサポートするべき(SHOULD)であり、引数ありの HELP をサポートしても良い(MAY)。
文法：
"HELP" [ SP String ] CRLF
このコマンドは、どのパラメータにも以前に投入されたコマンドにも何の影響も与えず、受信者が成功リプライを返す以外の動作を指示しない。
このコマンドは reverse-path バッファ、forward-path バッファ、メールデータバッファに何の影響も与えず、いつ発行されても良い。引数の文字列が指定された場合、サーバーはそれを無視するべきである(SHOULD)。
文法：
"NOOP" [ SP String ] CRLF
このコマンドは、受信者が成功リプライを送り、次に通信チャネルを閉じなければならない(MUST)ことを指示する。
QUIT コマンドを受信して応答するまで、(たとえエラーがあったとしても)受信者は意図的に通信チャネルを閉じてはならない(MUST NOT)。QUIT コマンドを送信するまで、送信者は意図的に通信チャネルを閉じてはならず(MUST NOT)、(たとえ前のコマンドのエラー応答があったとしても)リプライの受信を待つべきである(SHOULD)。上記の違反、またはシステムやネットワークの障害により接続が途中で閉じられる場合、サーバーは保留中の全てのトランザクションをキャンセルしなければならない(MUST)が、それ以前に完了したトランザクションを取り消してはならず、処理中のコマンドまたはトランザクションは、一般に一時的なエラー(すなわち 4yz 応答)を受け取ったかのように動作しなければならない(MUST)。
QUIT コマンドはいつ発行されても良い。
文法：
"QUIT" CRLF
前述の各コマンドの引数フィールドの文法を以下に示す([8] で規定されている文法が当てはまる場合はそれを使用している)。以下の一部は、付録 C で説明されているソースルートと併用してのみ使用される。このドキュメントで規定されていない各種端子(ALPHA、DIGIT、SP、CR、LF、CRLF など)は、"core" 文法 [8 (セクション 6)] またはメッセージ書式文法 [32] において定義されている。
Reverse-path = Path
Forward-path = Path
Path = "<" [ A-d-l ":" ] Mailbox ">"
A-d-l = At-domain *( "," A-d-l )
; この形式(いわゆる "ソースルート(source route)")は、
; 必ず受け入れられなければならず(MUST)、生成されるべきではな
; く(SHOULD)、無視されるべきである(SHOULD)ことに注意してほしい。
At-domain = "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param = esmtp-keyword ["=" esmtp-value]
esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value = 1*(%d33-60 / %d62-127)
; "="・SP・制御文字を除く、任意の CHAR
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
address-literal = "[" IPv4-address-literal /
IPv6-address-literal /
General-address-literal "]"
; セクション 4.1.3 参照
Mailbox = Local-part "@" Domain
Local-part = Dot-string / Quoted-string
; 大文字・小文字を区別しても良い(MAY)
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
String = Atom / Quoted-string
上記の Local-part の定義は比較的寛容であるが、メール受信を期待するホストは最大限の相互運用性のために、Local-part が Quoted-string 形式を要求(または使用)したり、大文字・小文字が区別されたりするメールボックスを定義することを避けるべきである(SHOULD)。Local-part を生成、または比較することが必要とされる目的(例えばメールボックス名を指定する場合)のために、引用符付き形式は全て同等に扱われなければならず(MUST)、送信側システムは最低限の引用符を使用する形式で送信するべきである(SHOULD)。
システムは、SMTP において非 ASCII 文字(最上位ビットが１にセットされたオクテット)または ASCII "制御文字(control characters)" (10進数で 0-31 と 127)を必要とするようなメールボックスを定義してはならない(MUST NOT)。これらの文字は、MAIL コマンドや RCPT コマンド、あるいはメールボックス名を要求する他のコマンド内で使用されてはならない(MUST NOT)。
バックスラッシュ("\")は引用文字であり、その次の文字を(通常の解釈ではなく)その文字のまま使用することを表すために使用されることに注意してほしい。例えば "Joe\,Smith" は、フィールドの 4 文字目にコンマを持つ全 9 文字の単一のユーザーフィールドを表す。
命名と適用性とにおける DNS の保守的な利用に関する長年の方針(例えば、基本的 DNS 文書 RFC1035 [22] のセクション 2.3.1 参照)との相互運用性と一貫性とを推進するため、SMTP のクライアントまたはサーバーのためのドメイン名ラベルの中に、アルファベット・数字・ハイフン以外の文字が現れてはならない(MUST NOT)。特にアンダースコアは許可されない。無効な文字コードが使用されたコマンドを受信した SMTP サーバーは、それ以外に拒否する理由がない場合、そのコマンドを 501 レスポンスで拒否しなければならない(MUST)。
ホストがドメインネームシステムに知られておらず、通信(そして特に、エラーの報告と回復とのための通信)がブロックされている場合がある。この障壁を迂回するために、ドメイン名の代替として、アドレスの特別なリテラル形式が許可されている。IPv4 アドレスの場合、この書式は [123.255.37.2] のようなドットで区切られた 4 個の 10 進整数値を括弧で括ったものであり、オクテットシーケンス(sequence-of-octets)形式の (IPv4) インターネットアドレスを表す。IPv6 と、いずれ標準化されるかもしれない他のアドレス形式との場合、その書式は、IPv6 標準 [17] の一部として規定されている形式でのアドレス文法とコロンとアドレス自身とを特定する、標準化された "タグ(tag)" から構成される。
詳細：
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; スタンダードトラック RFC で規定され、
; IANA によって登録されなければならない(MUST)
Snum = 1*3DIGIT
; 0 から 255 までの10進整数を表す
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
IPv6-hex = 1*4HEXDIG
IPv6-full = IPv6-hex 7(":" IPv6-hex)
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
IPv6-hex)]
; "::" は少なくとも２個のゼロから成る16ビットの組を表す
; "::" の中には６個未満の組が存在する可能性がある
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
[IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
; "::" は少なくとも２個の、ゼロから成る 16 ビットの組を表す
; "::" と IPv4-address-literal とに加えて、４個未満の組が
; 存在する可能性がある
これらのコマンドを使用する場合の順序には制限がある。
メールトランザクションを含むであろうセッションは、最初に EHLO コマンドの使用により初期化されなければならない(MUST)。この初期化が無い場合でも、SMTP サーバーは非メールトランザクションのコマンド(例 VRFY または EXPN)を受け入れるべきである(SHOULD)。
EHLO コマンドは、クライアントによってセッション中に遅れて発行されても良い(MAY)。セッション開始後に発行された場合、SMTP サーバーは RSET コマンドが発行された場合と全く同様に、全てのバッファをクリアし、状態をリセットしなければならない(MUST)。言い換えると、EHLO の直後の RSET は冗長であり、不要なコマンドを実行するというパフォーマンスコスト以外の害は無い。
SMTP サーバーが EHLO コマンドを受け入れられない場合、必要に応じて 501・500・502 の失敗リプライを返さなければならない(MUST)。SMTP サーバーはそれらのリプライを送信した後も、EHLO を受信する前と同じ状態に留まらなければならない(MUST)。
可能であれば、EHLO コマンドへのドメイン引数が有効な主要ホスト名(CNAME または MX 名ではない)であることを、SMTP クライアントは保証しなければならない(MUST)。それが不可能な場合(例えばクライアントのアドレスが動的に割り当てられており、明確な名前を持たない場合)、ドメイン名と付加情報との代わりに、クライアントを特定する手助けとなるであろうアドレスリテラルを代用とするべきである(SHOULD)。
SMTP サーバーは、EHLO コマンドのドメイン名引数が、確かにクライアントの IP アドレスに対応していることを検証しても良い(MAY)。しかしながら検証に失敗した場合でも、それを理由にメッセージの受け付けを拒否してはならない(MUST NOT)。検証失敗に関する情報は、記録とトレースとの為だけのものである。
NOOP・HELP・EXPN・VRFY・RESET の各コマンドは、セッション中またはセッションの初期化前に、いつでも使用することが出来る。EHLO コマンドを受信する前であっても SMTP サーバーはこれらを通常通りに処理する(すなわち、コード 503 を返さない)べきである(SHOULD)。クライアントはこれらのコマンドを送信する前に、EHLO によりセッションを開くべきである(SHOULD)。
これらの規則に従う場合、EXPN に先立って EHLO コマンドが発行されている場合と、クライアントの IP アドレスまたは他の認証や認証決定メカニズムに基づいてアクセス拒否が行われている場合とを除き、EXPN コマンドに対する応答として "550 access denied to you" が返されるという RFC 821 の例は誤りである。
MAIL コマンド(または時代遅れの SEND・SOML・SAML の各コマンド)は、メールトランザクションを開始する。一旦開始されると、メールトランザクションは、トランザクション開始コマンド、１つ以上の RCPT コマンド、DATA コマンドから成る(この順序で)。メールトランザクションは RSET (または新しい EHLO)コマンドによって中止されても良い。１回のセッション中に、ゼロ個以上のトランザクションが存在して良い。MAIL (または SEND、SOML、SAML)コマンドは、メールトランザクションが開始された後に送信されてはならない(MUST NOT)。すなわち、セッション中でメールトランザクション中ではない場合か、前のトランザクションが DATA コマンドにより正常に終了している場合か、前のトランザクションが RSET によって中止された場合か、この何れかの場合にのみ MAIL コマンドは送信されるべきである。
トランザクション開始コマンドの引数が受け入れられない場合、501 リプライが返されなければならず(MUST)、SMTP サーバーは同じ状態に留まらなければならない(MUST)。トランザクション中の各コマンドがサーバーによって処理できないほど異常な順序の場合、503 リプライが返されなければならず(MUST)、SMTP サーバーは同じ状態に留まらなければならない(MUST)。
セッション中の最後のコマンドは、QUIT コマンドでなければならない(MUST)。QUIT コマンドはセッション中のそれ以外の時に使用することは出来ないが、セッション開始コマンドが送信も受け入もされていない場合でも、接続の終了を要求するためにクライアント SMTP によって使用されるべきである(SHOULD)。
セクション 2.2.2 で規定されている通り、"X" で始まるコマンドは、クライアント(送信側)とサーバー(受信側)の SMTP エージェント同士による合意により使用されて良い。そのようなコマンドを認識しない SMTP サーバーは、"500 Command not recognized" を返すことを期待される。拡張された SMTP サーバーは、EHLO コマンドの応答として、それらのプライベートコマンドに対応する機能名称をリストして良い(MAY)。
SMTP システムによって送信され受け入れられる "X" で始まるコマンドは、セクション 2.2.2 の要求事項に従わなければならない(MUST)。
SMTP コマンドへのリプライは、メール転送の過程でリクエストとアクションとの同期を確実にし、SMTP クライアントが SMTP サーバーの状態を常に知っていることを保証するのに役立つ。全てのコマンドは、正確に１つのリプライを生成しなければならない(MUST)。
コマンド - リプライのシーケンスの詳細は、セクション 4.3 で説明されている。
SMTP リプライは３桁の数値(３つの数字として送信される)であり、この文書以外で規定されていない限り、それに何らかのテキストが続く。その数値は次に入るべき状態を自動的に決定するために利用され、そのテキストは人間のユーザー向けである。３つの数字は、SMTP クライアントがテキストを調べる必要がないほど十分に符号化された情報を含み、それを破棄するか、必要に応じてユーザーに渡すかして良い。例外はこの文書内に別掲されている。具体的に言うと 220・221・251・421・551 の各リプライコードは、機械によって解析・解釈されるべきメッセージテキストに関連している。一般にこのテキストは受信者依存かつコンテキスト依存であるため、各リプライコードのために異なるテキストが存在するだろう。リプライコードの原理についての議論はセクション 4.2.1 に示されている。正式には、リプライは、３桁のコード・<SP>・１行のテキスト・<CRLF> というシーケンス、または複数行リプライ(セクション 4.2.1 で定義されている)と定義されている。この仕様に違反してテキストが送られない場合もあるため、テキストを受け取らなかったクライアントは、コード単独(後続の空白文字があっても無くても)でも処理する準備が出来ているべきである(SHOULD)。通常の環境では EHLO・EXPN・HELP のみが複数行リプライを返すことを期待されるが、複数行リプライは任意のコマンドに対して許可されている。
ABNF 表現によるサーバーレスポンスは以下の通りである：
Greeting = "220 " Domain [ SP text ] CRLF Reply-line = Reply-code [ SP text ] CRLF
この "Greeting" は、サーバーが接続を開いたことを知らせる 220 レスポンスの中にのみ現れる。
SMTP サーバーはこの文書内で示されているリプライコードのみを送信するべきである(SHOULD)。適切だと認められるときにはいつでも、SMTP サーバーはその例に示されているテキストを使用するべきである(SHOULD)。
SMTP クライアントは、テキストによってではなく、リプライコードのみによってその行動を決定しなければならない(MUST)("change of address" 251 と 551、また必要なら 220・221・421 の各リプライコードを除く)。一般的には、(送信者はコードのみを送信するべきではない(SHOULD)が)テキストを全く含まない場合も含め、任意のテキストが受け入れられるべきである(MUST)。リプライコードに続く空白(ブランク)はテキストの一部と見なされる。可能ならいつでも、受信側 SMTP はリプライコードの１桁目(深刻さを表す)を検証するべきである(SHOULD)。
以下に示すコードの一覧は、不変なものと解釈されてはならない(MUST NOT)。新しいコードの追加(そのレスポンスのテキスト部には補助的な情報を伴うことが好ましい)は稀有で重要な取り組みであるはずだが、新しいスタンダードまたはスタンダードトラックの仕様の結果として新しいコードが追加される可能性がある。したがって送信側 SMTP は、この文書で規定されていないコードを扱う準備が出来ていなければならず(MUST)、かつ１桁目の数字を解釈することによってのみそれを行わなければならない(MUST)。
リプライの３つの数値はそれぞれ特別な意味を持っている。１桁目の数字は、その応答が成功・失敗・未完了の何れであるかを示す。洗練されていない SMTP クライアント、または予期せぬコードを受信した SMTP クライアントは、この１桁目の数字を調べることによって次の行動(予定通りに進める、やり直す、切り詰めるなど)を決定することが出来るだろう。発生したエラーのおおよその種類(例えばメールシステムエラー、コマンドの文法エラー)を知りたい場合、SMTP クライアントは２桁目の数字を調べても良い。３桁目の数字と提示される可能性のある補助的な情報は、情報の詳細なレベル用に予約されている。
リプライコードの１桁目のために、５つの値が存在する：
２桁目の数字は、特定のカテゴリ内のレスポンスを符号化する：
３桁目の数字は、２桁目の数字によって特定される各カテゴリにおける意味の、より詳細な等級を表す。リプライのリストがそれを明らかにする。各リプライのテキストは必須ではないが、推奨はされ、対応するコマンドに従って変更されることさえも許される。その一方で、リプライコードはこのセクションの仕様に厳密に従わなければならない。受信側実装は、ここで説明されているものと少しだけ異なる状況のために新しいコードを作り出すのではなく、定義済みのコードに適合させるべきである。
例えば NOOP のような(成功しても SMTP クライアントに新しい情報を何も提供しない)コマンドは、250 リプライを返すだろう。実装されていない非サイト固有アクションをコマンドが要求した場合、リプライは 502 となる。この改良版は、コマンドは実装されているが、実装されていない引数を要求するコマンドの場合の 504 である。
リプライテキストは１行より長くても良い。そのような場合の完全なテキストは、SMTP クライアントがリプライを読み取るのを止めるときを知ることが出来るように、印付けされなければならない。これには複数行のリプライを表すための特別な書式を必要とする。
複数行リプライのための書式は、リプライコードで始まり、その直後にハイフン "-" (マイナスとしても知られる)、その後にテキストが続く形式を、最終行を除く全ての行で必要とする。最終行はリプライコードで始まり、その直後に <SP>、任意のテキスト、そして <CRLF> という書式である。前述の通り、後続のテキストが送られない場合でもサーバーは <SP> を送るべきである(SHOULD)が、クライアントはそれが省略された場合の用意が出来ていなければならない(MUST)。
例：
123-First line 123-Second line 123-234 text beginning with numbers 123 The last line
多くの場合、SMTP クライアントは単純に、直後に <SP> または <CRLF> が続くリプライコードで始まる行を探し、後続の全ての行を無視する必要があるだけである。まれに、リプライ "テキスト(text)" 中に、クライアントにとって重要なデータが存在する。クライアントは現在のコンテキストからこれらのケースを特定することが出来るだろう。
500 Syntax error, command unrecognized
文法エラー、認識できないコマンド
(これには、コマンドが長すぎるといったエラーが含まれても良い)
501 Syntax error in parameters or arguments
パラメータまたは引数の文法エラー
502 Command not implemented
コマンドは実装されていない (セクション 4.2.4 参照)
503 Bad sequence of commands
不正なコマンドシーケンス
504 Command parameter not implemented
コマンドのパラメータが実装されていない
211 System status, or system help reply
システム状態またはシステムヘルプのリプライ
214 Help message
ヘルプメッセージ
(受信者を利用する方法、または特定の非標準コマンドの意味に関する情報
このリプライは人間のユーザーにとってのみ有用である)
220 <domain> Service ready
<domain> サービス準備完了
221 <domain> Service closing transmission channel
<domain> サービスは通信チャネルを閉じようとしている
421 <domain> Service not available, closing transmission channel
<domain> サービスは利用不能であり、通信チャネルを閉じようとしている
(シャットダウンしなければならないことをサービスが分かっている場合に
任意のコマンドへのリプライとして使用されてよい)
250 Requested mail action okay, completed
要求されたメールアクションは正常であり、完了した
251 User not local; will forward to <forward-path>
ユーザーはローカルに存在しないため、<forward-path> に転送される
(セクション 3.4 参照)
252 Cannot VRFY user, but will accept message and attempt delivery
ユーザーを確認できないが、メッセージを受け付け、配送を試みる
(セクション 3.5.3 参照)
450 Requested mail action not taken: mailbox unavailable
要求されたメールアクションは行われない：メールボックス利用不可
(例 メールボックスが使用中)
550 Requested action not taken: mailbox unavailable
要求されたアクションは行われない：メールボックス利用不可
(例 メールボックスが見つからない、アクセスできない、
ポリシーを理由にコマンドが拒否された)
451 Requested action aborted: error in processing
要求されたアクションは中止された：処理中のエラー
551 User not local; please try <forward-path>
ユーザーはローカルではないため、<forward-path> を試してほしい
(セクション 3.4 参照)
452 Requested action not taken: insufficient system storage
要求されたアクションは行われない：システム容量不足
552 Requested mail action aborted: exceeded storage allocation
要求されたメールアクションは中止された：割り当て容量を超えた
553 Requested action not taken: mailbox name not allowed
要求されたアクションは行われない：メールボックス名は許可されない
(例 メールボックスの文法が不正)
354 Start mail input; end with <CRLF>.<CRLF>
メールの入力を開始、<CRLF>.<CRLF> で終了
554 Transaction failed (または接続開始時の応答の場合は
"No SMTP service here")
トランザクション失敗(または接続開始時の応答の場合は
"SMTP サービスが無い")
211 System status, or system help reply
システム状態またはシステムヘルプのリプライ
214 Help message
ヘルプメッセージ
(受信者を利用する方法、または特定の非標準コマンドの意味に関する情報
このリプライは人間のユーザーにとってのみ有用である)
220 <domain> Service ready
<domain> サービス準備完了
221 <domain> Service closing transmission channel
<domain> サービスは通信チャネルを閉じようとしている
250 Requested mail action okay, completed
要求されたメールアクションは正常であり、完了した
251 User not local; will forward to <forward-path>
ユーザーはローカルに存在しないため、<forward-path> に転送される
(セクション 3.4 参照)
252 Cannot VRFY user, but will accept message and attempt
delivery
ユーザーを確認できないが、メッセージを受け付け、配送を試みる
(セクション 3.5.3 参照)
354 Start mail input; end with <CRLF>.<CRLF>
メールの入力を開始、<CRLF>.<CRLF> で終了
421 <domain> Service not available, closing transmission channel
<domain> サービスは利用不能であり、通信チャネルを閉じようとしている
(シャットダウンしなければならないことをサービスが分かっている場合に
任意のコマンドへのリプライとして使用されてよい)
450 Requested mail action not taken: mailbox unavailable
要求されたメールアクションは行われない：メールボックス利用不可
(例 メールボックスが使用中)
451 Requested action aborted: local error in processing
要求されたアクションは中止された：処理中のエラー
452 Requested action not taken: insufficient system storage
要求されたアクションは行われない：システム容量不足
500 Syntax error, command unrecognized
文法エラー、認識できないコマンド
(これには、コマンドが長すぎるといったエラーが含まれても良い)
501 Syntax error in parameters or arguments
パラメータまたは引数の文法エラー
502 Command not implemented (see section 4.2.4)
コマンドは実装されていない (セクション 4.2.4 参照)
503 Bad sequence of commands
不正なコマンドシーケンス
504 Command parameter not implemented
コマンドのパラメータが実装されていない
550 Requested action not taken: mailbox unavailable
要求されたアクションは行われない：メールボックス利用不可
(例 メールボックスが見つからない、アクセスできない、
ポリシーを理由にコマンドが拒否された)
551 User not local; please try <forward-path>
ユーザーはローカルではないため、<forward-path> を試してほしい
(セクション 3.4 参照)
552 Requested mail action aborted: exceeded storage allocation
要求されたメールアクションは中止された：割り当て容量を超えた
553 Requested action not taken: mailbox name not allowed
要求されたアクションは行われない：メールボックス名は許可されない
(例 メールボックスの文法が不正)
554 Transaction failed (または接続開始時の応答の場合は
"No SMTP service here")
トランザクション失敗(または接続開始時の応答の場合は
"SMTP サービスが無い")
リプライコード 502 (Command not implemented(コマンドは実装されていない))が他のコードよりも優先して返されるべき(SHOULD)場合に関しての議論がある。502 は、そのコマンドが SMTP サーバーによって実際に認識はされたが、実装はされていない場合に使用されるべきである(SHOULD)。コマンドが認識もされなかった場合、コード 500 が返されるべきである(SHOULD)。拡張された SMTP システムは、502 (または 500)リプライを返す可能性のある機能を EHLO への応答の中にリストしてはならない(MUST NOT)。
<CRLF>.<CRLF> によって DATA コマンドが完了した後、SMTP サーバーが肯定完了ステータス(コード 2yz)を返したとき、そのサーバーは以下の責任を負う：
<CRLF>.<CRLF> によって DATA コマンドが完了した後、SMTP サーバーが永続的エラー状態コード(5yz)を返したとき、そのサーバーはそのメッセージを配送する試みを続けてはならない(MUST NOT)。SMTP クライアントは引き続きそのメッセージの配送責任を持ち、それをユーザーに返すか、後の試行のために再度キューイングする(セクション 4.5.4.1 参照)か、どちらかを許される。
メッセージを発信したユーザーは、永続的失敗を解釈するのと全く同じように、(メールメッセージまたはその他の手段による)配送不能通知としての一時的失敗ステータスの返信を理解できるべきである(SHOULD)。すなわち、クライアント SMTP がこれらの状態を正常に処理すれば、そのユーザーはそのようなリプライを受信することはないだろうということである。
<CRLF>.<CRLF> によって DATA コマンドが完了した後、SMTP サーバーが永続的エラーステータスを返すとき、そのサーバーはそのメッセージを配送する試みを続けてはならない(MUST NOT)。一時的エラーステータスと同様に、SMTP クライアントは引き続きメッセージの責任を持つが、ユーザーによる再調査とメッセージの介入とを伴わずに同じサーバーへ再度配送を試みるべきではない(SHOULD)。
送信者と受信者との間の会話は、送信者の制御による交互の会話である。送信者がコマンドを発行し、受信者がリプライで応答する。サービス拡張を通して他の取り決めが交渉されていない限り、受信者は更にコマンドを送信する前に、その応答を待たなければならない(MUST)。
重要なリプライの１つとして、接続の挨拶がある。一般に受信者は、接続が完了したときに 220 "Service ready" リプライを送信するだろう。送信者は何らかのコマンドを送信する前に、この挨拶メッセージを待つべきである(SHOULD)。
注意： この種の挨拶リプライは全て、リプライコードに続く最初の単語としてそのサーバーホストの公式名(完全限定の主要ドメイン名)を持つ。ホストが意味のある名前を持たない場合もある。そのような状況における代替案に付いての議論は、セクション 4.1.3 を参照してほしい。
例：
220 ISIF.USC.EDU Service ready
または
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
または
220 [10.0.0.1] Clueless host service ready
以下の表は、各コマンドに対して選ばれるべき成功・失敗の一覧である。これは厳密に次の規則に従う：受信者はリプライ中のテキストを置き換えることは出来るが、コード番号と特定のコマンドリプライシーケンスとにより暗示される意味とアクションを変更することは出来ない。
各コマンドは、通常あり得るリプライと共にリストされている。あり得るリプライの前に使われているプレフィクスはそれぞれ、"I" は中間(intermediate)、"S" は成功(success)、"E" はエラー(error)を表す。一部のサーバーは特別な環境下でこれ以外のエラーを生成しても良いことと、さらなる拡張を可能にするためとに、SMTP クライアントは可能であればリプライの１桁目だけを解釈するべき(SHOULD)であり、また１桁目だけを解釈することで認識できないリプライコードを処理する準備が出来ていなければならない(MUST)。セクション 2.2 で説明されているメカニズムを使用して拡張されていない限り、SMTP サーバーは、３桁の数字ではないリプライコードや、数字の２〜５以外で始まるリプライコードを SMTP クライアントに送信してはならない(MUST NOT)。
これらの順序付け規則も(原理上は)そのコード自身も、サーバーが提案し、クライアントが受け入れた(要求した) SMTP 拡張によって拡張、または修正されて良い。
以下の一覧に示されているコードに加えて、任意の SMTP コマンドに対して以下のコードの何れかを、それに対応する異常な状況に出くわした場合に返すことが出来る。
具体的なシーケンスは以下の通り：
接続確立 (CONNECTION ESTABLISHMENT)
S: 220
E: 554
EHLO または HELO
S: 250
E: 504, 550
MAIL
S: 250
E: 552, 451, 452, 550, 553, 503
RCPT
S: 250, 251 (ただし、251 と 551 の議論についてセクション 3.4 を
参照すること)
E: 550, 551, 552, 553, 450, 451, 452, 503, 550
DATA
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
RSET
S: 250
VRFY
S: 250, 251, 252
E: 550, 551, 553, 502, 504
EXPN
S: 250, 252
E: 550, 500, 502, 504
HELP
S: 211, 214
E: 502, 504
NOOP
S: 250
QUIT
S: 221
セクション 4.1.1.4 で議論されている通り、配送やさらなる処理のためにメッセージを受信した SMTP サーバーは、そのメッセージ内容の先頭にトレース情報("time stamp" または "Received")を挿入しなければならない(MUST)。
その行は以下のように構造化されなければならない(MUST)：
インターネットのメールプログラムは、メッセージヘッダに既に追加されている Received: 行を変更してはならない(MUST NOT)。SMTP サーバーはメッセージの先頭に Received 行を追加しなければならない(MUST)。既存の行の順序を変更したり、その他の位置に Received 行を挿入したりしてはならない(MUST NOT)。
インターネットの成長に伴い、Received フィールドの比較可能性は、問題(特にリレー遅延)を発見するために重要になっている。Received フィールドを生成する SMTP サーバーは、何らかのタイムゾーン名ではなく、日付の明示的なオフセット(例 -0800)を使用するべきである(SHOULD)。可能ならば、(オフセットを伴う)ローカル時刻は UT が望ましい。この公式化により、指定されたローカル環境に関する若干詳しい情報が利用可能になる。UT が必要な場合、受信者はその値を変換するために単純な計算を行うだけで良い。UT を使用することにより、そのサーバーのタイムゾーン位置に関する情報は失われる。タイムゾーン名が必要な場合、それはコメント内に含まれるべきである(SHOULD)。
配送 SMTP サーバーがメッセージの "最終配送(final delivery)" を行うとき、そのサーバーはメールデータの先頭に return-path 行を挿入する。この return-path の使用は必須であり、メールシステムはこれをサポートしなければならない(MUST)。return-path 行は MAIL コマンドの <reverse-path> 内の情報を保持する。ここでの最終配送とは、メッセージが SMTP 環境に残されていることを意味する。一般的にこれは、そのメッセージが宛先ユーザーまたは対応するメールドロップに配送されたことを意味するが、場合によっては別のメールシステムによってさらに処理され、送信される可能性もある。
例えば、エラーレスポンスをメッセージの送信者ではなく特別なエラー処理用メールボックスに配送させるような場合、return-path 内のメールボックスは実際の送信者のメールボックスと異なることも可能である。メーリングリストが必要とされる場合、エラーをメッセージ送信元ではなくリスト管理者に配送する方法として、この取り決めは一般的なものであり、有用である。
上記の文章は、最終的なメールデータは return path で始まり、その後に１つ以上のタイムスタンプ行が続くということを暗示している。これらの行の後に、メールデータのヘッダとボディと[32]が続くだろう。
配送のためにメッセージを受信した後で転送や他の操作が行われる可能性があるため、SMTP サーバーが最終配送を行うかどうかを判断することは、時に困難である。したがって追加的なシステム(転送、ゲートウェイ、リレーなど)は、配送されるメッセージに正確に１行だけ return path 行が含まれることを確実にするための必要に応じて、return path を削除し、MAIL コマンドを再構築しても良い(MAY)。
メッセージ送信元の SMTP システムは、Return-path ヘッダが既に含まれているメッセージを送信するべきではない(SHOULD NOT)。リレー機能を実行する SMTP サーバーはメッセージデータを調べてはならない(MUST NOT)が、Return-path ヘッダがあるかどうかを判断するために必要とされる範囲では、なおさらである。最終配送を行う SMTP サーバーは、自身の Return-path を追加する前にそれらを削除しても良い(MAY)。
Return-path の主要な目的は、配送不能やその他のメールシステム障害を表すメッセージが送信されるアドレスを指定することである。これが不明確にならないように、メッセージが配送されるときには正確に１つの return-path が含まれるべきである(SHOULD)。非 SMTP トランスポートと共に RFC 822 文法を使用するシステムは、エラーレポート(例えば配送不能メッセージ)が送信されるべき、そのトランスポートのエンベロープに対応する不明確ではないアドレスを指定するべきである(SHOULD)。
歴史的注意： エラーメッセージの宛先として Return-path ヘッダ(または MAIL コマンドからのエンベロープ reverse path アドレス)を使用することと矛盾するように見える RFC 822 の文章は、インターネット上においては適用され得ない。(Return-path へコピーされる)reverse path アドレスは、配送エラーメッセージを含んでいる全てのメール宛先として使用されなければならなない(MUST)。
詳細：
メールデータ終了指示に続く処理が部分的にしか成功しなかった場合、サーバーは特別な扱いをしなければならない。これは、SMTP サーバーが複数の受信者とメールデータとを受け取った後、受信者の一部(全てではない)への配送に成功したことが分かった場合に起こり得る。このような場合、DATA コマンドへの応答は成功リプライでなければならない(MUST)。しかしながらその SMTP サーバーは、メッセージの送信者への "undeliverable mail" 通知メッセージを作成し、送信しなければならない(MUST)。
失敗した全ての受信者をリストした単一の通知、または個別の通知メッセージが、失敗した受信者毎に送信されなければならない(MUST)。送信者による処理の効率化のためには、可能であれば前者が望ましい。全ての配送不能メール通知メッセージは、(たとえそれらが廃止された SEND、SOML、SAML などのコマンド処理の結果であったとしても)MAIL コマンドを使用して、かつセクション 3.7 で議論されているように空の return-path を使用して送信される。
タイムスタンプ行と return path 行は、公式には以下のように定義される。
Return-path-line = "Return-Path:" FWS Reverse-path <CRLF>
Time-stamp-line = "Received:" FWS Stamp <CRLF>
Stamp = From-domain By-domain Opt-info ";" FWS date-time
; ここで "date-time" は [32] で定義されている通りだが、
; "obs-" 形式(特に２桁の年)は SMTP では禁止されており、
; 使用されてはならない(MUST NOT)。
From-domain = "FROM" FWS Extended-Domain CFWS
By-domain = "BY" FWS Extended-Domain CFWS
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
TCP-info = Address-literal / ( Domain FWS Address-literal )
; サーバーによる TCP 接続由来の情報であり、
; クライアントの EHLO 由来の情報ではない。
Opt-info = [Via] [With] [ID] [For]
Via = "VIA" FWS Link CFWS
With = "WITH" FWS Protocol CFWS
ID = "ID" FWS String / msg-id CFWS
For = "FOR" FWS 1*( Path / Mailbox ) CFWS
Link = "TCP" / Addtl-Link
Addtl-Link = Atom
;リンク用の追加の標準名は Internet Assigned Numbers Authority
; (IANA)によって登録される。
; "Via" は主に非インターネットトランスポートと共に
; 使用される値である。SMTP サーバーは登録されていない名称を
; 使用するべきではない(SHOULD NOT)。
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; プロトコル用の追加の標準名は Internet Assigned Numbers
; Authority (IANA)によって登録される。
; SMTP サーバーは登録されていない名称を使用するべきではない
; (SHOULD NOT)
SMTP を動作させるためには、以下の最小限の実装が全ての受信者に必要となる。この仕様に適合するためには、以下のコマンドがサポートされなければならない(MUST)。
EHLO HELO MAIL RCPT DATA RSET NOOP QUIT VRFY
メールのリレーまたは配送をサポートしている SMTP サーバーを含む全てのシステムは、大文字・小文字を区別しないローカル名として、予約済みのメールボックス "postmaster" をサポートしなければならない(MUST)。サーバーが接続開始時に常に 554 を返す場合(セクション 3.1 で説明されている)、この postmaster アドレスは厳密には必須ではない。postmaster へのメールを受け付けるというこの要求事項は、SMTP サーバーがメールサービスを提供している任意のドメインの potmaster メールボックスを指定する RCPT コマンドはもちろん、"RCPT TO:<Postmaster>" という特殊なケースも暗示している。
インターネット上の任意のドメインからの Postmaster 宛てメールを受け付けるために、SMTP システムはあらゆる合理的な努力を行うことを期待される。例えばサービス不能攻撃やその他のセキュリティ侵害のような極端なケースでは、SMTP サーバーは Postmaster 宛てメールをブロックしても良い。しかしながらこのような取り決めは、その種の攻撃の一部ではないメッセージのブロックを避けるために、注意して調整されるべきである(SHOULD)。
何らかのデータ透過性の提供なしには、文字シーケンス "<CRLF>.<CRLF>" がメールテキストを終了させ、ユーザーによって送信されることは出来ない。一般にこのような "禁止された(forbidden)" シーケンスにユーザーは気付かない。ユーザーの作成した全ての文章が透過的に送信されることを可能にするために、以下の手続きが使用される：
メールデータは 128 の ASCII 文字から任意の文字を含んでよい。空白や垂直タブ、水平タブ、その他の制御文字を含め、全ての文字が受信者のメールボックスに配送される。通信チャネルが 8 ビットバイト(オクテット)のデータストリームを提供している場合、7 ビット ASCII コードは、上位ビットが 0 にクリアされ、オクテット内に右詰めされて送信される。リレー機能を提供する SMTP システムにおけるこのような状況の特別な扱いについては、3.7 を参照してほしい。
一部のシステムでは、データが受信・保存されるために、そのデータを変換する必要があるかもしれない。これは、ローカルの文字セットとして ASCII とは異なる文字セットを使用するホストに必要かもしれない。そのようなホストでは文字列ではなくレコードにデータを保存したり、メールボックス内部の区切り文字として特別な文字シーケンスを使用したりする。このような変換が必要な場合(特にリレーされるメールにそれが適用されるような場合)、その変換は可逆的でなければならない(MUST)。
いくつかのオブジェクトはサイズの最大値/最小値を必要とする。全ての実装は、少なくともこの範囲のサイズのオブジェクトを受信可能でなければならない(MUST)。可能であれば、このサイズより大きいオブジェクトは避けられるべきである(SHOULD)。しかしながら、例えば符号化された X.400 アドレス [16] などを構築する一部のインターネットメールは、しばしばより大きなオブジェクトを必要とする。クライアントはそれを送信しようとしても良い(MAY)が、サーバーがそれを処理できない場合には拒否されるという準備が出来ていなければならない(MUST)。可能な最大限の範囲において、これらのオブジェクトの長さに制限を課さない実装技術が使用されるべきである。
これらの限界を超えたことによるエラーは、リプライコードを使用して報告されても良い。いくつかのリプライコードの例は以下の通りである：
500 Line too long.
または
501 Path too long
または
452 Too many recipients (see below)
または
552 Too much mail data.
RFC 821 [30] は、SMTP サーバーが RCPT コマンドの数に関する実装上の限界を超えた場合のエラーにリプライコード 552 が含まれると、誤ってリストしている。この状況での正しいリプライコードは 452 である。クライアントはこの状態を永続的な障害としてではなく、以下のロジックが正しく動作する一時的な障害として扱うべきである(SHOULD)。
適合する SMTP サーバーがこの状況に出くわした場合、そのサーバーは自身の受信者バッファに少なくとも 100 個の成功した RCPT コマンドを持っている。そのサーバーがそのメッセージを受け入れられる場合、少なくともこれら 100 個のアドレスが SMTP クライアントのキューから削除されるだろう。452 レスポンスを受け取ったアドレスの再送信をクライアントが試みる場合、少なくともそれらのアドレスの内 100 個は SMTP サーバーの受信者バッファに収まることができる。何でも配送できる各再送信の試みごとに、少なくともそれらの受信者の内 100 個は処理することができる。
あるSMTP サーバーが RCPT コマンドの数に実装上の制限を持っており、その限界まで使い尽くされた場合、そのサーバーはレスポンスコード 452 を使用しなければならない(MUST)(ただし前述の通り、クライアントは 552 の準備も出来ているべきである(SHOULD))。そのサーバーが RCPT コマンドの数に設定済みサイトポリシーによる制限を課している場合、そのサーバーは代わりにレスポンスコード 5XX を使用しても良い(MAY)。たとえある特定のメッセージ本文が複数メールトランザクションで送信されるとしても、そのメッセージ本文の受信者数の合計にポリシーによる制限が適用されるのであれば、これは最も適切だろう。
SMTP クライアントはタイムアウトのメカニズムを提供しなければならない(MUST)。これには、何らかの方法でメールトランザクション全体の時間を計るのではなく、コマンド毎のタイムアウトを使用しなければならない(MUST)。タイムアウトは簡単に再設定可能であるべき(SHOULD)で、SMTP コードの再コンパイルは不要であることが望ましい。これを実装するために、各 SMTP コマンドとデータ通信の各バッファとのためのタイマーが設定される。この後者は、全体的なタイムアウトが本質的にメッセージサイズに比例するということを意味している。
多忙なメールリレーホストを伴う大規模な経験に基づき、コマンド単位のタイムアウトの最小値は以下の通りであるべきである(SHOULD)：
SMTP サーバーは送信者からの次のコマンドを待っている時間として、少なくとも 5 分のタイムアウトを持つべきである(SHOULD)。
ホスト SMTP 実装の一般的構造は、ユーザーメールボックス、通信中のメッセージをキューイングするための１つ以上の領域、メールを送受信するための１つ以上のデーモンプロセスを含む。その正確な構造は、そのホスト上のユーザーの要求とそのホストによってサポートされるメーリングリストの数とサイズとに依存して様々である。私たちは、特に高いトラフィック量をサポートするメイラーにとって有益であることが立証されているいくつかの最適化について説明している。
どのキューイング戦略も、コマンド毎の全ての動作にタイムアウトを含まなければならない(MUST)。いかなる環境においても、キューイング戦略はエラーメッセージへの応答としてエラーメッセージを送信してはならない(MUST NOT)。
SMTP クライアントの一般的なモデルは、定期的にメール送信を試みる１つ以上のプロセスである。一般的なシステムにおいて即座に送信できないメールはキューイングされ、送信者によって定期的にリトライされなければならない(MUST)一方で、メッセージを作成するプログラムは新しい送信メールを即座に送ることを要求するための何らかの手段を持っている。メールキューのエントリーは、メッセージそのものだけではなく、エンベロープ情報も含むだろう。
ある特定の宛先への送信が失敗した後、クライアントは再送を遅延させなければならない(MUST)。一般にこの再送の間隔は少なくとも 30 分であるべき(SHOULD)だが、配送不能の原因を SMTP クライアントが特定できる場合には、より繊細で柔軟な戦略が有益だろう。
メッセージが送信されるか送信者があきらめるまで再送は続けられる。一般にあきらめるまでの時間は少なくとも 4、5 日を必要とする。この再送アルゴリズムへのパラメータは設定可能でなければならない(MUST)。
クライアントはキューイングされているメールを単純に再送しようとするのではなく、到達不可能なホストと対応する接続タイムアウトとのリストを保持すべきである(SHOULD)。
一般的に障害は一時的なもの(相手のシステムまたはその接続が故障中)であることが経験的に示されているため、メッセージがキューに入ってから最初の 1 時間に 2 回の接続を試み、その後は 2、3 時間に 1 回へと後退するポリシーが好まれている。
SMTP クライアントは SMTP サーバーと協力して、このキューイング遅延を短縮することができる。例えば、ある特定のアドレスからメールが受信された場合、そのホスト宛てにキューイングされているメールはすぐに送信することが出来ると考えられる。多くの場合この原理の適用は、明示的に "すぐにキューを送信する(send queues now)" 機能(例えば ETRN など)[9]の必要性を削減する。
ホスト毎の複数アドレスの結果(下記参照)として、配送時間とリソース利用との関係を最適化するために、この戦略はさらに修正されても良い。
SMTP クライアントは配送不能の宛先ホスト毎に大きなメッセージキューを持つことが許される。各再送サイクルのたびにその全てのメッセージが再送されてしまうとインターネットに過度のオーバーヘッドを掛けることになり、送信システムは長時間にわたってブロックされるだろう。一般に SMTP クライアントは数分のタイムアウトの後にのみ配送の試みが失敗したと判断することができ、たとえ各接続ごとに１分のタイムアウトであっても、同じホスト宛てにキューイングされているメッセージの再送が何十回も繰り返されると(何百回ならなおさら)、結果として非常に大きな遅延を生むであろうことに注意してほしい。
しかしながら、サーバーからの否定応答をキャッシュする際には、SMTP クライアントは十分に注意を払うべきである(SHOULD)。極端な場合、一回の SMTP 接続中に複数の EHLO を発行すると、サーバーからそれぞれ異なる答えが返される可能性もある。より注意すべきことは、MAIL コマンドへの 5yz レスポンスは決してキャッシュされてはならない(MUST)ということである。
あるメールメッセージが複数の受信者に配送されようとしており、さらにそのメッセージのコピーが送信される複数の受信者の SMTP サーバーが同じ場合、そのメッセージのただ１つのコピーだけが送信されるべきである(SHOULD)。したがって SMTP クライアントは、MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA というシーケンスではなく、MAIL, RCPT, RCPT, ...,RCPT, DATA というシーケンスを使用するべきである(SHOULD)。ただし非常に多くのアドレスがある場合、MAIL コマンドごとの RCPT コマンドの数に対する制限が課されるかもしれない(MAY)。この効率的な機能の実装は強く推奨される。
同様に、タイムリーな配送を行うために、SMTP クライアントは複数同時の送信メールトランザクションをサポートしても良い(MAY)。しかしながらホストがその全てのリソースをメールに注いでしまうのを防ぐために、何らかの制限が課されるのが適切だろう。
SMTP サーバーは、常時 SMTP ポート上でのリッスン状態が継続されるように試みるべきである(SHOULD)。これは複数の SMTP 用 TCP 接続のサポートを必要とする。何らかの制限が課されても良い(MAY)が、同時に２つ以上の SMTP 接続を処理できないサーバーは、この仕様の目的には適合しない。
先に議論したように、ある特定ホストのアドレスからのメールを SMTP サーバーが受信したとき、そのホスト上のアドレス宛てに保留されている全てのメールを再送信するために、独自の SMTP キューイングメカニズムを作動させても良い。
既存、または提案中の標準によって、空の reverse path と供に送信されることを要求される通知メッセージが数種類存在する。すなわち、セクション 3.7 で議論されている配送不能通知、その他の種類の配送ステータス通知(DSNs：Delivery Status Notifications)、そしてメッセージ廃棄通知 [10] である。この種のメッセージは全て以前のメールに関する通知であり、その以前のメールメッセージの reverse-path へと送信される。(通常このような通知メッセージの配送が失敗した場合、その通知メッセージの宛先となっているホストのメールシステムに問題があることを示している。そのため一部のホストは、そのような失敗した通知メッセージを、そのメールシステムの問題を修復できる人物へと(例えばエイリアス postmaster を経由して)転送するように設定される。)
その他の種類のメッセージは全て(言い換えると、スタンダードトラック RFC によって空の reverse-path を持つことを要求されない全てのメッセージは)、有効な空ではない reverse-path と供に送信されるべきである(SHOULD)。
自動メール送信プロセッサの実装者は、空の reverse-path を持つ様々な種類のメッセージが正しく扱われることを確実にするように注意するべきである。特にそのようなシステムは、空の reverse-path を持つメッセージに返信するべきではない(SHOULD NOT)。
SMTP クライアントは、メールが配送されるドメインを辞書的な意味で認識した時点で、そのドメイン名を解決するために(セクション 3.6 と 3.7 での説明のように) DNS 検索を実行しなければならない[22](MUST)。その名前は完全限定ドメイン名(FQDN)であることを期待される：部分的な名前やローカルのエイリアスから FQDN を推測するメカニズムはこの仕様の範囲外であり、問題を起こしてきた歴史のため、一般的には推奨されない。この検索はまず最初に、その名前に対応する MX レコードを見つけようとする。もし代わりに CNAME レコードが見つかった場合、その結果の名前が最初の名前であるかのようにして処理される。MX レコードは見つからなかったが A RR は見つかった場合、その A RR は、優先順位 0 でそのホストを指す暗黙の MX RR に対応する A RR であるかのように扱われる。１つ以上の MX RR が見つかった場合、SMTP システムはその名前に対応する A RR を、それらが MX RR を使用して位置づけられているのではない限り、利用してはならない(MUST NOT)。上記の "暗黙の MX(implicit MX)" の規則は MX レコードが無かった場合にのみ適用される。MX レコードはあったものの、その何れもが利用不可能だった場合、その状況はエラーとして報告されなければならない(MUST)。
この検索が成功したとき、複数の MX レコードまたはマルチホーミングのため、またはその両方のために、結果としてそのマッピングは単一のアドレスではなく、択一的な配送アドレスのリストになる可能性がある。信頼できるメール転送を提供するために、SMTP クライアントは配送が成功するまでそのリストの中の該当アドレスを順に試す(そしてリトライする)ことが出来なければならない(MUST)。しかしながらリトライ可能なアドレスの数には設定可能な上限を設けても良い(MAY)。いずれにしても、SMTP クライアントは少なくとも２つのアドレスは試すべきである(SHOULD)。
ホストのアドレスを順位付ける為に 2 種類の情報、複数 MX レコード、マルチホームホストが使用される。
複数の MX レコードは、ソートして使用されなければならない(MUST)優先順位値を含む(下記参照)。低い数値は高い数値よりも優先順位が高い。同じ優先順位を持つ複数の宛先が存在し、その１つを選ぶ明確な理由(例えば、簡単に到達可能なアドレスであるという認識)がない場合、指定の組織向けの複数のメールエクスチェンジャ全体に負荷を分散するために、送信側 SMTP はそれらを無作為に選ばなければならない(MUST)。
(おそらく優先順位の高い MX レコードから選ばれた)宛先ホストは、マルチホームかもしれない。そのような場合、ドメイン名リゾルバは択一的な IP アドレスのリストを返すだろう。必要に応じてそのリストを優先順位の降順に並べ替えることはドメイン名リゾルバインターフェイスの責任であり、SMTP はその順序通りに試さなければならない(MUST)。
複数の択一的アドレスを試みる能力は必須であるが、個別の設定により択一的アドレスの使用を制限、または無効にすることを望んでも良い。マルチホーム化された１ホストの異なるアドレスを使用して送信者がリトライを試行するべきかどうかという問題は、議論を呼んでいる。複数アドレスを使用することを支持する主な理由は、それがタイムリーな配送の可能性(実際には、時に全ての配送の可能性)を最大化するということであり、反対する理由は、無駄なリソースの使用を招く可能性があるということである。リソースの使用に関しては、セクション 4.5.4.1 で議論されている送信戦略によっても決定されることに注意してほしい。
指定されたメールエクスチェンジャから得られた宛先を伴うメッセージを SMTP サーバーが受信した場合、サーバーはそのメッセージをリレーするか、メッセージの最終配送を行うか、SMTP が提供されるトランスポート環境の外に何らかのメカニズムを使用して渡すかして良い(MAY)。当然ながら最後の選択肢以外は、MX レコードのリストが十分に検査されることを必要とする。
アドレスを書き換えることなくメッセージをリレーするべきだとサーバーが判断した場合、そのサーバーは配送のための候補を決定するために MX レコードをソートしなければならない(MUST)。レコードはまず最初に優先順位で並べられる(最低値のレコードが最も優先順位が高い)。次にリレーホストは、メールトランザクション中に分かったであろう全ての名前とアドレスとのために、そのリストを調査しなければならない(MUST)。一致するレコードが見つかった場合、同じ優先順位の全てのレコードと、それより高い数値を持つ全てレコードは考慮の内から外されなければならない(MUST)。この時点でどのレコードも残らなかった場合、それはエラー状態であり、そのメッセージは配送不能として返されなければならない(MUST)。レコードが残っている場合、前述のように優先順位が高いものから順に試行されるべきである(SHOULD)。
受信側 SMTP が(DATA への応答として "250 OK" を送ることで)メールを受け付けたとき、そのサーバーはそのメッセージの配送またはリレーの責任を受け入れたことになる。サーバーはこの責任を重く受け止めなければならない。そのサーバーは軽率な理由、例えばそのホストが後に故障したとか、予測可能なはずのリソース不足といった理由でそのメッセージを失ってはならない(MUST NOT)。
メールを受け付れた後に配送障害が発生した場合、受信側 SMTP は通知メッセージを作成し、それをメールで送信しなければならない(MUST)。この通知メッセージはエンベロープ内に空の("<>" の) reverse path を使用して送信されなければならない(MUST)。この通知の受信者は、エンベロープの return-path (または Return-Path: 行)から得られるアドレスでなければならない(MUST)が、もしそのアドレスが空("<>")の場合、受信側 SMTP は通知を送信してはならない(MUST NOT)。明らかに、もし望まれているのなら、空のアドレスに関する情報をローカルに記録したり送信したりするというローカルの(つまりその受信側 SMTP のシステム環境の一部としての)判断を禁止できないし、禁止するべきでもない。もしそのアドレスが明示的なソースルートだった場合、それはその最終ホップまで取り除かれなければならない(MUST)。
例えば以下の内容を伴って届いたメッセージのために送信されるエラー通知の場合：
MAIL FROM:<@a,@b:user@d>
その通知メッセージは以下の内容を使用して送信されなければならない(MUST)：
RCPT TO:<user@d>
SMTP によりメッセージが受け入れられた後に発生する一部の障害は避けられないものだろう。例えば、"緩い(soft)" ドメインシステムエラーのために受信側 SMTP サーバーが RCPT コマンド内の全ての配送先アドレスを確認できない場合や、宛先がメーリングリストの場合(RCPT に関する前述の議論参照)、あるいはサーバーがリレーとして動作しており、かつ配送システムへ即座にはアクセスしない場合などである。
タイムアウトの結果としてのメッセージを重複して受信することを避けるために、受信側 SMTP はデータ終了を表す最後の <CRLF>.<CRLF> への応答に必要となる時間を最小限しようとしなければならない(MUST)。この問題の議論については RFC 1047 [28] を参照してほしい。
メールシステムにおけるループを検出するためにメッセージ内の "Received:" ヘッダの数を数えるという単純な方法は、最適であることはまれだとは言え、効果的な手段であることが立証されている。この手法を使用する SMTP サーバーは、大きな閾値(少なくとも 100 個の Received エントリー)を使用するべきである(SHOULD)。どのようなメカニズムが使用されるとしても、サーバーは平凡なループを検出・停止するための対策を含んでいなければならない(MUST)。
残念ながら、インターネットメールプロトコルの変種や独創的な解釈、明らかな違反などが発生しており、一部の人々はそれが非常に頻繁に発生していると示唆している。正しく動作する SMTP 受信者やリレーは不正なメッセージを拒否するべきなのか、変更を加えずに渡すことを試みるべきなのか、配送に成功する確率を上げるために修復を試みるべきなのか、この議論は構造化されたネットワークメールの黎明期からあり、勢いが衰える気配はない。拒否の支持者は、修復の試みはめったに成功しないうえ、不正なメッセージを拒否することは攻撃的なソフトウェアを矯正させる唯一の方法であると主張する。 "修復(repair)" または "何であっても配送する(deliver no matter what)" の支持者は、とにかく可能ならばメールが送られることをユーザーは望んでいるうえ、その方向への大きな市場圧力があると反論する。現実問題として、特定のベンダーにとってこのような市場圧力は、現場の開発者の好みとは関係なく、標準に厳密に適合することよりも重要かもしれない。
不適切な形式のメッセージに関連する問題は、split-UA メール読込みプロトコル(split-UA mail reading protocols) [3, 26, 5, 21] の採用によって悪化した。これらのプロトコルは、投入プロトコルとしての SMTP の使用と、それらの(しばしばインターネットへの断続的な接続しか持たない)クライアントホストのためのリレーシステムとしての SMTP サーバーの使用とを促進してきた。歴史的にこのようなクライアントマシンの多くは SMTP (実際にはメールフォーマットプロトコル[7])では前提とされているメカニズムの一部や情報の一部を欠いている。一部は適切な時間の経過を維持できなかったり、タイムゾーンの概念を持たなかったり、さらには自分の名前やアドレスを認識できなかったりする。そして当然ながらこれらのクライアントは、RFC 822 の認証済みアドレスの概念の基礎である条件を満たすことが出来ない。
このような貧弱な SMTP クライアントに応えて、現在では多くの SMTP システムが、未完成または不正な形式で配送されたメッセージを完全なものにする。サーバーがクライアントを識別または認証でき、かつ双方に事前の合意がある場合には、この戦略は一般に適切なものと見なされる。その一方で、ユーザーやクライアントマシンに関する知識を少ししか持たないか、全く持たないリレーまたは配送 SMTP サーバーによって適用される修正に関しては、大きな懸念が存在する。
送信元 SMTP サーバー、または最初の投入プロトコルとしての SMTP の宛先として使用される SMTP サーバーによって、処理中のメッセージに必要に応じて以下の変更が適用されて良い(MAY)。
クライアントに関してサーバーが持っている情報が少なければ少ないほどこれらの変更の正しいさは怪しくなるため、修正を行うかどうかやその方法を考えるとき、さらなる注意と保守主義とが適用されるべきである。中間リレーの機能を提供する SMTP サーバーは、これらの変更を適用してはならない(MUST NOT)。
いかなる場合でも SMTP サーバーによる訂正には、正しい情報を提供し適切に運用されているクライアントが好ましい。また何れの場合も、サーバーによって実行された動作についての(トレースフィールド内やヘッダコメント内での)説明が強く推奨される。
ごく普通のユーザーでさえ、受信や中継を行う SMTP サーバーに直接接続し、経験の浅い受信者に別のところから来たと信じ込ませるようないたずらメッセージを作成することが可能であることから、SMTP メールは本質的に安全ではない。その "なりすまし(spoofed)" 行為が専門家でも見抜けないようなメッセージを作成するのはいくらか困難だが、抑止的かつ博識な人物への抑止力になるほどではない。その結果として、インターネットメールの知識が増えるにつれ、SMTP メールはトランスポートレベルで本質的に認証できないということ、あるいは整合性チェックを提供しないということの知識も同様に増える。真のメールセキュリティは、例えばデジタル署名([14] と、例えば PGP [4] または S/MIME [31] とを参照)のような、メッセージ本文に含まれるエンドツーエンドの手法にのみ存在する。
トランスポートレベル(例えば SMTP クライアントから SMTP サーバーへ)での認証を提供する様々なプロトコル拡張と設定オプションが、上で説明されている従来の状況をいくらか改善する。しかしながら、注意深く設計された信頼できる環境における注意深い責任のやり取りによって両者が参加していない限り、トランスポートシステムの整合性に依存するのではなくデジタル的に署名されたメッセージを使用するエンドツーエンドのメカニズムよりも、それらは本質的に弱いままである。
エンベロープの return path とヘッダの "From" フィールドとを、ユーザー自身以外の有効なアドレスを指すように設定するのをより困難にしようとする努力は、全くの見当違いである。これは、別の人の代理として誰かがメールを送信したり、エラー(または通常の)リプライが特別なアドレスに向けられるべきだったりする正当なアプリケーションを台無しにする。(これらのフィールドをメッセージ単位でユーザーが変更するための便利な方法を提供するシステムは、メッセージデータ内の Sender フィールドが合理的に生成され得るように、そのユーザーの主要かつ永続的なメールボックスアドレスを設置することを試みるべきである。)
メールを偽造しようとする無知なユーザからの保護というわずかなマージンを期待して有益な機能を無効にしないべきだということを主張する以外、この仕様はこれ以上 SMTP にまつわる認証問題を扱わない。
多くの理由により、メッセージヘッダには現れないアドレスが、SMTP サーバーへの RCPT コマンド中に現れる可能性がある。最も一般的な２つの理由は、"list exploder" (複数のアドレスへと解決される単一アドレス)としてメーリングアドレスを使用する場合と、"ブラインドコピー(blind copies)" が現れる場合とである。特に２つ以上の RCPT コマンドが現れる場合と、これらのメカニズムの一部を無効にするのを避けるためとに、SMTP のクライアントとサーバーは、RCPT コマンドの引数の全てをヘッダ内に(トレースヘッダの一部としてや、情報またはプライベート拡張されたヘッダとして)コピーするべきではない(SHOULD NOT)。実際問題としてこの規則はしばしば破られるうえ、強制することも出来ないため、"bcc" の効用に気付いた送信 SMTP システムは、単一の RCPT コマンドを含む個別のメールトランザクションとして各ブラインドコピーを送信することが有益であるということを発見しても良い(MAY)。
ヘッダ内のアドレスと、SMTP トランザクション("エンベロープ(envelope)")における(MAIL や SAML などからの) "reverse" または(RCPT からの) "forward" との間に特有の関連性はない。受信システムはそのような関連性を推測したり、配送のためにメッセージのヘッダを変更する目的でそれらを利用したりしようとするべきではない(SHOULD NOT)。有名な "Apparently-to" ヘッダはこの原則に違反するだけではなく、意図しない情報開示の代表的な原因であり、使用されるべきではない(SHOULD NOT)。
セクション 3.5 での議論の通り、個々のサイトはセキュリティを理由に VRFY または EXPN のどちらか、または両方を無効化したいと考えても良い。その当然の結果として、これを許可する実装は、実際には検証されていない検証済みアドレスを持っているように見えてはならない(MUST NOT)。あるサイトがセキュリティを理由にこれらのコマンドを無効化する場合、その SMTP サーバーは、成功か失敗かの検証に混乱するかもしれないようなコードではなく、252 レスポンスを返さなければならない(MUST)。
VRFY コマンドにリストされたアドレスに対して文法チェックのみを行った後にリプライコード 250 を返すことは、この規則に違反する。また当然ながら、アドレスが有効かどうかに関わらず常に 550 を返すことによって VRFY を "サポートする(supports)" するような実装も、同様に適合しない。
ここ数年でメーリングリストの内容は、いわゆる "スパマー(spammers)" にとってのアドレス情報源として有名になった。リスト管理者がリスト自体の不適切な利用に対する保護策を導入するにしたがって、アドレスを "収穫(harvest)" するための EXPN の利用は増加してきた。それでもなお実装は EXPN のサポートを提供するべき(SHOULD)だが、サイトはそのトレードオフを注意深く評価するべきである(SHOULD)。SMTP に認証メカニズムが導入されるにつれて、一部のサイトは認証済みユーザーに対してのみ EXPN を利用可能にすることを選択するかもしれない。
挨拶レスポンスや HELP コマンドへの応答としてサーバーの種類やバージョン(そして時にはサーバーのドメイン名も)をアナウンスすることのデバッグ観点での長所と、潜在的に敵意に満ちた攻撃に利用される可能性のある情報を開示するという短所との間のトレードオフに関して、継続中の議論が存在する。デバッグ情報の有用性について疑う余地はない。これを利用可能にすることを主張する人々は、サーバーの正確な身元を隠すことにより既知の脆弱性を隠すことで防御力が高まるだろうと望むより、実際に SMTP サーバーを安全にする方がはるかに優れていると指摘している。サイトはこの問題を念頭に置いてこのトレードオフを評価することが推奨される。実装は、何らかの方法で他のネットワークホストに、その種類とバージョンの情報を最低限に提供することが推奨される。
一部の環境、例えば公のインターネットに直接接続していないホストを持つ LAN 内などからメールが発信される場合、この仕様に適合して生成されるトレースフィールド("Received")は、ホスト名や、通常は入手不可能なはずの同じような情報を公開することになる可能性がある。通常これが問題になることは無いが、名前の公開について特別な不安を持つサイトはこの問題を認識するべきである。また同様に、オプションである FOR 節は慎重に提供されるか、複数の受信者が含まれている場合に気付かない内に "ブラインドコピー(blind copy)" の受信者の身元を他人に公開しないように、全く提供されないべきである。
セクション 3.4 での議論の通り、あるメールボックスに対応する代替アドレスを特定するためにリプライコード 251 または 551 を使用することは、意図せず機密情報を開示する可能性がある。これらの問題に不安を持つサイトは、サーバーを適切に選択・設定していることを確実にするべきである。
SMTP サーバーを提供しているサイトにとって合理的な任意の運用上または技術上の理由により、サーバーがメールを受け入れるのを拒否するかもしれないということは、安定した原則である。しかしながら、サイトと設備との間の協調がインターネットを可能にしている。トラフィックを拒否する権利をサイトが過剰に利用した場合、メールの可用性(インターネットの強みの１つ)が脅かされることになるだろう。受け付けたり処理したりするトラフィックに関して選択的であることをサイトが決めた場合、相当な注意が払われ、バランスが維持されるべきである。
ここ数年、メールの実際の発信者を隠す悪意を持つ試みの一部として、独断的なサイトを通したリレー機能が利用されるようになってきた。一部のサイトはリレー機能の利用を既知、または身元確認可能な接続元のみに制限する決断をしており、実装はこの種のフィルタリングを実行する能力を提供するべきである(SHOULD)。これらの理由、または他のポリシーを理由にメールが拒否された場合、EHLO・MAIL・RCPT への応答として、必要に応じてコード 550 が使用されるべきである(SHOULD)。
この仕様をサポートするにあたり、IANA は３つのレジストリを保守する。１つ目は、対応するキーワード(および必要に応じてパラメータと命令(verbs))を伴う SMTP サービス拡張から成る。セクション 2.2.2 で規定されている通り、"X" で始まるエントリーがこのレジストリ内に作成されることはない。エントリーは、この目的の為に IESG によって明確に承認されたスタンダードトラック RFC、または実験的 RFC の何れかで定義されているサービス拡張(および対応するキーワード、パラメータ、命令(verbs))のためにのみ作成される。
２つ目のレジストリは、IPv4 アドレスのため(RFC 821 と この文書とで規定されている)と IPv6 アドレス(この文書で規定されている)のためと以外のドメインリテラルの書式を特定する "タグ(tags)" から成る。追加のリテラルタイプは使用される前に標準化を必要とする(現時点で予定されているものは無い)。
３つ目(RFC 821 で制定され、この仕様によって更新された)は、セクション 4.4 で説明されているタイムスタンプ("Received: header") の従属節である "via" および "with" と共に使用される、リンク識別子とプロトコル識別子のレジストリである。この文書で規定されているリンク識別子とプロトコル識別子への追加は、標準化によって、または RFC により文書化され IESG 承認された実験的プロトコル拡張によってのみ登録されて良い。
[1] American National Standards Institute (formerly United States of
America Standards Institute), X3.4, 1968, "USA Code for
Information Interchange".
ANSI X3.4-1968 は僅かな変更を伴う新しいバージョンにより置き換えられたが、インターネットではいまだ 1968 バージョンが最も確実である。
[2] Braden, R., "Requirements for Internet hosts - application and
support", STD 3, RFC 1123, October 1989.
[3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J.
Reynolds, "Post Office Protocol - version 2", RFC 937, February
1985.
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC
1176, August 1990.
[6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
2060, December 1996.
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", RFC 822, August 1982.
[8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[9] De Winter, J., "SMTP Service Extension for Remote Message Queue
Starting", RFC 1985, August 1996.
[10] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[11] Freed, N, "Behavior of and Requirements for Internet Firewalls",
RFC 2979, October 2000.
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, December 1996.
[13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC
2920, September 2000.
[14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
December 1998.
[16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156,
January 1998.
[17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for
Message Size Declaration", STD 10, RFC 1870, November 1995.
[19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
"SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July
1994.
[21] Lambert, M., "PCMAIL: A distributed mail system for personal
computers", RFC 1056, July 1988.
[22] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
December 1996.
[24] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD
53, RFC 1939, May 1996.
[27] Partridge, C., "Mail routing and the domain system", RFC 974,
January 1986.
[28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February
1988.
[29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, September 1981.
[30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August
1982.
[31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
[33] Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 1830, August 1995.
[34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996.
John C. Klensin
AT&T Laboratories
99 Bedford St
Boston, MA 02111 USA
Phone: 617-574-3076
EMail: klensin@research.att.com
この文書の多くのイテレーションにおいて、多くの人々が長時間、懸命に活動した。インターネットメール配送のための多くの技術的問題と改定された標準の役割とについて、IETF DRUMS Working Group において幅広い議論が(メーリングリスト上と顔をあわせての議論の両方で)行われた。また多くの寄稿者が、この仕様の文言を整形する手助けをしてくれた。RFC 821 の作成以来の多くの議論に参加した何百人もの人々は多すぎて書き切れないが、その全員が、この文書が現在のようになるための手助けをしてくれた。
TCP 接続は 8 ビットバイトの通信をサポートする。SMTP のデータは 7 ビットの ASCII 文字である。各文字は、上位ビットがゼロにクリアされた 8 ビットバイトとして伝達される。サービス拡張は完全な 8 ビットデータバイトによるメッセージ本文の通信を許可するようにこの規則を修正しても良いが、SMTP のコマンドまたはレスポンスに対しては許されない。
一部のシステムは、メール投入プロトコルに RFC 822 ヘッダ(のみ)を使用するか、さもなければメッセージが UA から MTA へと渡されるときに RFC 822 ヘッダ由来の SMTP コマンドを生成する場合がある。MTA-UA のプロトコルはプライベートな問題であり、どのインターネット標準によっても網羅されていないが、このアプローチには問題がある。例えば、概念的にはメールエンベロープに所属する情報が初期の処理ではヘッダ情報から分離されていない(その後分離される)場合の、"bcc" コピーと再配布リストとの適切な扱いに伴う度重なる問題が存在する。
UA は最初の("投入クライアント(submission client)") MTA に、メッセージ自体とは分離したエンベロープを提供することが推奨される。しかしながらエンベロープが提供されない場合、以下のように SMTP コマンドが生成されるべきである(SHOULD)：
MTA がこのように使われる場合、その MTA は、送信されたメッセージが有効であることの確認を行う責任を負う。その有効性を確認するメカニズムや、到着時点で有効ではないメッセージを扱う(または送り返す)ためのメカニズムは MUA-MTA インターフェイスの一部であり、この仕様では網羅されない。
外部の(非 SMTP の)メールシステムから SMTP 環境へとメッセージをゲートウェイするためには、標準 RFC 822 の情報のみを基にした投入プロトコルが使用されてはならない(MUST NOT)。エンベロープを構築するための追加情報は、(補助的なヘッダでろうと、その外部システムのエンベロープであろうと)その他環境内の何らかの情報源からもたらされるべきである。
ヘッダの "to" フィールドと "cc" フィールドとのみを使用してメッセージをゲートウェイしようとする試みは、メールのループや、インターネットメール環境の適切な機能に反するその他の振る舞いを再三引き起こしてきた。メッセージがインターネット上のメーリングリストから発信され、エンベロープ情報を使用して外部環境へと配布された場合、これらの問題は特によく起こるものであった。これらのメッセージがその後ヘッダのみのリメイラーによって処理されると、インターネット環境(そしてそのメーリングリスト)へのループバックはほとんど避けられない。
歴史的に <reverse-path> はホストと送信元メールボックスとから成る逆方向ソースルーティングリストであった。<reverse-path> 内の最初のホストは、MAIL コマンドを送信したホストであるべきである(SHOULD)。同様に <forward-path> は、ホストと宛先メールボックスから成るソースルーティングリストであって良い。しかしながら一般に <forward-path> は、ルーティング情報が必要な場合にはそれをドメインネームシステムに依頼しながら、メールボックスとドメインとのみを含むべきである。ソースルートは非推奨である。セクション 3.3 と F.2 とで議論されている通り、サーバーはそれを受信・処理する準備が出来ていなければならない(MUST)。とは言え、クライアントはそれを送信しないべき(SHOULD NOT)であり、このセクションはそのコンテキストを提供するためだけに含まれていた。
リレー目的の場合、forward-path は "@ONE,@TWO:JOE@THREE" のような形式のソースルートであっても良い(ONE・TWO・THREE はそれぞれ完全限定ドメイン名でなければならない(MUST))。この書式はアドレスとルートとの区別を強調するために使用されている。メールボックスは絶対アドレスであり、ルートはそこへと到達する方法に関する情報である。この２つの概念は混同されるべきではない。
ソースルートが使用される場合、forward-path と reverse-path とを構築・更新するためのメカニズムについて、RFC 821 と以下の文章が参考にされるべきである。
SMTP サーバーは、forward-path から reverse-path の先頭まで、もしあれば自身の識別子(自身のドメイン名、またはメールエクスチェンジャとして振舞っているドメイン)を取り除くことでコマンドの引数を変換する。
forward-path と reverse-path は SMTP のコマンドとリプライの中に現れるが、メッセージには現れる必要がないことに注意してほしい。すなわちこれらのパスや特にその文法は、メッセージヘッダの "To:"、"From:"、"CC:" などのフィールド内に現れる必要はないということである。逆に SMTP サーバーは、メッセージのヘッダフィールドから最終的な配送の情報を導き出してはならない(MUST NOT)。
ホストのリストが現れた場合、それは "逆方向(reverse)" ソースルートであり、リスト上の各ホストを通してそのメールがリレーされたことを示している(リストの先頭のホストが最も最近のリレーである)。このリストは配送不能通知を送信者へと返すためのソースルートとして使用される。各リレーホストはリストの先頭に自身を追加するため、それにはメールがリレーされてきたトランスポート環境における名前ではなく、リレーしようとしているトランスポート環境において知られている名前を(それらが異なる場合には)使用しなければならない(MUST)。
このセクションでは数種類の SMTP セッションの完全なシナリオを示す。以下の例の中で、 "C:" はここまで SMTP クライアントと呼ばれていたものを表し、"S:" はここまで SMTP サーバーと呼ばれていたものを表す。
この SMTP の例は、ホスト bar.com 上の Smith からホスト foo.com 上の Jones・Green・Brown の３人へと送信されたメールを表している。ここで私たちは、ホスト bar.com がホスト foo.com に直接接続可能であると仮定している。このメールは Jones と Brown とに対しては受け付けられたが、Green はホスト foo.com 上にメールボックスを持っていなかった。
S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM:<Smith@bar.com> S: 250 OK C: RCPT TO:<Jones@foo.com> S: 250 OK C: RCPT TO:<Green@foo.com> S: 550 No such user here C: RCPT TO:<Brown@foo.com> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Blah blah blah... C: ...etc. etc. etc. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM:<Smith@bar.com> S: 250 OK C: RCPT TO:<Jones@foo.com> S: 250 OK C: RCPT TO:<Green@foo.com> S: 550 No such user here C: RSET S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
ステップ 1 -- 送信元ホストからリレーホストへ
S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250 HELP C: MAIL FROM:<JQP@bar.com> S: 250 OK C: RCPT TO:<@foo.com:Jones@XYZ.COM> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Date: Thu, 21 May 1998 05:33:29 -0700 C: From: John Q. Public <JQP@bar.com> C: Subject: The Next Meeting of the Board C: To: Jones@xyz.com C: C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
ステップ 2 -- リレーホストから宛先ホストへ
S: 220 xyz.com Simple Mail Transfer Service Ready C: EHLO foo.com S: 250 xyz.com is on the air C: MAIL FROM:<@foo.com:JQP@bar.com> S: 250 OK C: RCPT TO:<Jones@XYZ.COM> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Received: from bar.com by foo.com ; Thu, 21 May 1998 C: 05:33:29 -0700 C: Date: Thu, 21 May 1998 05:33:22 -0700 C: From: John Q. Public <JQP@bar.com> C: Subject: The Next Meeting of the Board C: To: Jones@xyz.com C: C: Bill: C: The next meeting of the board of directors will be C: on Tuesday. C: John. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
S: 220 foo.com Simple Mail Transfer Service Ready C: EHLO bar.com S: 250-foo.com greets bar.com S: 250-8BITMIME S: 250-SIZE S: 250-DSN S: 250-VRFY S: 250 HELP C: VRFY Crispin S: 250 Mark Crispin <Admin.MRC@foo.com> C: SEND FROM:<EAK@bar.com> S: 250 OK C: RCPT TO:<Admin.MRC@foo.com> S: 250 OK C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: Blah blah blah... C: ...etc. etc. etc. C: . S: 250 OK C: QUIT S: 221 foo.com Service closing transmission channel
一般にインターネットと他のメールシステムとの間のゲートウェイは、２つのメールシステムが含まれる境界をまたいで全ての層化された動作(layering semantics)を維持しようと試みるべきである(SHOULD)。マッピング(例えばあるシステムのエンベロープ情報から別システムのメッセージヘッダやメッセージボディへのマッピング)によって近道をしようとするゲートウェイ変換アプローチは、重要な点で不適切であることが一般的に証明されている。エンベロープもヘッダもインターネットメールもサポートしないような複数環境の間で変換を行うシステムは、何らかの情報損失がほぼ避けられないということを理解した上で作られなければならない。
RFC 821 のいくつかの機能は問題を起こしやすいことが立証されており、インターネットメールにおいて使用されるべきではない(SHOULD NOT)。
クライアントとサーバーの役割を入れ替えることを要求してくるホストに対する強力な認証機能が欠けていると、このコマンド(RFC 821 で説明されている)は正しい宛先からメールをそらす目的に簡単に利用できてしまうため、重大なセキュリティ問題を引き起こす。このコマンドの使用は非推奨であり、サーバーがクライアントを認証可能な場合を除き、SMTP システムはこれを使用するべきではない(SHOULD NOT)。
あるホストから別のホストへと一連のリレーを経由してメールを送るために、RFC 821 は明示的なソースルーティングの概念を利用していた。正規のメールトラフィックにおいてソースルートを利用することの必要性は、ドメインネームシステムの "MX" レコードの導入によって削減され、また最後の重要な正当化の理由も、"@" に続くアドレスは全て完全限定ドメイン名でなければならないという RFC 1123 における明確な要求事項の導入により削減された。その結果、ソースルートを使用することを正当化する理由として残るのは、非常に古い SMTP クライアントや MUA をサポートすることと、メールシステムのデバッグにおいてとだけである。しかしながら後者の状況や、例えば DNS のレコードに関連する障害などの深刻な(しかし一時的な)問題を迂回してメールをルーティングするためには、なお実用的である。
SMTP サーバーは、この文書の本文と RFC 1123 とで規定されているソースルートの文法を受け入れ続けなければならない(MUST)。必要に応じてアドレス内のルート情報を無視し、宛先ドメインだけを利用しても良い(MAY)。ソースルートを使用するのであれば、そのメッセージはアドレス内に最初に現れるドメインに送られなければならない(MUST)。特に、サーバーはソースルート内の近道を推測してはならない(MUST)。
例えばデバッグの場合や、ファイアーウォールまたはメールシステムの設定間違いを迂回してリレーする場合などの異常な状況を除き、クライアントは明示的なソースルーティングを利用するべきではない(SHOULD NOT)。
セクション 3.1 と 4.1.1 とでの議論の通り、サーバーが EHLO を受け入れられるのであれば、HELO よりも EHLO が強く推奨される。古いクライアントをサポートするために、サーバーは引き続き HELO を受け入れ、処理する必要がある。
RFC 821 は、シャープ記号 "#" を前置した 10 進整数のホスト番号としてインターネットアドレスを指定する方法を提供していたが、実際のところ TCP/IP の導入によってこの書式は時代遅れとなった。これは非推奨であり、使用されてはならない(MUST NOT)。
SMTP のクライアントやサーバーがメッセージ内(例えばトレースフィールド)に日付を挿入する場合、4 桁の年が使用されなければならない(MUST)。2 桁の年は非推奨であり、3 桁の年はインターネットメールシステムにおいて許可されたことはない。
メッセージをユーザーのメールボックスに配送するメカニズムの規定に加え、RFC 821 は、メッセージをユーザーのターミナル画面に直接配送する追加の(任意の)コマンドを提供していた。これらのコマンド(SEND、SAML、SOML)はまれにしか実装されず、また実装されているところでさえ、ワークステーション技術の変化と他のプロトコルの導入とがこれらを時代遅れにしている可能性がある。
クライアントは SEND・SAML・SOML をサービスとして提供するべきではない(SHOULD NOT)。サーバーはこれらを実装しても良い(MAY)。サーバーがこれらを実装する場合、RFC 821 で規定されている実装モデルが使用されなければならず(MUST)、そのコマンド名を EHLO コマンドへの応答の中で公開しなければならない(MUST)。
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC エディタの働きへの資金拠出は、現在 Internet Society によって提供されている。