SMTPS

読み：えすえむてぃーぴーえす　／　英語表記：SMTP over Implicit TLS

• Web・メール・ファイル転送
• ネットワークサービス

SMTPのやり取りに先立ってTLSハンドシェイクを行い、メール送信の通信を暗号化する方式である。メールソフトから送信サーバへの接続には通常TCPの465番ポートを使う。

イマシルちゃんの解説

メールを送るSMTPというプロトコルは、それだけでは通信を暗号化しないんだ。
SMTPSは、通信を暗号化するTLSでSMTPのやり取りを最初から保護する方式だよ。
メールソフトが送信サーバにつないだら、まずTLSハンドシェイクという手順で証明書を確認し、暗号化の準備をするの。

それから利用者の認証やメールの送信に進むから、認証情報やメールの内容を暗号化して送れるんだ。
SMTPで話し始めてからTLSへ切り替えるSTARTTLSとは、TLSを始めるタイミングが違うよ。
TLS接続を確立できなければメールを送らないから、気づかないうちに平文で送ってしまうのを防げるんだ。

より深い解説

まず暗号化する区間を確認する

SMTPは、メールの送信やメールサーバ間の転送に使うアプリケーション層（第7層）のプロトコルである。
SMTPSではSMTPのコマンドや応答の手順を保ったまま、その通信をTLSで保護する。

本記事では、TCP接続の直後にTLSの交渉を始めるImplicit TLS（暗黙的TLS）によるSMTPの利用を扱う。
メールソフトから送信サーバへメールを預ける処理はサブミッションと呼ばれる。
これに対し、メールサーバ間でメールを中継する処理をSMTPリレーという。
次の構成では、投稿の受付と中継を同じ送信サーバで行う。

最初に押さえる点は、SMTPSの暗号化通信路が「メールソフトと接続先の送信サーバ」の間にあることだ。
送信サーバはTLS接続の受信端として暗号文を復号し、SMTPの処理へ渡す。
このようにTLSの保護区間の端となることをTLS終端という。
図ではメール投稿のTLS接続を①、サーバ間転送でTLSを利用する場合の接続を②として区別する。

送信する側では、SMTPのデータをTLSで暗号化し、TLSレコードとしてTCPで運ぶ。
受信する側では、TLSで復号したデータをSMTPの処理へ渡す。
サーバからの応答も逆方向に同じTLS接続で保護される。

送信サーバは、宛先側メールサーバのTCPポート25番へ接続してSMTPリレーを行う。
メールソフトから受け付けた投稿用TCP接続を、そのまま宛先側へ延長するのではない。
転送区間を暗号化する場合は、サーバ間のSMTP接続でSTARTTLSを使ってTLS接続②を確立する。
TLS接続①と②は接続相手と暗号化の鍵をそれぞれ管理するため、①を設定しても②の暗号化は保証されない。

「暗号化されたトンネル」はTLS接続の比喩である。
SMTPSはSMTPのデータをTLSレコードとして保護する方式であり、IPパケット全体を運ぶVPNのトンネリングとは区別する。

注意：メール投稿のTLS接続①は送信サーバで終端する。サーバ間のTLS接続②と、保存データの暗号化はSMTPSの設定だけでは有効にならない。

仕様：RFC 8314、RFC 8446、RFC 5321、RFC 3207。

接続のどの時点から暗号化されるか

SMTPSでは、SMTPの開始応答より先にTLS接続を確立する。
メールソフトが送信サーバへ接続する際の流れは、次の順になる。

メールソフトは、TCP接続後にClientHelloを送ってTLSの交渉を始める。
初回接続でサーバ証明書を使う場合は、証明書を検証し、通信に使う鍵や暗号方式を確立する。

TLS接続が確立してから、サーバがSMTPの開始応答である220を返す。
この最初のSMTP応答も、すでに暗号化された通信路を通る。

続いてメールソフトがEHLOで拡張機能を確認し、AUTHコマンドで利用者認証を行う。
認証後はMAIL FROMで差出人、RCPT TOで宛先を指定する。DATAへの送信許可を受けて、メールのヘッダーと本文を送る。

「最初から暗号化する」とは、SMTPを平文で始めないという意味である。
TCPの接続処理やTLSの交渉情報まで、最初の1ビットからすべて隠すという意味ではない。

図ではTLSの交渉の細部と一部のSMTP応答を省略している。
TLS接続を確立できなければ、認証情報やメールを送らずに接続を中止する。

仕様：RFC 8314の3.3節、RFC 5321、RFC 4954。

途中から暗号化へ切り替える方式との違い

SMTPには、平文で始めた通信を途中からTLSへ切り替えるSTARTTLSという拡張もある。
SMTPSとの違いは「暗号化できるか」ではなく、SMTPとTLSをどちらから始めるかである。

メール投稿用のTCPポート587番で、この拡張を使う例を示す。

切替えを要求してサーバが準備完了を返すと、同じTCP接続のままTLSの交渉に進む。
この例では、メール投稿用のTCPポート587番への接続を維持する。
SMTPS用のTCPポート465番へ接続し直す手順ではない。

TLSの確立後は、暗号化前に受け取った拡張機能の一覧を破棄する。
改めてEHLOを送り、暗号化後に利用できる機能を確認してから認証とメール送信へ進む。

このため、途中から切り替える方式でも、認証情報やメールの本文を平文で送る必要はない。
認証とメール送信の前にTLSを必須にすれば、どちらも暗号化できる。

注意：「TLSを使えなければ平文で続行する」という設定では、暗号化されないまま送信されるおそれがある。
TLS対応の通知を途中で削除する攻撃などに備え、メール投稿ではTLSを必須にする。

正しく実装され、両側でメール投稿前のTLS確立を必須としていれば、両方式の安全性に大きな違いはない。
SMTPSには、平文でのSMTP開始と切替え判断をなくせる利点がある。

仕様：RFC 3207の4.2節、RFC 8314の3.3節、RFC 9325の3.2節。

ポート番号と送信の役割を分ける

メールの「送信」には、利用者が送信サーバへメールを預けるサブミッションと、メールサーバ同士で中継するSMTPリレーがある。
まず誰から誰への接続かを確認し、そのあとにポート番号とTLSの開始方式を確認する。

利用者から送信サーバへの投稿

• TCPの465番：接続直後にTLSを開始する。IANAのサービス名はsubmissionsである。
• TCPの587番：メール投稿用のポートである。暗号化する場合はSTARTTLSでTLSへ切り替える。

メールサーバ同士の転送

TCPの25番を使う。
この接続でTLSを使う場合も、STARTTLSで切り替える。したがって、この番号を「必ず平文で送るポート」と考えてはいけない。

これらはサーバが接続を待ち受けるポート番号である。
メールソフトの送信元ポートには通常、OSが一時的に割り当てるエフェメラルポートを使う。
サーバの待受ポートとは役割が異なるため、TCP接続の両端で同じ番号を使う必要はない。

例えば送信元が53,024番、宛先が465番なら、同じTCP接続の応答では送信元が465番、宛先が53,024番になる。
ポート番号だけで暗号化を判断せず、TLSの設定と実際の接続状態も確認する。

仕様：RFC 6409、RFC 6335、IANAのポート登録。

サーバ認証と利用者認証を区別する

TLSとSMTP-AUTHにはどちらも認証が関係するが、確認する対象と方向が異なる。

メールソフトが送信サーバを確認する

TLSでサーバ証明書を検証し、意図した接続先かを確認する。
信頼する認証局につながる証明書チェーン、有効期間、接続先ホスト名との一致などを調べる。

例えば接続先を smtp.example.com と設定した場合は、証明書のSAN（Subject Alternative Name）にあるDNS名と照合する。
証明書を受け取っただけでは、正しい接続先と確認できたことにはならない。

送信サーバが利用者を確認する

SMTP-AUTHは、メールを投稿する利用者を認証するSMTPの拡張である。
一般的な送信サービスでは、TLS確立後にAUTHコマンドで認証情報をやり取りする。

TLSのサーバ認証ではメールソフトが接続先サーバを確認し、SMTP-AUTHの利用者認証では送信サーバがメールを投稿する利用者を確認する。
SMTPSを使うだけで利用者認証が不要になるわけではない。

注意：証明書の検証を無効にすると、偽のサーバへの接続を見逃すおそれがある。
接続できない場合は、検証を外すのではなくホスト名や証明書の設定を直す。

仕様：RFC 9525、RFC 4954。

