POP3S・SMTPS・STARTTLSとは|電子メールの危険性
- 著者:YAMANJO
- 公開日:2008年11月24日
- 最終更新日:2025年6月16日
電子メールの危険性と、さまざまなセキュリティ対策について理解していきましょう。
電子メールの危険性
前項で学習のとおり、電子メールは非同期的な送受信構造を持つ「メッセージ交換方式」です。
そのため、送信と受信で異なるアプリケーション層のプロトコルを使用しており、複数のプロトコルが存在します。代表的なプロトコルは、送信の「SMTP」、受信の「POP」と「IMAP」の3つです。
ただし、これらのプロトコルはインターネットの初期から存在する古いプロトコルで、セキュリティ機能はほとんどなく、セキュリティリスクに対しては非常に脆弱です。
そこで、様々な方法でこれらのプロトコルのセキュリティを強化してきました。どのようなセキュリティ対策が行われているのかを理解していきましょう。
そもそも、
POPでメールを受け取る場合には「認証」を必要とする
仕組みになっています。
POPも、FTP や PPP と同じように、認証しなければPOPサーバに接続することはできません。
いくら古いプロトコルでセキュリティ機能が脆弱といっても、自分のメールを認証しで誰でも受信することができたらさすがに問題です。POPの認証は、メールサーバにある自分のメールボックスを開ける鍵で、銀行の暗証番号のようなものになります。
ところが、
SMTPでメールを送信する場合には「認証」機能がない
のです。
なぜかというと、SMTPには認証を必要とするという考え方がなかったからです。SMTPはどのようなメールでも、内容に関わらずそのまま送信先に転送するプロトコルです。郵便と同じように誰でもアドレスを指定することで相手に届きます。
そのため、送信されたメールはメールサーバ(SMTPサーバ)をただ通過するだけになります。銀行でお金を引き出す時には認証が必要で、振り込む時には誰でも振り込めるのと同じです。
こうした仕組みのもとで電子メールが利用されているために、様々な問題が起こってきました。
下図は、10年以上前にWindows Vistaが標準搭載していたメーラー「Windowsメール」の設定画面です。

このように「受信メールサーバー」と「送信メールサーバー」それぞれに設定ができるようにするようになっています。
現在のメーラーでは「メールサーバー」にまとめられることもありますが、POP(受信メールサーバー)には、ユーザー名(アカウント)とパスワードを指定する欄があり、認証が必要なことがわかります。
ここで入力する「ユーザー名」と「パスワード」は、契約したプロバイダ等(ドメイン取得やレンタルサーバなどの契約者)から送られてきます。メーラーに設定しておけば、起動と同時にメールの送受信が行われるため、POP認証も自動的で行われます。
ところが「送信メールサーバー」のところには認証情報を入力する欄がありません。(赤線の「このサーバーは認証が必要」については後述します)
こうした仕組みのために、多くのトラブルが起こるようになりました。
誰でも他人のSMTPサーバにアクセスしてメールを送信することができる
からです。
そのため、スパムメール(営利目的の広告やダイレクトメールといった迷惑メール)やマルウェアなどが無差別にばら撒かれる要因となったのです。(マルウェアについては、マルウェアの種類と特徴 で詳しく学習します)
知らないうちに悪意のある第三者によって、自分のSMTPサーバからスパムメールが配信される「踏み台」として利用されることが起こりました。
また、こうして簡単に他人になりすますことが可能になり「なりすまし」によってクレジットカード等の暗証番号を入手しようとするフィッシング詐欺も問題となりました。
そこで、様々な対策が考えられるようになっていきます。
POP before SMTP
POP before SMTP(ポップ・ビフォア・エスエムティーピー)は、直訳すると「SMTPの前にPOP」になります。
文字どおり、
メールを送信する前に受信して認証を行う
という方法です。
つまり、SMTPサーバに接続する前にPOPサーバに接続して認証を受けるという仕組みです。単純な仕組みですが、これだけでユーザー認証を行うことができます。
既存システムのままで設定を変更する必要がないことから、多くのプロバイダで採用されました。ユーザー側もメーラーの起動と同時にメールを受信してくる(認証を行う)ので、特に意識することもありません。
とは言え、やはりこれだけでは不十分でした。POP before SMTP方式の中身は、
POP認証が行われた後の一定期間だけメールの送信を許可する
というものです。
厳密に言えば、POPで認証したIPアドレスに対して一定期間SMTP送信を許可とするという運用です。一定期間というのはプロバイダによって異なりますが、数分から十数分程度です。そのため、逆に言えばこの間は認証なしでメールが送れることになります。
さらに、IPアドレスとは(3) で学習したNATによるIPアドレス変換が行われている場合は、ネットワークでIPアドレスを共有するため、一人のユーザー認証によってネットワーク内のすべてのユーザーが認証できてしまうといった問題もありました。
また、メールの受信(メーラーの起動)から数分間経過すると、再度POP認証を受けないとメールを送信することができなくなり、ユーザーからメールが送信できないといった問い合せがプロバイダへ数多く寄せられるなど、問題解決にはなりませんでした。
こうして、SMTPにも認証機能を持たせる必要性が高まっていきます。
SMTP-AUTH
SMTP-AUTH(エスエムティーピー・オース)は、「SMTP認証」とも呼ばれる仕組みです。AUTH(オース)は「authentication」の略で「認証」の意味になります。
これも文字どおり、
SMTPに認証機能を持たせた拡張規格
になります。
POPと同様に、メール送信時にSMTPサーバでユーザーIDとパスワードによる認証を行います。先ほどの図の「このサーバは認証が必要」という赤線の箇所がこの設定になります。
下図は、Outlookの設定画面になります。「送信サーバ(SMTP)は認証が必要」にチェックが入っています。

