RFC 5321 – シンプルメール転送プロトコル
このRFCが存在する理由
SMTPはメールを動かす最も古く、最も基本的なプロトコルです。その系統は1982年にジョン・ポステルによって発表されたRFC 821にまでさかのぼります。2008年に発表されたRFC 5321は現在の正式な仕様です。数十年にわたる拡張、明確化、運用経験を単一の権威あるドキュメントに統合しました。
RFC 821からRFC 5321への主な進化は以下の通りです。ESMTP（拡張SMTP）の形式化、リレーと送信動作の明確化、DNS MXルックアップをめぐるより厳しい要件、アドレスリテラルとIPv6の更新されたルール、バウンス処理の要件。このRFCは他のすべてのメールRFCが構築される基礎です。
仕組み
SMTPトランザクションは、TCP接続（従来ポート25）を介する2つのサーバー間の構造化された会話です。プロトコルはテキストベースで行指向です。すべてのコマンドと応答は人間が読める可能な ASCII です。
SMTPモデル
SMTPは3つのロールを定義します。
- SMTPクライアント（Sender-SMTP）: メッセージを転送するために接続を開始するシステム。
- SMTPサーバー（Receiver-SMTP）: 接続を受け入れてメッセージを受信するシステム。
- SMTPリレー: メッセージを受信して最終的な宛先に転送するサーバー。クライアントとサーバーの両方として機能します。
クライアントが接続してEHLOで自身を識別し、エンベロープ送信者（MAIL FROM）、1つ以上の受信者（RCPT TO）を指定し、メッセージデータ（DATA）を送信します。サーバーは各コマンドに3桁のステータスコードで応答します。
SMTPコマンド
| コマンド | 目的 |
|---|---|
EHLO |
クライアントを識別して拡張機能をリクエスト。古いHELOに置き換わりました。 |
MAIL FROM:<addr> |
エンベロープ送信者を指定（バウンスのための返信パス）。 |
RCPT TO:<addr> |
受信者を指定。受信者ごとに1回発行されます。 |
DATA |
メッセージコンテンツ送信を開始。.だけの行で終了します。 |
RSET |
現在のトランザクションを中止して状態をリセット。 |
VRFY |
ユーザーが存在するかを確認（悪用のため、ほとんどサポートされていません）。 |
EXPN |
メーリングリストを展開（ほとんどサポートされていません）。 |
NOOP |
操作なし。接続をキープアライブします。 |
QUIT |
接続を閉じます。 |
返信コード
すべてのサーバー応答は3桁のコードで始まります。最初の桁がクライアントに何が起きたかを伝えます。
- 2xx — 成功。リクエストされたアクションが完了しました。
-
3xx — 中間。サーバーがさらなる入力を必要としています（
DATAの後に使用）。 - 4xx — 一時的な失敗。クライアントは後で再試行する必要があります。例：メールボックス満杯（452）、サーバービジー（421）。
- 5xx — 永続的な失敗。再試行しないでください。例：ユーザー不明（550）、構文エラー（500）、リレー拒否（553）。
2番目の桁がカテゴリを絞ります。x0x = 構文、x1x = 情報、x2x = 接続、x5x = メールシステム。RFC 3463は5.1.1（不正な宛先メールボックス）のような拡張ステータスコードでさらに拡張しています。
主要な技術詳細
エンベロープとヘッダー
SMTP における重要な区別は、エンベロープとメッセージヘッダーの間です。エンベロープ（MAIL FROMとRCPT TO）はルーティングを制御し、サーバーにメッセージをどこに配信するかを指示します。メッセージヘッダー（From:、To:、Subject:）はDATAの間に送信されるメッセージ本体の一部であり、受信者が見るものです。これらは異なる場合があり、メーリングリスト、BCC、転送などの場合に正当に異なります。
MXルックアッププロセス
クライアントがuser@example.comに配信する必要がある場合、example.comのMXレコードをDNSに照会します。RFC 5321で定義されたプロセス。
- ドメインのMXレコードを検索。優先度でソート（低い番号 = より高い優先度）。
- MXレコードが存在しない場合、ドメイン自体のAまたはAAAAレコードにフォールバック。
- MXレコードが
.（RFC 7505に基づく「null MX」）を指している場合、ドメインはメールを受け入れません。 - 優先度順に各MXホストを試す。サーバーが4xxエラーを返した場合、次のホストを試す。
行長とデータ透明度
SMTPでは、メッセージ内の行は998文字（CRLFを除く）より長くない必要があり、推奨される制限は78文字です。データ終了マーカーは.だけを含む行です。メッセージ本体の行がピリオドで始まる場合、クライアントはそれの前に余分なピリオドを付けることで「ドット詰め」を行い、サーバーはそれを削除する必要があります。
タイムアウト
RFC 5321は、クライアントが従う必要のある最小タイムアウトを指定しています。
- 初期グリーティング: 5分
- MAILコマンド: 5分
- RCPTコマンド: 5分
- データ開始: 2分
- データブロック: 3分
-
データ終了（最終
.）: 10分
これらの余裕のあるタイムアウトは、受信サーバーが最終ドットに応答する前に高価なチェック（スパム フィルタリング、ウイルススキャン）を実行する可能性があるため存在します。
SMTP例
メッセージを配信する完全なSMTPトランザクション。
一般的なミス
-
エンベロープとヘッダーアドレスを混同する。
MAIL FROMエンベロープアドレスはFrom:ヘッダーと同じではありません。SPFはエンベロープ送信者をチェック。DKIM はヘッダーに署名します。これを間違えると認証失敗が発生します。 -
4xxと5xxの区別を無視する。
450は「後で再試行」を意味します。キューに入れて指数バックオフで再試行する必要があります。550は「決して機能しない」を意味します。再試行を続けると不要なトラフィックが発生し、送信者評判に害を及ぼします。 -
複数行応答を処理しない。
250-（ハイフン付き）のような応答は、さらに行が続くことを意味します。250（スペース付き）だけが最終行を示します。 -
EHLOなしで送信する。 古い
HELOコマンドの代わりに使用すると、STARTTLS、SIZE、PIPELININGのようなサーバー拡張を検出できません。常にEHLOを使用してください。 - 行長制限を超える。 998文字を超える行は仕様に違反し、メッセージの破損を引き起こす可能性があります。長いコンテンツにはMIMEエンコーディングを使用してください。
-
ヌル送信者を無視する。 バウンスメッセージ（DSN）は空の
MAIL FROM:<>を使用します。ヌル送信者を拒否すると、バウンスループ防止メカニズムが壊れます。 -
ドット詰めを実装しない。 メッセージ本体に
.で始まる行がある場合、サーバーはドットを倍にしない限り、それをデータの終わりと解釈します。
配信性への影響
RFC 5321準拠は、メールがインボックスに届くかどうかに直接影響します。
- 適切なEHLOホスト名。 EHLOホスト名はDNSで解決可能である必要があります（前方および逆方向）。多くの受信サーバーは、EHLOプラス名が有効なA/AAAAレコードを持つことを確認し、IPの逆引きDNスがマッチするかを確認しています。不一致はスパム信号です。
- バウンス処理。 RFC 5321は送信者がバウンスを処理することを要求しています。DSNを無視すると、無効なアドレスに送信し続け、送信者評判を破壊します。メールボックスプロバイダーは送信者のバウンス率をよく追跡しています。
- 再試行動作。 4xxエラーの指数バックオフによる適切な再試行ロジックは、よく振る舞う送信者であることを示しています。積極的な再試行動作はレート制限またはブロックリストをトリガーする可能性があります。
- 接続動作。 単一のMXへのあまりにも多くの同時接続を開くか、拒否された後に高速に再接続することは、スパムに関連するパターンです。接続制限を尊重し、適切にスロットルしてください。
-
エンベロープ配置。 SPFとDMARCは
MAIL FROMドメインに依存しています。エンベロープ送信者ドメインがFrom:ヘッダードメインと一致することを確認することは、認証チェックに合格するために不可欠です。