この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
ただ、見出しの「Outlookのバグ」という言い方には注意がいります。今回起きたことの本質は、Dovecot 2.4が「暗号化されていない接続での平文認証」を既定で拒否するようになった設定既定の変更です。Outlook側が、SSLを有効にしているつもりでも黙って平文ポート（POP3:110）へ繋ぎにいっていた古い挙動が、Dovecotの厳格化によって露呈しただけ。順序を取り違えると、原因の切り分けも対処も間違えます。
20年以上Linuxサーバーの現場にいますが、これは「ディストリのメジャーアップグレードでミドルウェアの既定が変わる」典型例です。受講生にも繰り返し伝えてきたテーマなので、現役のメールサーバ管理者がこの種の地雷をどう検証・回避するか、運用目線で1本まとめます。
この記事のポイント
- 本質はOutlookのバグではなく、Dovecot 2.4が非暗号接続での平文認証を既定で拒否するようになった設定既定の変更。CVE（脆弱性）ではない。
- Dovecot側ログに出るのは
-ERR [AUTH] Cleartext authentication disallowed on non-secure (SSL/TLS) connections.系のエラー。 - Outlookは設定でSSLを選んでいても、黙って平文ポート110へ接続していた。この挙動はOutlook 2007を含め約20年前から存在。
- 正しい対応はクライアントを暗号ポート（POP3S:995／IMAPS:993）＋SSL必須に直すこと。Dovecot側で平文を許す設定に戻すのは暫定・非推奨。
- Dovecot 2.4は設定キー名・既定が大きく変わる。
disable_plaintext_authはauth_allow_cleartextへ。本番投入前のステージング検証とdoveconf -n差分確認が必須。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
何が起きたか – Fedora 43のDovecot 2.4で受信不能
アップグレード当日に「メールが落ちた」
発端はFedora Server 42から43へのアップグレード（2026年5月27日前後、Fedora 42のEOLにあわせた更新）です。Fedora 43では同梱のDovecotが2.4系に上がりました。アップグレード自体は正常終了し、サーバも問題なく立ち上がる。ところがその直後から、Outlookを使っている利用者がメールを受信できなくなった、という流れです。ここで大事なのは、サーバの障害でもネットワークの障害でもない点です。Dovecotは正常に起動して待ち受けています。落ちているのは「平文認証で繋ごうとしたクライアントの認証だけ」。だからこそ「メールサーバは動いているのに特定クライアントだけ受信できない」というねじれた症状になります。
# Dovecot側ログに出る代表的なエラー（fedoramagazine掲載の原文） -ERR [AUTH] Cleartext authentication disallowed on non-secure (SSL/TLS) connections.
これはCVEではない、という切り分け
最初に明確にしておきます。これはCVE（脆弱性）ではありません。Dovecotがバグを踏んだわけでも、セキュリティホールが見つかったわけでもない。2.4でセキュリティを強める方向に既定を変えた、その仕様変更の結果です。Microsoftも、このOutlookの挙動を公式に脆弱性として認めてはいません。「設計上の挙動」という見方も成り立ちます。煽らずに言えば、長年放置されていたOutlookの古い挙動が、Dovecotの厳格化という外圧によって表に出てきた、という構図です。どちらか一方を「悪者」にして終わる話ではなく、メールサーバ管理者としては「自分の環境で同じことが起きないか」を淡々と点検するのが筋です。
Dovecot 2.4で何が変わったのか
非暗号接続での平文認証を既定で拒否
Dovecot 2.4系の大きな変更点が、平文認証（PLAINなどの平文パスワード）を、暗号化されていない接続では既定で許可しないことです。2.3系まではディストリやデフォルト設定によっては平文ポートでの認証がそのまま通る環境もありました。2.4はそこを締めた、と理解すれば大筋を外しません。平文認証を非暗号接続で許可するかどうかは、Dovecotの
auth_allow_cleartextという設定で制御します。2.4ではこれが既定でオフ（許可しない）です。2.3系で使われていたdisable_plaintext_authという設定キーが、2.4ではauth_allow_cleartextへ置き換わっており、意味が反転している点に注意がいります（disable_plaintext_auth=yes は auth_allow_cleartext=no に相当）。設定キー名と既定が広く変わる
今回の平文認証だけでなく、Dovecot 2.4は設定ファイルの構文・キー名がかなり変わっています。本番に当てる前に押さえておきたい主な変更を挙げます。| 項目 | 2.3系 | 2.4系 |
|---|---|---|
| 非暗号での平文認証 | disable_plaintext_auth |
auth_allow_cleartext（既定で許可しない） |
| SSL証明書 | ssl_cert |
ssl_server_cert_file |
| SSL秘密鍵 | ssl_key |
ssl_server_key_file |
| サーバ優先暗号 | ssl_prefer_server_ciphers |
ssl_server_prefer_ciphers |
| 設定バージョン宣言 | — | dovecot_config_version（先頭で必須） |
特に2.4では
dovecot.confの先頭にdovecot_config_versionを書くことが必須になりました。証明書の指定も、2.3系で書いていた行頭の「<」（ファイル読み込み記号）を外す必要があります。2.3系の設定ファイルをそのまま2.4に持っていっても、構文段階で弾かれる、もしくは意図しない既定で動く、という事故が起きます。Dovecotは設定変換を補助するオンラインツール（dovecot.org/upgrader/）も用意していますが、変換後のdoveconf -nでの目視確認は省けません。PR / メールサーバの土台を押さえ直したい方へ
Postfix実践入門 清水 正人 / 技術評論社
PostfixとDovecotを組み合わせたメールサーバ運用では、SMTPとPOP/IMAPの役割分担、ポートと暗号化の関係を腹落ちさせておくことが事故防止に直結します。Dovecot 2.4の平文認証厳格化を「なぜそうなっているか」から理解する土台になる一冊です。
なぜOutlookで顕在化したのか
SSLを選んでいるのに平文ポート110へ繋いでいた
ここが今回の肝です。問題のOutlookは、アカウント設定でSSL/TLSを有効にしていたにもかかわらず、その設定を黙って無視し、暗号化されていないPOP3の110番ポートへ接続していました。利用者には何の警告も出ません。本人は「SSLで繋いでいる」と思っているのに、実際の通信は平文だった、ということです。2.3系のDovecot（あるいは平文認証を許す設定）であれば、この食い違いがあっても認証は通ってしまうので、誰も気づきません。長年「動いているから問題ない」とされてきました。2.4で非暗号接続の平文認証が既定拒否になった瞬間、この食い違いが認証エラーとして表面化した、という順序です。
この挙動は約20年前から存在していた
報じられたところでは、このOutlookの挙動はOutlook 2007を含め約20年前から存在していたとされます。つまり今回新しく壊れたのではなく、ずっと平文で繋いでいたものが、サーバ側の厳格化で初めて見えるようになっただけです。セキュリティの観点で言えば、これはむしろ「今まで気づかずに平文でパスワードを流していた」ことが分かったわけで、Dovecotの厳格化はそれを止めてくれた、と捉えるのが健全です。「受信できなくなった」を障害として元に戻すのではなく、「平文で流していた事実」を直す方向に持っていくのが、管理者として正しい判断になります。
管理者の検証手順 – doveconf -nとopenssl s_client
アップグレード前にステージングで差分を取る
メジャーアップグレードでミドルウェアの既定が変わるリスクは、本番に当てる前にステージングで掴むのが鉄則です。Dovecotの場合はdoveconf -nで「実際にDovecotがどう設定を解釈しているか」を出力し、2.3時点と2.4時点で差分を取ります。# アップグレード前（2.3時点）に現行設定の解釈結果を保存 $ doveconf -n > /tmp/dovecot-2.3.conf # Dovecotのバージョン確認 $ dovecot --version $ doveconf -n | grep -E "auth_allow_cleartext|disable_plaintext_auth|ssl" # アップグレード後（2.4時点）に再取得して差分を見る $ doveconf -n > /tmp/dovecot-2.4.conf $ diff -u /tmp/dovecot-2.3.conf /tmp/dovecot-2.4.conf
auth_allow_cleartextが既定で許可しない側に倒れているので、ここを意図して許すのか拒否するのかをはっきりさせます。暗号接続と平文拒否をopensslで実測する
設定を読むだけでなく、実際にポートへ繋いで挙動を確かめます。openssl s_clientでPOP3S/IMAPSの暗号接続が成立するか、平文ポートで認証が拒否されるかを実測します。# POP3S(995)へ暗号接続できるか $ openssl s_client -connect mail.example.jp:995 -quiet # IMAPS(993)へ暗号接続できるか $ openssl s_client -connect mail.example.jp:993 -quiet # POP3(110)でSTARTTLS前に平文認証が拒否されるか $ openssl s_client -connect mail.example.jp:110 -starttls pop3 # 平文ポートで素のtelnet的に繋いで拒否メッセージを確認 $ openssl s_client -connect mail.example.jp:110 # USER/PASS送信前に Cleartext authentication disallowed が返るかを見る
正しい対応と暫定回避 – クライアントを995/993へ
本筋はクライアントを暗号ポート＋SSL必須に直す
正しい対応は、メールクライアント側を暗号ポートに直し、SSL/TLSを必須にすることです。優先順位ははっきりしています。- POP3利用なら、受信ポートを995（POP3S）にしてSSL/TLSを有効化。110のままSSLにチェックを入れていても、今回のように無視される個体があるので、ポート番号も995へ明示的に変える。
- IMAP利用なら、受信ポートを993（IMAPS）にしてSSL/TLSを有効化。
- STARTTLS方式（110/143から暗号化に昇格）を使う構成もあるが、クライアントが確実にSTARTTLSを実行する保証が取りにくいなら、最初から暗号専用ポート（995/993）に寄せる方が事故が少ない。
要は「平文で繋いでいた事実」を直すのが目的なので、ポートと暗号化の両方をクライアント側で正しく設定し直すのがゴールです。サーバ側を緩めて元に戻すのは、本筋ではありません。
暫定回避は非推奨、やるなら条件付き
どうしてもクライアントをすぐ直せず、業務メールが止まって困る場合、Dovecot側で非暗号接続の平文認証を一時的に許す選択肢は残っています。ただしこれは非推奨です。やむを得ず使うなら条件を切ります。- LAN内・閉じたネットワーク限定にとどめ、インターネットに面した経路では絶対に開けない。
- 「クライアント設定を995/993へ直すまでの数日間」という期限を区切った暫定措置として扱い、剥がす日を決めておく。
- 暫定で許している間も、平文で流れているパスワードは漏えいリスクがある前提で運用する。
Dovecot 2.4で平文認証を許すには
auth_allow_cleartextを許可側に設定することになりますが、これは「セキュリティを下げる方向の操作」だと自覚した上で、上記の条件を満たすときだけにとどめます。煽るつもりはありませんが、本来直すべきはクライアント側であって、サーバ側を緩めるのは応急処置にすぎません。
メジャーアップグレード一般の教訓
ディストリのメジャー更新は既定変更を伴う
今回いちばん持ち帰ってほしいのは、個別のDovecotの話を超えた一般論です。ディストリビューションのメジャーアップグレードは、同梱ミドルウェアの「既定値」の変更を伴う。バージョンが上がるだけでなく、安全側・厳格側へ既定が動くことがよくあります。今回のDovecotの平文認証拒否はその典型でした。特にFedoraは更新サイクルが短く、新しいバージョンのミドルウェアを早く取り込みます。Dovecotに限らず、Apache（httpd）やPHP、systemd、暗号ライブラリの既定など、メジャー更新のたびに「前は通っていた構成が通らなくなる」場面を踏みやすいディストリです。だからこそ、本番に当てる前のステージング検証とリリースノート・移行ガイドの確読を、儀式としてではなく実作業として1本通す必要があります。
本番投入前に通すべきチェックリスト
今回の件を一般化した、メジャーアップグレード前のチェックリストです。- リリースノートと移行ガイドを先に読む: 「既定が変わる」「設定キーが変わる」と書いてある箇所を最優先で拾う。Dovecotなら2.3→2.4移行ガイドの平文認証・SSLの項。
- ステージングで現状の設定解釈を保存:
doveconf -nのような「実際の解釈」を出すコマンドで、アップグレード前後の差分を取る。 - 暗号接続・認証を実測:
openssl s_clientでポートと暗号化を実機確認。設定ファイルの読みだけで判断しない。 - クライアント側の設定も棚卸し: サーバを締めるなら、繋いでくるクライアントが暗号ポート・SSL必須になっているかを事前に点検。今回のように「SSLにチェックは入っているが実は平文」を炙り出す。
- 切り戻し条件と期限を決める: 暫定で緩める場合も、剥がす日と条件を先に決めてから当てる。
メールサーバ運用・Dovecot/Postfixの役割分担・SSL/TLSの基礎は、こういう場面で確実に効いてくる地力です。今回の「Outlookのバグ」騒動も、土台が分かっていれば「Dovecotの既定が締まった、クライアントを直そう」と即断できます。逆に土台があやふやだと、サーバを緩めて元に戻して、平文のまま運用を続けてしまう。差が出るのはまさにここです。
参考
- gihyo.jp「FedoraをアップグレードしたらOutlookのバグを発見した件」: https://gihyo.jp/article/2026/06/daily-linux-260610
- Fedora Magazine「Fedora 43 Upgrade revealed 20 years old Outlook Security Bug」: https://fedoramagazine.org/fedora-43-upgrade-revealed-20-years-old-outlook-security-bug/
- Dovecot 公式 2.3→2.4 アップグレードガイド: https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html
- Fedora Project Wiki Changes/Dovecot2.4: https://fedoraproject.org/wiki/Changes/Dovecot2.4
PR / あわせて読みたい本
- Postfix実践入門 清水 正人 / 技術評論社
- Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本 中島 能和 / 翔泳社
メールサーバの仕組みと、SSL/TLSを含むサーバ防衛の基本を両輪で押さえる2冊。Dovecotの平文認証厳格化のような「既定が締まる」変更を、慌てずに正しい方向へ対処するための背景知識になります。
ディストリのメジャーアップグレード、既定変更を踏んでも自分で切り分けられますか？
doveconf -n の差分、openssl s_client での暗号接続テスト、クライアントのポートとSSL設定の棚卸し。今回のDovecot 2.4の件も、メールサーバとSSL/TLSの基礎があれば「サーバを緩める」ではなく「クライアントを直す」と即断できます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Rocky Linuxの商用サポート「RLC Pro」国内販売開始｜エクセルソフトがCIQ代理店に、無償版との違いと選び方
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます