RFC 5321: SMTP

このRFCが決めたこと

横にスクロール

RFC 5321（2008年10月）は、電子メールをサーバー間で運ぶプロトコルSMTP（Simple Mail Transfer Protocol）の現行仕様だ。系譜は長く、起点は1982年のRFC 821。2001年のRFC 2821が821を置き換え、5321がさらに2821を置き換えて今に至る。40年以上を経てなお、世界中のメールは基本的にこの手順で運ばれている。

押さえるべきは分業だ。5321が決めるのはあくまで「運び方」であり、From:やSubject:といったヘッダや本文の書式は、同時に発行されたRFC 5322が定める。郵便に例えるなら、5321は郵便局の集配の決まり、5322は便箋の書き方に相当する。

要点の精読

エンベロープとヘッダ、二つの差出人

配送先を決めるのは、セッション中にMAIL FROMとRCPT TOの2つのコマンドで伝えられるエンベロープ情報だけだ。メール冒頭に並ぶFrom:やTo:のヘッダはRFC 5322が定める「便箋の記載」にすぎず、配送には一切使われない。

この分離があるからBCCが成立する。BCCの宛先はRCPT TOでサーバーには伝わるが、ヘッダに書かれないため他の受信者からは見えない。また、配送に失敗したときのバウンス（エラー通知）は、ヘッダのFrom:ではなく、エンベロープのMAIL FROMで指定されたアドレス（逆経路）へ返される。バウンス自体は逆経路を空にして送ることで、エラー通知同士の無限ループを防ぐ決まりも5321にある。

セッションの基本コマンド列と応答コード

SMTPはテキストの対話で進む。クライアントがコマンドを送り、サーバーが3桁の数字で応える。

S: 220 mail.example.com ESMTP
C: EHLO client.example.jp
S: 250-mail.example.com
S: 250 STARTTLS
C: MAIL FROM:<taro@example.jp>
S: 250 OK
C: RCPT TO:<hanako@example.com>
S: 250 OK
C: DATA
S: 354 Start mail input
C: From: Taro <taro@example.jp>
C: Subject: Hello
C:
C: (本文)
C: .
S: 250 OK queued
C: QUIT
S: 221 Bye

EHLOは従来のHELOを置き換えるESMTP（SMTPサービス拡張）の挨拶で、サーバーは利用できる拡張機能（STARTTLSなど）を応答で列挙する。拡張の枠組みは1995年のRFC 1869で定められ、現在は5321本体に統合されている。

応答コードは先頭の数字がクラスを表す。2xxは成功（250が代表）、3xxは中間応答（354はDATAに対する「本文をどうぞ」）、4xxは一時的な失敗、5xxは恒久的な失敗（550は宛先メールボックス利用不可など）だ。この区別は運用に直結し、送信側は4xxならキューに残して再送を試み、5xxなら即座にバウンスを生成する。本文の終わりはピリオドだけの行で示す。上の例で、エンベロープのMAIL FROMとは別に、DATA内でFrom:ヘッダを自由に書けている点にも注目してほしい。

MXレコードとリレーの仕組み

送信側サーバーは、宛先アドレスのドメイン部についてDNSへMXレコードを問い合わせ、配送先ホストを決める（DNSの仕組みはRFC 1035の精読を参照）。MXが複数あれば優先度値の小さい順に接続を試み、MXが1つも無ければAレコードのホストを暗黙のMXとして扱う、というフォールバックも5321が規定している。

SMTPは元来リレー（中継）を前提とした設計で、メールは複数のMTA（メール転送エージェント）を経由できる。経由した各サーバーは通過の記録としてReceived:ヘッダを先頭に追記していくため、ヘッダを上から読めば配送経路を逆順に辿れる。ただし誰のメールでも中継するオープンリレーは迷惑メールの踏み台になるため、現在のサーバーは自ドメイン宛ての受信と、認証済みユーザーからの送信しか扱わないのが原則だ。

ポート25・587・465の使い分け

現在のSMTPは役割ごとにポートを使い分ける。

メールソフトからの「投稿」とサーバー間の「配送」を分ける考え方は、RFC 6409（メッセージサブミッション、2011年）として標準化されている。投稿はポート587でSMTP認証（SMTP AUTH、RFC 4954）を必須とし、STARTTLSコマンド（RFC 3207）で平文接続をTLSへ昇格させる。一方のポート465は接続の最初からTLSで包むImplicit TLS方式で、長らく非公式の扱いだったが、2018年のRFC 8314が投稿用として正式に位置づけ直した。

認証の不在と後付けの送信ドメイン認証

5321自体には、送信者が本人かを確かめる仕組みがない。プロトコル上、MAIL FROMにもFrom:ヘッダにも任意のアドレスを書けてしまう。これは相互信頼で成り立っていた1982年当時の設計を受け継いだ結果であり、なりすましメールが技術的に可能な根本原因だ。

この穴を塞ぐために送信ドメイン認証が後付けされてきた。SPF（RFC 7208、2014年）は、エンベロープのMAIL FROMドメインに対して送信元IPアドレスが正当かをDNSで検証する。DKIM（RFC 6376、2011年）はヘッダと本文への電子署名で出自と非改ざんを保証する。DMARC（RFC 7489、2015年）は受信者に見えるFrom:ヘッダとSPF/DKIMで認証されたドメインの一致（アライメント）を要求し、不一致時の扱いをドメイン所有者がポリシーとして宣言できるようにした。自ドメインの設定状況はSPFチェッカーとDMARCチェッカーで確認できる。

つまずきやすい点

最大の落とし穴は、エンベロープFrom（MAIL FROM）とヘッダFrom（From:）の不一致だ。SPFが検証するのは前者のドメインだけで、受信者の画面に表示されるのは後者。つまりSPFに合格していても、表示上の差出人が別ドメインというメールは作れてしまう。この隙を埋めるのがDMARCのアライメントであり、自ドメインをなりすましから守るには、SPF・DKIMに加えてDMARCポリシーの公開までが一揃いだと考えたい。

次に、バウンスはヘッダFromではなくエンベロープFrom宛てに返る。メーリングリストや転送サービスがエンベロープFromを自前のアドレスへ書き換えるのはこのためで、送信システムのエラー処理を設計するときは「どちらのFromに届くのか」を常に意識する必要がある。

最後に、ポート25での外向き送信は多くのISPにブロックされている（Outbound Port 25 Blocking）。ウイルス感染したコンピュータからの直接送信を防ぐ対策であり、メールソフトの送信が25番で失敗するのはむしろ正常に近い。設定は587（または465）と認証の組み合わせが正解だ。

まとめ

RFC 5321は、エンベロープとヘッダの分離という設計思想の上に、コマンドと応答コードによる転送手順、MXレコードによる配送先解決、リレーの規律を定めた電子メールの土台だ。認証の不在という生まれつきの弱点はSPF/DKIM/DMARCで補われており、この経緯ごと理解すれば「届かない」「なりすまされる」という実務の問題を仕組みから説明できるようになる。ほかのプロトコルの精読はRFC精読から辿れる。