RFC 3207 – SMTP STARTTLS拡張機能

Proposed Standard Transport Security Obsoletes RFC 2487 Published March 2026

ELI5: 混雑した部屋での会話を想像してください。誰でも聞くことができます。STARTTLSは会話の途中で「プライベートルームに行きましょう」と言うようなものです。最初はプレーンテキストでSMTPセッションを開始し、機密情報が交換される前に両側が暗号化通信に切り替えることに同意します。その後、誰もメール転送を盗聴することはできません。

このRFCが存在する理由

SMTPが1982年に設計されたとき、暗号化は考慮されていませんでした。メッセージはインターネット上を平文で移動し、ネットワークパスにアクセスできる誰もがそれらを読むことができました。インターネットがより敵対的になるにつれて、転送中のメール暗号化が不可欠になりました。

RFC 3207は、SMTP用のSTARTTLS拡張を定義し、平文のSMTP接続を暗号化されたTLS接続にアップグレードできるようにします。2002年に公開されたこれは、セキュリティに関する考慮事項とサーバーの動作の説明でRFC 2487に置き換わりました。

STARTTLSはポート25のサーバー間(MTA間)メールトラフィックを暗号化するための支配的なメカニズムです。クライアント間サブミッション用に、RFC 8314はポート465での暗黙的なTLSを推奨していますが、ポート587でのSTARTTLSは広く使用されています。

動作方法

STARTTLSはSMTP拡張として機能し、EHLO交換中にネゴシエートされます。

クライアントはポート25(または587)でサーバーに平文で接続します。
クライアントがEHLOを送信します。サーバーはその機能を応答し、暗号化をサポートする場合は250-STARTTLSを含みます。
クライアントがSTARTTLSを送信します。
サーバーが220 Ready to start TLSで応答します。
両側がTLSハンドシェイクを実行し、暗号化チャネルを確立します。
クライアントが暗号化された接続で新しいEHLOを送信します。サーバーの機能リストが変わる可能性があります(例:AUTHが現在アドバタイズされています)。
SMTPセッションは通常通り続きますが、すべてのトラフィックは暗号化されています。

SMTP例

サーバー間転送中のSTARTTLSネゴシエーション:

# ポート25での平文接続が確立されました S: 220 mx.example.com ESMTP C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES # クライアントはSTARTTLSが利用可能であることを認識し、アップグレードをリクエストします C: STARTTLS S: 220 2.0.0 Ready to start TLS # --- TLSハンドシェイクがここで発生します --- # 以降のすべてのトラフィックは暗号化されています # クライアントはTLS後にEHLOを再発行する必要があります C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-AUTH PLAIN LOGIN S: 250 ENHANCEDSTATUSCODES # 注:STARTTLSはもうアドバタイズされていません(既にアクティブです) # 注:AUTHは現在アドバタイズされています(TLS後にのみ利用可能) C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: [メッセージコンテンツ...] C: . S: 250 2.0.0 OK

主要な技術詳細

日和見的vs必須TLS

RFC 3207で定義されているSTARTTLSの重大な制限は、デフォルトでは日和見的であることです:

日和見的TLS: クライアントはサーバーがそれをアドバタイズする場合STARTTLSを試みますが、それが利用不可の場合またはTLSハンドシェイクが失敗した場合は平文にフォールバックします。これはMTA間接続のデフォルト動作です。
必須TLS: クライアントはTLSが確立されない限りメッセージの送信を拒否します。これはドメイン単位で設定するか、MTA-STS(RFC 8461)またはDANE(RFC 7672)を使用して実装することができます。

日和見的TLSはダウングレード攻撃に対して脆弱です。ネットワーク攻撃者はEHLO応答からSTARTTLS機能を削除でき、接続を平文のままにします。初期ネゴシエーションが平文で行われるため、クライアントはサーバーがTLSをサポートしていることを知る方法がありません。

証明書検証

RFC 3207はMTA間接続に対して厳格な証明書検証を要求しません。実際には、多くのサーバーは自己署名証明書またはMXホスト名と一致しない証明書を使用しています。根拠:検証なしの日和見的暗号化は依然として暗号化なしより優れています。受動的な監視から保護しますが、アクティブな中間者攻撃を防ぐことはできません。

より強力な保証のために、以下を使用します:

DANE(RFC 7672) — DNSSECで保護されたTLSAレコードを介してDNSにサーバーのTLS証明書を発行します。
MTA-STS(RFC 8461) — 証明書検証を伴うTLSを要求するポリシーを発行し、送信サーバーによってキャッシュされます。

STARTTLS後のRe-EHLO

TLSハンドシェイクが完了した後、クライアントは新しいEHLOコマンドを発行する必要があります。TLS前のサーバーの機能リストは破棄される必要があります。これが重要な理由は:

暗号化が確立された後、サーバーは異なる機能をアドバタイズする可能性があります(例:AUTH)。
暗号化は既にアクティブであるため、サーバーはSTARTTLSをもうアドバタイズしないはずです。
攻撃者はTLS前のEHLO応答を修正した可能性があります。

異なるポートでのSTARTTLS

ポート	プロトコル	TLS動作
25	SMTPリレー	STARTTLS(MTA間で日和見的)
587	サブミッション	STARTTLS(実質的に必須 — AUTHはそれを要求します)
465	サブミッション	暗黙的TLS(SMTPコマンド前にTLSハンドシェイク)

TLSレポーティング

RFC 8460はSMTP TLSレポーティング(TLSRPT)を定義し、ドメイン所有者がTLS接続失敗に関するレポートを受け取ることができます。これはDMARC集計レポートに相当するSTARTTLSです — サーバーへの接続がTLSネゴシエーションに失敗しているときに通知します。

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

一般的な間違い

STARTTLSはメッセージがエンドツーエンドで暗号化されることを意味すると想定する。 STARTTLSは2つの隣接するサーバー間の接続のみを暗号化します。メッセージが複数のホップを通過する場合、各ホップはTLSを独立してネゴシエートします。メッセージはあるホップで暗号化され、次のホップで平文である可能性があります。
STARTTLS後にEHLOを再発行していない。 TLSハンドシェイク後に新しいEHLOを送信しないことはプロトコル違反です。古い機能データで作業し、AUTHなどの新たに利用可能な機能を見逃す可能性があります。
STARTTLSの失敗を永続的なエラーとして扱う。 STARTTLSネゴシエーションが失敗した場合、接続は未定義の状態です。接続を閉じて新しい接続を開始します。同じ接続で平文を続けようとしないでください。
STARTTLSをアドバタイズしているが、期限切れまたは設定ミスの証明書を使用している。 多くのクライアントは証明書エラーにもかかわらず進みますが、増加する厳格なクライアント(およびMTA-STS/DANEポリシー)は拒否します。TLS証明書を有効で正しく設定した状態に保ってください。
セキュリティのためにSTARTTLSのみに依存する。 STARTTLSは日和見的でダウングレード攻撃に対して脆弱であるため、暗号化が重要なドメインではMTA-STSまたはDANEで補完される必要があります。
ポート587でSTARTTLSを忘れている。 サブミッション用に、クライアントは認証前に常にSTARTTLSを実行する必要があります。AUTH認証情報を平文で送信すると、接続を監視している誰でもあなたのSMTPパスワードが公開されます。

配信性への影響

GoogleおよびメジャープロバイダーはTLS暗号化されていないメールにフラグを立てます。 GmailはTLS暗号化なしで受信したメッセージに赤い開いた南京錠アイコンを表示します。これはメッセージが転送中に傍受された可能性があることを受信者に通知し、信頼度を低下させます。
TLS採用はほぼ普遍的です。 2025年の時点で、Gmailに送信されたメールの95%以上がTLSで暗号化されています。送信インフラストラクチャでSTARTTLSをサポートしないことはあなたを少数派にし、送信者の評判に悪影響を与える可能性があります。
MTA-STS実装が増加しています。 メジャープロバイダーは証明書検証を伴うTLSを要求するMTA-STSポリシーを発行しています。送信サーバーが有効な証明書でTLSを正常にネゴシエートできない場合、これらのドメインへの配信は失敗します。
TLSレポーティングが問題を露呈させます。 TLSRPTレコードを発行する場合、サーバーにTLS問題があれば、レポートを受け取ります。TLSRPTを発行しない場合、接続失敗について盲目です。
コンプライアンス要件。 HIPAA、GDPR、PCI-DSSおよび他の規制はメール用に転送中の暗号化を益々要求しています。STARTTLSはサーバー間メールのこの要件を満たす基準メカニズムです。