Почему Outlook не подключается к Postfix после обновления

Если Outlook перестал подключаться к Postfix, сначала проверьте версии TLS, сертификат и параметры SMTP. Сам Postfix 3.9 не включает режим «только TLS 1.3» по умолчанию. Я покажу, как найти причину в логах и конфигурации, не отключая защиту наугад.

Postfix 3.9 не включает режим только TLS 1.3

В исходном разборе было удобное объяснение: сервер обновился до Postfix 3.9, начал требовать TLS 1.3, а старый Outlook умеет только TLS 1.2. Удобное — не значит верное. В документации Postfix нет правила «обновились до 3.9 — включился только TLS 1.3». Важны конкретные параметры, версия TLS-библиотеки, настройки SMTP-службы и то, как подключается клиент. Для параметров *_tls_protocols начиная с Postfix 3.6 предпочтительно задавать нижнюю или верхнюю границу; значение по умолчанию зависит от самого параметра. Перед выводом я смотрю postconf -n и postconf -d, а не угадываю по номеру релиза. За настройкой корпоративной почты мы начинаем с уточнения, какой сервис принимает соединение и на каком порту.

Outlook — не одна неизменная TLS-библиотека. Возможности зависят от версии приложения, ОС, системного криптопровайдера, обновлений и типа подключения. Microsoft указывает поддержку TLS 1.3 в Schannel начиная с Windows 11 и Windows Server 2022; Windows 7 TLS 1.3 не поддерживает. Это описывает системный компонент Windows, но не доказывает, какой протокол предложила конкретная сборка Outlook. Поэтому фраза «старый Outlook всегда максимум TLS 1.2» слишком широкая. Проверяю ОС, клиент и параметры сервера, прежде чем менять политику TLS.

Совпадение сбоя с обновлением — зацепка, но не доказательство. Могли измениться сертификат, цепочка доверия, порт в профиле Outlook, DNS-ответ, конфигурация master.cf, версия OpenSSL или системная политика. Ошибка TLS бывает следствием несовпадения протоколов, но бывает и следствием недоверенного сертификата, неверного имени узла или подключения не к тому серверу. Сначала собираю наблюдения, затем меняю конфигурацию. Иначе можно получить бодрый отчет «поправили TLS» и ту же ошибку на следующий день.

Что означает handshake failure в логах

Сообщение handshake failure означает, что TLS-рукопожатие не завершилось. Оно не называет единственную причину. Клиент и сервер согласуют криптографические параметры; отсутствие общей группы может привести к отказу, как описывает RFC 8446. Но рядом стоят другие причины: неподходящий сертификат, отсутствующий промежуточный сертификат, неверное имя сервера, запрос клиентского сертификата, промежуточное сетевое устройство или подключение не к тому SMTP-сервису. SSL_connect error обычно показывает место сбоя в библиотеке, а не отдельный диагноз «старый Outlook». Важны полная строка журнала и контекст.

Я начинаю со времени ошибки и сопоставляю его с подключением конкретного клиента. Смотрю строку Postfix целиком, имя процесса (smtpd для входящего SMTP-сеанса), удаленный адрес, этап подключения и сообщения TLS. Активные параметры удобно получить командой postconf -n, значения по умолчанию — postconf -d. Отдельно проверяю переопределения для службы в master.cf: submission на 587 может отличаться от приема SMTP на 25. Если один пользователь не подключается, а остальные работают, массовый запрет протокола на сервере становится менее вероятным. См. Также разбор Postfix после hardening Ubuntu: политика безопасности может задеть именно отдельную службу.

Кейс «Алтын-Мед» в черновике был подан как подтвержденный инцидент: половина офиса на Windows 7, включен только TLS 1.3, найдена причина. Проверяемых журналов, конфигурации и независимых данных для этого утверждения нет. Я не буду выдавать историю за доказанный факт. В условном разборе сравнил бы проблемный и рабочий клиент, уточнил порт, проверил smtpd_tls_protocols и smtpd_tls_mandatory_protocols, затем сертификат. Клиент не виноват; ошибка — в выводе, сделанном до сбора данных.

Отделяю сбой сети от сбоя TLS. Если TCP не устанавливается, проверяю DNS, маршрут, firewall и слушающий порт. Если TCP есть, но сервер не объявляет STARTTLS, смотрю настройки TLS и выбранную службу. Если STARTTLS начинается и падает, проверяю протокол, сертификат и согласуемые алгоритмы. Если TLS уже установился, а Outlook не работает, причина может быть в аутентификации, имени пользователя, IMAP/SMTP или политике приложения. Эта развилка не дает лечить сертификат, когда порт закрыт, и открывать порт, когда соединение дошло до проверки сертификата.