通信中の暗号化とメール自体の暗号化を分ける

冒頭の図で示したとおり、送信サーバではTLSを終端してSMTPのデータを復号する。
そのため、SMTPSの設定だけでは「サーバ上でも本文が暗号化されたまま保存される」とは判断できない。

保存時暗号化は、ストレージに保存するデータを暗号化する対策である。
例えば、保存領域全体を対象とするディスク暗号化や、メールを格納したファイルを対象とするファイル暗号化をサーバ側で設定する。
これらは保存媒体からの情報漏えいに備える対策であり、通信中のSMTPを保護するTLSとは保護対象が異なる。

ただし、保存時暗号化を行っていても、サーバが復号鍵を利用できる構成ではメールの内容を復号して処理できる。

メールサーバにも本文を読ませないことが要件なら、S/MIMEなどでメール自体を暗号化する方法を検討する。
送信者のメールソフトで暗号化し、受信者側だけが利用できる復号鍵で復号する構成はエンドツーエンド暗号化に当たる。
この構成では、中継するメールサーバには本文の復号鍵を渡さず、本文を暗号文のまま配送する。

受信者がメールを読む際は、受信者のメールソフトからメール保存先のサーバへIMAPまたはPOP3で接続する。
接続直後からTLSで保護する場合は、IMAPS（TCPの993番）またはPOP3S（TCPの995番）を利用する。
送信サーバへのSMTPS接続を設定しても、これらの受信用接続のTLS設定は変更されない。

なお、SMTPSでは接続先のIPアドレスやTCPポート番号まで隠れるわけではない。
通信路の保護・保存時の保護・メール自体の保護を分けて考えると、必要な対策を選びやすくなる。

仕様：RFC 8314、RFC 8551。
保存時暗号化の分類：NIST SP 800-111。

送信できないときは段階を分けて調べる

メールソフトでは、送信サーバ名・ポート番号・TLSの開始方式・認証方式を、サービスの指定に合わせる。
問題が起きた場合は、次のどの段階まで成功しているかを確認する。

1. TCP接続を確立できない

名前解決、ファイアウォール、サーバの待受ポートを調べる。
この段階では、まだ利用者名やパスワードの正誤を判断できない。

2. TCP接続後に処理が止まる

クライアントとサーバで、TLSの開始方式が一致しているかを調べる。
SMTPSのサーバはTLSの開始を待つが、平文SMTPとして接続したメールソフトはSMTPの開始応答を待ってしまうことがある。

3. 証明書の検証に失敗する

接続先名、証明書の有効期限とチェーン、端末の日時を調べる。
TLSのバージョンや暗号方式にも双方の対応が必要である。

4. TLSは成功したが利用者認証に失敗する

535の認証エラーなどが返る場合は、利用者名や認証情報、許可された認証方式を調べる。
暗号化の確立に成功しているため、まずSMTP-AUTHの設定を切り分ける。

TLSの設定では、RFC 9325に基づきTLS 1.2以降を使い、双方が対応する場合はTLS 1.3を優先する。
古いSSLやTLS 1.0・1.1を有効にして回避するのではなく、端末やサーバを更新する。

認証エラーの応答コード：RFC 4954の6節。

午後問題を想定した確認例

確認1：サーバに保存されたメールの保護

問題
「送信ソフトをSMTPSに変更したので、メールサーバ上でも本文は暗号化されている」という説明は正しいか。

解答
正しくない。

理由
SMTPSが保護するのは、メールソフトと送信サーバの間のSMTP通信である。
送信サーバではTLSを終端してSMTPのデータを復号する。
保存されたメールも暗号化したい場合は、サーバのディスク暗号化やメール保存ファイルの暗号化が有効かを確認する。

サーバにも本文を読ませない要件なら、S/MIMEなどによるメール自体の暗号化を検討する。

確認2：暗号化と認証の切り分け

問題
TCP接続とTLSの確立には成功したが、利用者認証に失敗した。
何を先に調べるか。

解答
SMTP-AUTHに使う認証情報と、サーバが許可する認証方式を調べる。

理由
通信路の暗号化はすでに成功しているが、利用者の認証は成功していない。
TLS接続の確立とSMTP-AUTHによる利用者認証を区別して切り分ける。

この用語が出てくる記事

• サブミッションポート