多くのSMTPサーバでは、上図と同様にPOPサーバと同じユーザーIDとパスワードで認証できます。「メールを送信する前に受信メールサーバーにログオンする」が、POP before SMTPのことです。
具体的なメーラーの設定方法については、基本操作 メール編 で解説していますが、SMTP-AUTHでは「587番」ポートを使用します。多くのプロバイダでは、スパムメール対策としてそれまでSMTPサーバで使用していた「25番ポート」を閉じて、587番や465番にポートを変更しました。(ポートについては、TCP/IPとは を参照してください)
SMTP-AUTHによって、送信時も認証を行うことでなりすましを防止し、安全に電子メールがやり取りできるようになりましたと言いたいところですが、まだ完璧ではありませんでした。
なぜなら、
電子メールはプレーンテキスト(平文)でやり取りされる仕組み
だからです。
前項で学習のとおり、7ビットのASCII文字でなければやりとりすることができません。言い換えれば、テキストファイルしか扱うことができないということです。
平文(ひらぶん)という用語は次項以降も出てきます。暗号化されていないファイルを示す用語です。広い意味では、テキストファイルだけでなく暗号化されていない他の形式のファイルも含まれます。
つまり、郵便ハガキと同じように文章が「丸見え」ということです。容易に内容を読み取ることができてしまいます。内容だけならまだしも、致命的なのは、IDやパスワードも丸わかりになってしまうことです。
なぜかというと、
サーバの認証に使うパスワードも平文で送られていた
からです。
POP認証はもちろん、SMTP認証でも暗号化できる一部の方式を除いて、パスワードも平文でやり取りされていました。
下図のように、メーラーのパスワードの入力欄は「●●●」や「***」と表示され、まるで暗号化されているように見えますが、実際には平文で送られていたのです。

つまり、平文でパスワードが見えてしまうということは、ユーザー認証が意味をなさないということになります。そこで、まずはSMTP認証ではなく、POP認証からパスワードを暗号化する仕組みが開発されました。
それが、
APOP(エーポップ)
という技術です。
APOPは「Authenticated Post Office Protocol」の略になります。プロトコルの名が付いているとおり、POPのセキュリティ機能を高めたプロトコルです。APOPを使用すると、パスワードを暗号化して送信し、POPサーバと安全に認証することができます。
しかし、2007年にAPOPの脆弱性(セキュリティ上の欠陥)が発見され、現在では非推奨とされており、ほとんど使われていません。また、APOPでは認証時のパスワードが暗号化されるだけでメール本文は暗号化されないため、やはり安全とは言えませんでした。
そのため、認証パスワードもメール本文も暗号化する技術が開発されるようになります。SMTP-AUTHでも暗号化方式が開発されましたが、以降に説明する技術の登場によって、現在ではほとんど利用されていません。(SMTP-AUTHの暗号化規格が使われていないという意味で、SMTP-AUTH自体は広く使われています)
SMTPS・POP3S・IMAPS
では、どうすれば安全な通信が保証できるのかと言うと、SMTP認証、SMTPでの本文の送信、POP認証、POPでの受信のすべての行程で暗号化する必要があるということです。
ただ、4つに分解するわけではなく、それぞれのサーバとの通信を暗号化できればよいので、メーラー(ローカルホスト)とSMTPサーバの間、メーラー(ローカルホスト)とPOPサーバの間の通信を暗号化できればよいわけです。
こうして、2地点間のSMTPとPOP通信を暗号化する仕組みが開発されました。
POP通信を暗号化する技術を「POP over SSL/TLS(ポップ・オーバー・エスエスエル/ティーエスエス)」、SMTP通信を暗号化する技術を「SMTP over SSL/TLS(エスエムティーピー・オーバー・エスエスエル/ティーエルエス)」と言います。
POP over SSL/TLSは「POP3S(ポップスリーエス)」とも呼ばれ、SMTP over SSL/TLSは「SMTPS(エスエムティーピーエス)」とも呼ばれています。
どちらにも「SSL/TLS」が入っており、暗号化通信にはSSL/TSLという規格を使用するということです。暗号化通信の仕組みについては、次項から詳しく学習していきますが、これまでに学習したHTTPSやFTPS、SSHといった暗号化通信もSSL/TLSを利用しています。
またこれまで、A over Bという名称は何度も登場してきました。「Bの環境でAを利用するためにBで包み込む」という意味で、この場合はPOPやSMTPをSSL/TLSの環境で利用できるようにトンネリング(カプセル化)したということになります。(トンネリングについては、IPアドレスとは(3) を参照してください)
SSL/TSLの仕組みは次項から詳しく学習していきますが、簡単に言えば、
2地点間の経路を暗号化する仕組み
です。
経路の暗号化とは、特定のデータやファイルを個別に暗号化するのではなく、定められた区間において、そこを通過するデータ(パケット)をすべて暗号化するという仕組みです。つまり、ローカルホストとメールサーバ間の通信がすべて暗号化されます。
ただし、IPアドレスとは(3) で学習のとおり、パケットのうち伝送に必要なヘッダ情報(IPヘッダとTCPヘッダ)は暗号化されません。それ以外の中身(ペイロード)が暗号化されます。(IPsecではヘッダ情報も暗号化されて付け替えられます)
トンネリングによってSMTPとPOPでこの暗号化方式を利用することができますが、厳密に言えば、パケットのIPヘッダとTCPヘッダのみが暗号化されず、電子メールのヘッダ部分(From、To、Subjectなど)は暗号化されているということで、電子メールのヘッダ部分の大半は暗号化されて通信されます。
これは、双方でSSL/TLSによる暗号化通信のコネクションを確立してから両端の機器もしくはソフトウェアを通じて行います。そのため、そこを通過するパケットがすべて暗号化されるということですが、SMTPSやPOP3Sは、特定のメールプロトコルをSSL/TLSで包んだ通信形態であり、SMTPとPOP通信にしか使えません。(コネクションについては、TCP/IPとは を参照してください)
例えば、HTTPではHTTPS、FTPではSFTPがあるように、その適用はプロトコルごとに別々に行われます。したがって、実際にすべてのパケットを暗号化しようとすると、アプリケーション層より下位のネットワーク層やトランスポート層で暗号化する仕組みが必要になりますが、これについては、VPNとは で詳しく学習します。
またIMAPの場合は、「IMAP over SSL/TLS(ポップ・オーバー・エスエスエル/ティーエスエス)」となり「IMAPS(アイマップエス)」と呼ばれています。
POP3Sのポートは「995番」、SMTPSのポートは「465番」を使うのが一般的です。
下図はOutlookの設定画面です。