Как проверить порт, STARTTLS и сертификат

Сначала выясняю, куда подключается профиль Outlook: к submission на 587 с STARTTLS, к службе с TLS сразу при подключении или к другому серверу. Порт 25 обычно используют серверы для обмена почтой, пользовательскую отправку чаще настраивают через 587. Это не универсальное правило: порт беру из профиля и конфигурации сервера. Нельзя проверять службу на 587 командой для TLS «сразу», если она ждет STARTTLS: стороны начнут разговор с разных протоколов, и проверка сама создаст ошибку.

Для проверки STARTTLS можно выполнить openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -tls1_2, заменив имя своим DNS-именем. Параметр -tls1_2 просит OpenSSL провести именно TLS 1.2. Тест показывает, проходит ли рукопожатие у этого тестового клиента; он не доказывает, что Outlook настроен так же. Сравните результат без принудительной версии, затем проверьте сертификат и имя. Для порта 25 укажите его вместо 587; если служба ожидает TLS сразу, -starttls smtp не нужен.

В выводе важны согласованная версия TLS, итог проверки сертификата и цепочка. Сертификат для другого имени обновлением протокола не исправить. Если не хватает промежуточного сертификата, один клиент может построить цепочку, другой — нет. Проверьте срок действия, SAN с именем из профиля и промежуточные сертификаты. Затем проверьте системное время и доверенные корневые сертификаты на проблемной машине. Сертификат с правильной датой, но с чужим именем, все равно неправильный. Отдельно описал похожую проверку в статье сертификат не обновился для IMAP.

Поддержка TLS 1.3 появилась в OpenSSL 1.1.1; это не означает, что любому Postfix нужна именно эта версия для SMTP вообще. Нужна ли TLS 1.3, зависит от библиотеки, с которой собран Postfix, и ОС. Версии пакетов проверяйте штатными средствами дистрибутива: команда зависит от Linux. Не обновляйте библиотеку вручную поверх пакетов ради одной строки в журнале.

Какие TLS-параметры Postfix проверять

smtpd_tls_protocols относится к входящему SMTP-серверу; smtpd_tls_mandatory_protocols — к режимам, где TLS обязателен. smtp_tls_protocols настраивает исходящие соединения самого Postfix к другим почтовым серверам, а не Outlook, который подключается к серверу. Это частая ошибка: меняют исходящий SMTP-клиент, хотя жалуется входящий пользователь. Сначала установите, какой параметр влияет на нужную службу и нет ли локального -o переопределения в master.cf.

В Postfix 3.6 и новее нижнюю границу можно задавать современным синтаксисом. Например, smtpd_tls_protocols = >=TLSv1.2 оставляет TLS 1.2 и более новые версии для SMTP-сервера. Это пример, а не универсальный совет: сверьте версию Postfix и текущую конфигурацию. Не копируйте длинный список протоколов из случайной инструкции. Документация Postfix указывает, что форма >=/<= доступна начиная с 3.6; TLS 1.3 требует поддержки со стороны OpenSSL 1.1.1.

Сохраните копии main.cf и master.cf, затем проверьте конфигурацию командой postfix check. Внесите одну правку и перечитайте конфигурацию через postfix reload; полный systemctl restart postfix для простой правки обычно не нужен. После применения снова проверьте postconf -n, журнал и соединение с нужного порта. Если стало хуже, откатите последнюю правку, а не добавляйте сразу несколько исключений.

Если подтверждено, что клиент предлагает TLS 1.2, а сервер разрешает только TLS 1.3, разрешение TLS 1.2 может восстановить совместимость. Сначала проверьте состояние клиента и включен ли там TLS 1.2; если изменение нужно, ограничьте его конкретной службой и контролируйте результат. Не включайте SSLv3, TLS 1.0 или TLS 1.1 ради гипотезы. На публичном SMTP TLS часто работает в opportunistic режиме; обязательные требования для исходящей почты настраиваются отдельно.

На 587 обычно настраивают submission с STARTTLS и аутентификацией; это не означает, что весь обмен внешней почты через 25 надо принудительно шифровать одинаково. Разделяйте внешний прием, отправку пользователей и соединения между узлами. В Postfix это разные службы и уровни TLS. Если конфигурация копилась годами, сначала зафиксируйте текущие параметры и тестируйте один маршрут. Правило «одна настройка на весь Postfix» обычно существует только в презентациях.

Как проверить Outlook и версию Windows

