STARTTLSとは
STARTTLSは、平文で始めた通信を途中からTLS暗号化へ切り替えるためのSMTPやIMAPなどの命令です。正式名称はStart Transport Layer Security(スタート・トランスポート・レイヤー・セキュリティ)に由来し、一般に「スタートティーエルエス」と読みます。
最初に通常のプロトコルで接続し、サーバーがSTARTTLS対応を広告したことを確認して命令を送ります。成功応答後にTLSハンドシェイクを行い、同じTCP接続の残りを暗号化します。
STARTTLSという名前は暗号方式ではなく、接続の状態を平文からTLSへ切り替える合図です。TLSを開始しただけでなく、証明書検証と暗号化必須条件まで確認します。

接続の状態が変わる五つの境界を読む
サーバー挨拶を受け、まだ秘密情報を送らず能力確認を始める
SMTPならEHLO、IMAPならCAPABILITYなどからSTARTTLSの提供を知る
成功応答が返った直後から、通常命令ではなくTLS記録を交換する
暗号条件を合意し、証明書の信頼・名前・期限を検証する
保護前の情報を捨て、TLS後の状態でEHLOなどを再実行する
必要な安全条件を満たしたことを確認してプロトコルを続ける
暗黙的TLSは、最初の1バイトからTLSで始まる
STARTTLSはプロトコル平文からアップグレードするexplicit TLS(エクスプリシット・ティーエルエス/明示的TLS)です。対して暗黙的TLSは、TCP接続直後からTLSハンドシェイクを始め、その内側でSMTPやIMAPを話します。
メール利用者の投稿・アクセスでは、RFC 8314が暗黙的TLSを推奨しています。一方、SMTPサーバー間配送ではポート25上のSTARTTLSが広く使われます。設定画面の「SSL/TLS」と「STARTTLS」は、接続開始時の手順が違うため取り違えられません。
機会的暗号化と必須暗号化では、失敗時の動作が違う
サーバー間SMTPのSTARTTLSは、相手が対応すれば暗号化し、対応しなければ平文で続けるopportunistic encryption(オポチュニスティック・エンクリプション/機会的暗号化)として使われることがあります。到達性を優先できますが、暗号化を保証しません。
利用者が投稿サーバーへ資格情報を送る場合は、TLSが確立できなければ中止する設定が必要です。配送でもMTA-STS、DANE、REQUIRETLSなど別のポリシーで必須条件を強化できます。STARTTLS広告の存在だけで保証とみなしません。
広告を消す攻撃に備え、期待するTLSを記憶する
切替前の能力確認は平文なので、通信途中の攻撃者がSTARTTLS広告や命令を削除するSTARTTLS stripping(スタートティーエルエス・ストリッピング)を試せます。クライアントが「なければ平文で続ける」と、攻撃を検出できません。
利用者設定ではTLS必須にし、以前使えた暗号化が突然消えたら接続を止めます。サーバー間配送ではポリシー公開やDNSSECと組み合わせ、相手がTLSを要求していることを検証します。
暗号化表示だけでなく、証明書の検証を行う
TLSは接続先の証明書を提示します。クライアントは信頼された発行元か、接続先ホスト名と一致するか、有効期間内か、失効やアルゴリズム条件を満たすかを確認します。
警告を無視して続けると、暗号化された相手が攻撃者という状態になり得ます。メールアドレスのドメインではなく、設定で指定したサーバーホスト名と証明書を照合する点にも注意します。
STARTTLS成功後は、プロトコル状態をリセットする
SMTPではTLSハンドシェイク完了後、クライアントはEHLOを再送します。サーバーはTLS前に得たクライアント情報を捨て、クライアントもTLS前の拡張一覧を使いません。これは攻撃者が平文区間で改変した状態を持ち込まないためです。
認証済み状態の途中でSTARTTLSを実行するものではありません。接続、能力確認、TLS、再確認、SMTP AUTH、メール投稿の順に行います。
ログでは秘密ではなく、状態遷移と検証結果を残す
STARTTLS命令の成否、TLS版、暗号スイート、証明書名・発行元・期限、検証エラー、TLS後のEHLO結果を記録します。セッション鍵、パスワード、OAuthトークン、メール本文は診断ログへ残しません。
暗黙的TLSかSTARTTLSか、暗号化が必須か任意か、証明書を厳格検証するかを設定ごとに確認し、警告時に平文へ自動降格しないことが重要です。
切替手順と運用の確認資料:RFC 3207「SMTP STARTTLS」、RFC 8314「Cleartext Considered Obsolete」、RFC 9051「IMAP4rev2」