契約しているプロバイダ等のメールサーバと使用しているメーラーが対応している必要がありますが、POPサーバとSMTPサーバともにウェルノウンポートを指定し、SSL/TLSを使用して暗号化接続する設定になっています。
こうしてSMTP-AUTHを補完し、パスワードもメール本文も暗号化することができるようになりました。
STARTTLS
また、SMTPSやPOP3S、IMAPSに加えて「STARTTLS(スタート・ティーエルエス」)という技術も登場しました。
これも「TLS」の文字があるとおり、SSL/TLSによる暗号通信を行う方式です。TLSはSSLの後継規格のことで、実質的に現在ではすべてTLSになっています。(SSLのほうが有名なためTLSを指してSSLを呼ばれることが多いです)
したがって、同様にTLSでカプセル化して暗号化通信を行う仕組みですが、動作がまったく異なります。
どういうことかと言うと、
平文の通信を途中から暗号化通信に切り替える
という動作になります。
つまり、SMTPSやPOP3Sのように「最初から」カプセル化して暗号化通信を行うのではなく、最初の通信は平文のSMTPやPOPで行い「途中から」TLSに切り替えるということです。
そのため、通信規格としては異なりますが、暗号化の仕組みは同じものと言えます。と言っても、途中からSMTPSやPOP3Sに切り替わるわけではありません。同じTLSで暗号化されているということです。
では、なぜ途中から切り替えるのかということですが、そもそも、SMTPSやPOP3Sは暗号化通信のコネクションが確立してから通信を始めます。そのため、通信相手がSMTPSやPOP3Sに対応している必要があります。
STARTTLSは、平文通信のプロトコル(SMTP、POP3、IMAP)に後からセキュリティ機能を追加するために作られました。既存の平文プロトコルをそのまま使い、暗号化を追加できる設計になっています。
具体的には、SMTPサーバがSTARTTLSに対応しているかどうかの確認を通常のSMTP通信(平文)で行い、対応していることが確認できたら、その後の通信はTLSによる暗号化通信を行うというものです。
これらを自動的に行う仕組みで、対応していなければ、平文のまま通信します。STARTTLSのSTARTは「最初は平文で通信」することを意味します。
STARTTLSによって、既存の平文の通信環境をそのまま使い続けることが可能になり、双方での設定が容易(または設定変更が最小限)になりました。
また、SMTPSやPOP3Sでは、暗号化通信を確立するための専用ポートが必要になりますが、STARTTLSでは「25」や「587」をそのまま使うことができるというメリットがあります。(企業のLANなどでセキュリティ機器に対して新しいポートを開放する設定が不要になります)
STARTTLSは、SMTPだけでなくPOPやIMAPでも利用できますが、SMTPでもっともよく利用されており、現在の標準的な暗号化手段になっています。
ただし、暗号化通信を開始する前の平文の通信を盗聴されるリスクがあること、専用ポートがないために、暗号化通信が行われているのか、平文で通信されているのかの判断ができないというデメリットもあります。
こうして現在では、SMTP-AUTH、POP3S、SMTPS、STARTTLSが混在した状態になっています。
プロバイダによって、
SMTP:SMTP-AUTH+STARTTLS(ポート587、平文SMTP→TLSに切替)
またはSMTP-AUTH+SMTPS(ポート465、最初からTLSセッション)
POP:POP3S
といった組み合せが一般的となっています。

さて、これでようやく電子メールを誰もが安全にやり取りできるようになったと言えそうですが、はたしてどうでしょうか?
じつは、これでもまだ十分ではないのです。なぜなら、
相手のローカルホストまでのすべての経路が暗号化されている保証はない
からです。
確かに、送信者のメーラーと送信者のメールサーバまでのやり取りはTLSによって暗号化されています。しかし、そこから先の経路で暗号化通信が行われている保証はどこにもありません。
どういうことかと言うと、自分のサーバから送信相手のサーバまでの転送経路、また送信相手のサーバからローカルホストまでの経路が暗号化されているかどうかはわからないということです。つまり、サーバ同士の通信や送信相手がPOP3S、IMAPS、STARTTLSを利用しているかどうかは送信者にはわかりません。
インターネット上には古いレガシーシステムにしか対応していないサーバや機器が混在している可能性があり、相手の手元に届くまでのどこかの経路で暗号化に対応していない区間があれば、それは安全とは言えないのです。
では、インターネット上のすべての経路を暗号化しなければならないのかと言うと、そういうわけではありません。
特定の経路ではなく電子メールを暗号化したまま相手に届ければよい
ということです。
つまり、経路にこだわらず、暗号化した電子メールをそのまま相手まで届けて、相手側で復号化してもらうということです。この方法であれば、途中で盗み見されたとしても暗号文を盗み見されるだけで解読は不可能です。暗号化を施すトンネルを必ずしも通過させる必要もなくなります。
考えてみればそのとおりと言えますが、なかなかこの方法はハードルが高いのです。なぜなら、暗号文を復号化する「鍵」を相手に渡しておかなければならないからです。STARTTLSのようにすべて自動的にやってくれるわけではありません。
それを理解するために、まずは次項から、暗号通信の基礎をじっくりと学習していきましょう。
更新履歴
- 2008年11月24日
- ページを公開。
- 2009年5月19日
- ページをXHTML1.0とCSS2.1で、Web標準化。レイアウト変更。
- 2018年1月30日
- ページをSSL化によりHTTPSに対応。
- 2025年6月16日
- 内容修正。
著者プロフィール
YAMANJO(やまんじょ)
- 経歴
- 岡山県出身、1980年生まれ(申年)の♂です。現在、総合病院で電子カルテなどの情報システム担当SEとして勤務。医療情報学が専門ですが、ネットワーク保守からプリンタの紙詰まり、救急車の運転手までこなしています。
- 医療情報技師、日本DMAT隊員。ITパスポート、シスアドなど、資格もろもろ。
- 趣味は近所の大衆居酒屋で飲むこと、作曲(ボカロP)、ダイビング。
- 関連リンク
- 詳細なプロフィールはこちら
- 作成したボカロ曲などはYoutubeへ
- X(Twitter)