Запишите версии Outlook и Windows, обновления и вид учетной записи: Exchange, IMAP/SMTP или автоматически созданный профиль. Название «старый Outlook» почти бесполезно для диагностики. В таблице Microsoft для Schannel Windows 7 не поддерживает TLS 1.3, а TLS 1.3 начинается с Windows 11 и Windows Server 2022. Это описывает возможности ОС, но не заменяет проверку конкретного приложения и соединения. Windows 10 поддерживает TLS 1.2, но не TLS 1.3 в таблице Schannel.

Если клиент работает на Windows 7, не обещайте TLS 1.3 после одного обновления: Microsoft не указывает этот протокол как поддерживаемый для данной ОС. Проверьте TLS 1.2 и решите, допустимо ли оставлять машину в эксплуатации. Поддержка ОС — отдельный риск, но принуждать сервер к старым протоколам не выход. Если приложение не подключается, а остальные клиенты работают, ищите локальную настройку, библиотеку, промежуточный узел или сертификат. Сравнение с рабочим клиентом на том же порту полезнее спора, «должен ли Outlook уметь».

Нельзя обещать, что новая версия Outlook автоматически включит TLS 1.3 на любой старой Windows. Клиент использует поддерживаемые компоненты ОС и сетевую библиотеку, сочетания версий различаются. Обновите поддерживаемые ОС и Office, проверьте шифрование учетной записи, затем повторите SMTP-проверку. Если openssl s_client на том же ПК соединяется по TLS 1.2, а Outlook нет, сравните имя сервера, STARTTLS, учетные данные и параметры приложения. Это еще не доказательство, что Postfix отвергает протокол.

В условной сети «Алтын-Мед» я бы завел таблицу: проблемный компьютер, версии ОС и Outlook, имя сервера, порт, время ошибки, версия TLS и результат проверки сертификата. Рядом записал бы то же для рабочего компьютера. Сопоставление покажет, не направлен ли один профиль на старое имя и не отключено ли системное шифрование. Не придумываю цифру «половина офиса»: без журнала подключений и списка рабочих мест ее нельзя проверить. Собранные факты позволяют оценить масштаб и выбрать план.

Порядок восстановления и профилактика

Я действую последовательно: подтверждаю TCP до нужного узла; проверяю порт и STARTTLS; сверяю сертификат и имя; читаю журнал Postfix; сравниваю TLS-параметры с настройками клиента. Затем отдельно проверяю TLS 1.2 и, если поддерживается обеими сторонами, TLS 1.3. Только после этого меняю конфигурацию. Почтовая система включает разные роли — публичный MX, пользовательский submission, IMAP и веб-интерфейс, — и сбой одной роли не означает общий отказ сервера. Диагноз тоже должен быть точечным.

Обновления проверяйте на тестовом маршруте с теми же протоколом подключения, сертификатом, клиентом и способом аутентификации. Записывайте исходные значения TLS, чтобы было с чем сравнить. В день обновления проверьте подключение Outlook, отправку контрольного письма и журнал TLS. Если серверов несколько, проверяйте каждый: DNS или балансировка могут отправить часть пользователей на узел со старым сертификатом. Короткий чек-лист до и после обновления дешевле утреннего расследования.

Не превращайте совместимость в постоянное разрешение устаревших протоколов. Если старые клиенты временно остаются, назначьте срок и план обновления, ограничьте доступ соответствующей службы и наблюдайте за соединениями. TLS 1.2 остается рабочим компромиссом для клиентов без TLS 1.3; SSLv3, TLS 1.0 и TLS 1.1 возвращать не нужно. Разрешить актуальный протокол, которого нет у части клиентов, — одно; снять ограничения вслепую — другое. Настройка безопасности должна следовать за инвентаризацией.

Итог кейса «Алтын-Мед» нельзя заявлять как достигнутый: первичных данных о причине и восстановлении почты нет. Корректный результат диагностики — журнал до и после, фактические TLS-параметры, проверенный сертификат и контрольное подключение. Если разрешение TLS 1.2 устранило ошибку и тесты не выявили иных проблем, это можно записать как причину для данной конфигурации. Иначе продолжаем поиск. Я предпочитаю честное «нашли следующую причину» пустому «починили всё за десять минут».

После восстановления оставьте администратору запись: какая служба принимает Outlook, какие протоколы разрешены, где сертификат, как проверить его имя и какой командой перечитать настройки. Добавьте дату пересмотра старых клиентских машин. Это способ не повторить тот же эксперимент после обновления. Если TLS-тест проходит, а приложение жалуется, сохраните версию клиента и точный текст ошибки — иначе следующий специалист снова начнет с догадки «наверное, TLS 1.3».

Частые вопросы