Postfix 3.10: обновления, TLSRPT и путь к версии 3.11

Правильное определение даты выпуска Postfix 3.10

На момент проведения исследования, 20 октября 2026 года, Postfix 3.10 не является текущей стабильной ветвью разработки: эту роль занимает Postfix 3.11. Разработчик указывает версию 3.10 как Ветвь Legacy, но продолжает выпускать для него исправления ошибок и уязвимостей. В официальных объявлениях Postfix 3.10.14 от 7 сентября 2026 года указан как последний доступный патч этой ветки.

Эта классификация разграничивает два разных вида обновлений. Обновление для обслуживания, например, с версии 3.10.8 до более новой версии 3.10 с исправлениями, сохраняет выбранную ветвь функциональности и включает в себя соответствующие исправления. Обновление до версии 3.11, напротив, влечет за собой смену ветки разработки и поэтому требует проверки на предмет изменений в функциональности, совместимости конфигураций, расширений и рабочих процессов. Переход на более позднюю версию основной или второстепенной ветки не всегда является подходящим решением для каждой производственной системы.

При работе с пакетами Linux, помимо указанной версии Postfix, проверьте метаданные пакета, журнал изменений и рекомендации по безопасности, предоставленные разработчиком операционной системы. Уточните там, какие исправления содержит данный конкретный пакет и документирует ли разработчик бэкпорты. В то же время объявление разработчика описывает выпуск Postfix и не свидетельствует об общей политике дистрибутива в отношении бэкпортов.

Для планирования технического обслуживания это означает: сначала задокументируйте версию установленного пакета, канал репозитория и локальные настройки. Затем сравните, какие исправления для этого пакета указывает поставщик операционной системы. Только это сравнение покажет, есть ли невыполненное Обновление Postfix требуется ли переход на версию 3.10 или же запланированный переход на версию 3.11 принесет дополнительную техническую выгоду. Пункт 3.10.14 является ориентиром на верхнем уровне, а не инструкцией по установке для конкретной системы Linux.

Роль MTA, порты SMTP и системные ограничения

Postfix — это Агент передачи почты (MTA). Он принимает электронные письма по протоколу SMTP, на основе настроек маршрутизации и политик принимает решение о дальнейшей обработке и передает сообщения на другие почтовые серверы или по локальным каналам доставки. Таким образом, Postfix формирует транспортный уровень почтового сервера в системе Linux. Однако его настройки не определяют автоматически, как пользователи просматривают свои почтовые ящики или как оценивается подозрительный контент.

Сервер IMAP или POP3 предоставляет почтовые ящики для почтовых программ и представляет собой отдельный компонент, отличный от SMTP-транспорта. Кроме того, функции Postfix не заменяют полноценного решения для фильтрации спама или вирусов: такие системы необходимо при необходимости правильно подключить, обслуживать и контролировать. Это разделение имеет практическое значение, поскольку успешное прохождение SMTP-теста не подтверждает ни возможность доступа к почтовому ящику, ни качество проверки содержимого.

Порт 25 обычно используется для SMTP-трафика между почтовыми серверами и, следовательно, для работы в режиме публичного MX-сервера. Порты 587 и 465, напротив, предназначены для доставки почты почтовыми клиентами, как правило, с аутентификацией и собственным определением службы. Postfix не только организационно различает эти роли: некоторые настройки не могут или не должны применяться одинаково ко всем SMTP-службам.

Перед внесением изменений вам потребуются права администратора, восстанавливаемая резервная копия конфигурации Postfix и окно технического обслуживания, подходящее с учетом очереди, сроков доставки и подключенных приложений. Кроме того, уточните, осуществляет ли сервер исходящую отправку, принимает ли он почту в качестве общедоступного MX-сервера или предоставляет услугу доставки от имени клиентов. Эти увольнение со службы предотвращает ситуацию, при которой решение по защите данных, обоснованное с точки зрения Submission, случайно изменит общедоступный порт 25.

TLSRPT обеспечивает безопасную доставку электронной почты

Postfix 3.10 предлагает дополнительную поддержку TLSRPT в SMTP-клиенте. Домены могут публиковать через DNS адрес получателя для агрегированных отчетов TLS; RFC 8460 допускает использование как адресов электронной почты, так и HTTPS-конечных точек. При этом Postfix сообщает только об успешном завершении или сбое TLS-рукопожатия, максимум об одном итоговом статусе на каждое SMTP-соединение. Неудачные попытки установления соединения и прерывания до или после TLS-рукопожатия не регистрируются.

Однако сам по себе номер версии 3.10 не доказывает, что установленный пакет Postfix действительно может использовать TLSRPT. Для работы этой функции необходимо, чтобы Postfix был скомпилирован с поддержкой клиентской библиотеки TLSRPT и с опцией сборки USE_TLSRPT был создан. Поэтому перед планированием конфигурации тебе необходимо, опираясь на документацию по пакетам, указанные характеристики сборки и доступные дополнительные пакеты, проверить, поддерживает ли твой дистрибутив эту функцию.

TLSRPT дополняет механизмы, которые фактически влияют на защиту доставки с помощью TLS. STARTTLS позволяет согласовать шифрование на уровне транспорта. DANE использует записи TLSA и для своих допущений о безопасности предполагает наличие DNSSEC; MTA-STS публикует политику, определяющую ожидаемые свойства TLS. Если обязательное требование DANE или MTA-STS не выполняется, TLSRPT может предоставлять последующие уведомления о таких ошибках. Однако он сам не активирует ни шифрование, ни проверку сертификатов.

При этом следует различать две роли. Принимающий домен публикует Конечная точка rua и обеспечивает или поручает обеспечение контролируемого приёма, а также анализ поступающих отчётов. В свою очередь, MTA, отправляющий отчёты, нуждается в правильно настроенном и активированном Postfix, а также в отдельной инфраструктуре, которая собирает, извлекает, агрегирует события и отправляет отчёты. Эти две функции могут быть организационно разделены; владелец домена, публикующий отчёты, не обязан самостоятельно генерировать отчёты TLSRPT на той же системе.

Поэтому плагин политики TLS не всегда входит в каждую цепочку отчетов TLSRPT. Postfix сам поддерживает DANE. Соответствующий плагин становится особенно актуальным в том случае, если отправляющий MTA передает информацию о политике MTA-STS через smtp_tls_policy_maps . Postfix 3.10 дополняет ответы такого плагина атрибутами, связанными с TLSRPT; однако из этого не следует ни то, что для каждой установки требуется плагин, ни то, что TLSRPT входит в состав каждого пакета версии 3.10.

Кроме того, TLSRPT не является системой мониторинга в режиме реального времени. В руководстве по Postfix указано, что в среднем проходит около двенадцати часов до поступления сообщения об ошибке, поэтому отчеты явно не предназначены для мониторинга остро возникающих сбоев. Для решения текущих проблем с доставкой по-прежнему необходимы проверка очередей, анализ журналов и система оповещения. TLSRPT в первую очередь помогает выявить повторяющиеся закономерности и проблемы с политиками на основе множества попыток доставки.

Подготовка обновления Postfix в ветке 3.10

Обновление в рамках Postfix 3.10 представляет собой задачу технического обслуживания с чёткой исходной ситуацией: вы обновляете существующую устаревшую ветвь до версии с исправлениями, предоставляемой вашим дистрибутивом. Перед началом работ сохраните конфигурацию Postfix и запланируйте окно для технического обслуживания. Кроме того, проверьте, обеспечивает ли сервер исходящую доставку, MX-трафик или функцию Submission, поскольку от этого зависят меры контроля и план действий на случай сбоев.

Сначала определите версию Postfix, установленную на вашем компьютере или полученную при запуске программы, и явно зафиксируйте её в main.cf заданные параметры. Первые две команды служат для сбора данных в режиме чтения. postfix check Напротив, это административная команда обслуживания: она, в частности, проверяет права владения и доступа к файлам и каталогам и может создавать отсутствующие каталоги. Поэтому запускайте её с предусмотренными административными правами, а не исходя из предположения, что файловая система гарантированно не изменилась.

postconf mail_version
postconf -n
postfix check

Вывод postconf mail_version указывает версию запущенной программной платформы Postfix. postconf -n отображает параметры с явными name=value-записи в main.cf. Сюда могут входить и настройки, значения которых соответствуют текущим встроенным настройкам по умолчанию; поэтому выводимые данные не являются достоверным доказательством фактического отклонения от значений по умолчанию. Кроме того, после смены версии значения по умолчанию могут измениться, в то время как ранее заданная настройка останется неизменной.

Также postfix check не является полной проверкой конфигурации почтового сервера. Команда может сообщать о проблемах с правами доступа к каталогам или файлам и создавать отсутствующие каталоги, но не проводит всестороннюю оценку технической корректности всех параметров. Цепочки сертификатов, внешние карты, зависимости DNS, фильтры, аутентификация и интеграция подключенных служб должны проверяться отдельно.

Для обновления пакета используйте поддерживаемый в вашей дистрибутиве способ обновления. Проверьте в метаданных пакета, журнале изменений и уведомлениях о безопасности, какие исправления и возможные бэкпорты содержит данный пакет. Сравните эту информацию с объявлениями разработчиков. Не делайте выводов об отсутствии патча, основываясь исключительно на сокращённой версии.

Особое требование по обновлению процессов, описанное в документации Postfix, касается перехода с более старой ветки разработки на Postfix 3.10.0. В связи с изменением внутреннего протокола агента доставки после этого необходимо как минимум postfix reload или требуется остановка с последующим запуском; в противном случае курьеры могут столкнуться с неожиданной smtputf8-Атрибут «предупреждение». Это обоснование нельзя в целом применять ко всем последующим обновлениям в рамках версии 3.10.

При установке обновлений в рамках ветки 3.10 вместо этого проверьте, перезагрузила ли утилита управления пакетами службу в соответствии с требованиями дистрибутива или запустила ли её заново, а также относятся ли запущенные процессы к обновлённой версии. Если это не так, воспользуйтесь функцией перезагрузки или перезапуска, предусмотренной дистрибутивом и пакетом. Затем проверьте очередь и журналы в окне обслуживания, вместо того чтобы предполагать наличие определённой команды активации независимо от поведения пакета.

Планирование TLSRPT с использованием DNS и инфраструктуры отчетности

В TLSRPT необходимо отдельно планировать роль домена-получателя отчетов и роль MTA-отправителя отчетов. Домен, желающий получать отчеты о доставке на свою собственную инфраструктуру, публикует Конечная точка rua в DNS и обеспечивает надлежащее управление их приемом, защитой, хранением и анализом. Таким образом, запись TXT определяет, куда другие отправляющие MTA должны направлять свои сводные отчеты.

MTA, который должен самостоятельно генерировать отчеты TLSRPT, в любом случае нуждается в пакете Postfix, содержащем библиотеку-клиент TLSRPT и USE_TLSRPT была скомпилирована. Указание «Postfix 3.10» лишь подтверждает, начиная с какой ветки доступна данная интеграция; оно не указывает на особенности сборки конкретного бинарного пакета. Поэтому, прежде чем планировать использование этой функции, проверьте документацию по пакету, информацию о сборке и доступные дополнительные пакеты вашего дистрибутива.

На каждой участвующей системе Postfix запускается локальный Коллекционер события, передаваемые подключенной библиотекой TLSRPT через локальный сокет домена Unix. Отдельно от этого могут работать средства сбора данных, централизованная система агрегации и генератор отчетов: они получают собранные данные, формируют предусмотренные сводки и отправляют отчёты на адреса, опубликованные доменами-получателями. Эти нижестоящие компоненты могут быть централизованы на других системах; однако это не позволяет заменить локальный коллектор на соответствующей системе Postfix.

A Плагин политик требуется дополнительно только в определённых сценариях со стороны отправителя. Если MTA использует информацию о политике MTA-STS через smtp_tls_policy_maps, для этого используемый плагин должен поддерживать атрибуты, связанные с TLSRPT. DANE поддерживается самим Postfix. Поэтому ни запись DNS принимающего домена, ни обработка отчетов правильно настроенным MTA не требуют в обязательном порядке использования плагина MTA-STS.

В следующей записи рассматривается исключительно синтаксис DNS для получателя отчета. example.invalid преднамеренно не является продуктивным доменом и не должен использоваться без изменений. Тег v=TLSRPTv1 характеризует данный метод; rua здесь указывается адрес для отправки отчетов. Согласно RFC 8460, помимо электронной почты допускаются также HTTPS-конечные точки.

_smtp._tls.example.invalid. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Для отчетов TLSRPT в Postfix 3.10 описывается заголовок TLS-Required: no, чтобы при передаче отчет мог перейти на уровень безопасности TLS „may“. Это строго ограниченное исключение позволяет избежать ситуации, при которой отчет об ошибке не проходит даже строгую проверку TLS. Оно не является указанием снижать требования TLS для обычной деловой или пользовательской почты.

Защита передачи данных, целенаправленная оценка параметров TLS

Обстановка smtpd_hide_client_session предназначена для доставки почты через аутентифицированные почтовые клиенты. Если эта функция включена, SMTP-сервер формирует заголовок «Received:» без информации из сеанса клиента. В зависимости от сеанса из заголовка могут быть скрыты, например, имя хоста и IP-адрес клиента, данные сеанса TLS, данные для входа SASL, а также сведения о протоколе SMTP.

Расставь их по порядку Функция защиты данных в специальное определение службы отправки данных для порта 587 или 465, вместо того чтобы задавать их глобально в main.cf . Публичный MTA на порту 25 выполняет иную роль в передаче данных между серверами. В документации Postfix для этого параметра указано стандартное значение, чтобы обеспечить соответствие требованиям RFC 5321.

Таким образом, это решение касается не только конфиденциальности, но и отслеживаемости, а также границ обслуживания. Для авторизованных клиентов сокращение объема ненужных метаданных может быть целесообразным. Однако на общедоступном сервере MX такой же настройка нарушила бы задокументированные ожидания в отношении информации в поле «Received:». Поэтому вместо единого глобального правила рекомендуется проверять отдельные службы, прослушиватели и их соответствующие параметры.

Кроме того, Postfix 3.10.0 содержит адаптацию для OpenSSL 3.5 и его группового синтаксиса для постквантовой криптографии. Если необходимо полностью делегировать выбор групп централизованно поддерживаемой конфигурации OpenSSL, необходимо tls_eecdh_auto_curves и tls_ffdhe_auto_groups оба поля должны быть пустыми. Только при таком совместном настройке OpenSSL сам выбирает вариант; Postfix не поддерживает новый синтаксис OpenSSL.

Очистка обоих автоматических параметров представляет собой Особый случай для централизованно управляемых настроек шифрования, а не в качестве общей рекомендации по укреплению безопасности. Это подходит только в том случае, если эффективная конфигурация OpenSSL известна, имеет версию и протестирована. При отсутствии такого контроля перенос выбора может скрыть ошибки в конфигурации или привести к появлению неожиданных свойств TLS; в таком случае явные настройки Postfix остаются более понятными.

Проверить состояние патчей и известные ошибки

Само по себе указание версии 3.10 не отражает единого технического состояния. Решающее значение имеют конкретная версия патча, сведения из журнала изменений дистрибутива и, при необходимости, исправления, портированные назад. Postfix 3.10.14 был анонсирован 7 сентября 2026 года в качестве устаревшей версии вместе с другими поддерживаемыми ветвями. Из этого не следует, что каждый пакет для Linux уже содержит эту версию из исходного репозитория.

Конкретным примером является Postfix 3.10.6: в этом выпуске была устранена проблема, связанная с TLS требуется: нет и режим TLS-обёртки на стороне клиента. Предыдущая реализация могла негативно влиять на такие соединения; исправление обрабатывает их с уровнем безопасности „encrypt“. Поэтому тем, кто использует режим оболочки SMTPS, следует проверять версии патчей и фактически используемый канал передачи, а не делать выводы об одинаковом поведении на основании версии «3.10».

В анонсе версии 3.10.14, среди прочего, упоминаются исправления и укрепления безопасности, касающиеся сценария SMTP-smuggling с использованием smtpd_proxy_filter. Это не означает, что проблема затрагивает все почтовые серверы: по умолчанию этот параметр отключен, и актуальность данного вопроса зависит от локальной конфигурации, а также от предшествующей или подключённой архитектуры фильтрации. Поэтому сначала проверьте, используется ли эта функция вообще.

При обнаружении проблем с доставкой следует соблюдать определённую последовательность действий при поиске неисправностей: сначала проверьте фактические отклонения и правильность конфигурации, затем — успешность перезагрузки после обновления. Затем необходимо проанализировать очередь и протоколы на наличие повторяющихся сообщений о TLS, соединениях или отложенных операциях. Систематическое руководство по Анализ лог-файлов Postfix помогает сопоставить отдельные события с идентификатором очереди и соответствующей попыткой доставки.

Предупреждение: Смена версии не заменяет анализ причин. Перезагрузка не устраняет ни недействительные цепочки сертификатов, ни ошибки DNS, ни несоответствующие правила маршрутизации. И наоборот, отсутствие перезагрузки после обновления может скрыть изменения в процессах или конфигурациях, произошедшие в ходе эксплуатации. Поэтому необходимо совместно документировать состояние патчей, источник пакетов, время активации и наблюдаемые сообщения в журналах.

Как правильно оценивать отчеты TLSRPT в процессе эксплуатации

Отчеты TLSRPT поступают с задержкой и не заменяют мониторинг в режиме реального времени. В документации Postfix указано, что в среднем проходит около двенадцати часов до поступления отчета об ошибке. В Postfix регистрируемые результаты относятся к TLS-рукопожатиям; ошибки установления соединения и прерывания до или после рукопожатия не учитываются. Для оперативного реагирования на инциденты по-прежнему необходимы мониторинг очередей, анализ журналов и система оповещения.

Повторное использование также ограничивает подсчёт: повторно используемое SMTP-соединение не вызывает повторного обмена данными TLS. При возобновлении сеансов TLS Postfix 3.10 по умолчанию пропускает регистрацию; для этого используется параметр smtp_tlsrpt_skip_reused_handshakes. Поэтому сводные отчёты не отражают ни полного числа всех SMTP-соединений, ни доли сообщений, ни коэффициента доставки. Анализируйте типы ошибок, домены получателей, временные интервалы и повторяющиеся паттерны в совокупности с протоколами сервера.

Сама по себе техническая отправка отчета ещё не приносит пользы. Заранее определите, кто отвечает за работу с получателем RUA, кто принимает и сохраняет отчеты, а также как долго будут храниться данные. Поскольку отчеты могут содержать информацию о сеансах TLS, в концепцию эксплуатации должны быть включены права доступа, требования по защите данных и процедура удаления. Также должно быть предусмотрено правило эскалации для повторяющихся ошибок.

Таким образом, анализ объединяет два уровня: TLSRPT отображает обобщенные тенденции за определенный период, в то время как протоколы почтовых серверов предоставляют информацию о конкретном ходе отдельных попыток доставки. Для текущего мониторинга дополняет Практическое руководство по мониторингу лог-файлов Postfix отчеты о методах классификации сообщений об ошибках и очередей. Автоматические сигналы тревоги должны реагировать на оперативные данные в режиме реального времени, а не только на поступившие агрегированные данные TLSRPT.

Если не предусмотрены ни ответственный получатель, ни защищенное хранилище, ни регулярный анализ, публикацию TLSRPT следует сначала тщательно спланировать, а не активировать поспешно. Ответственность за отчетность является частью функции безопасности: только после присвоения ошибки ответственному подразделению становится возможным принять обоснованные меры, например, в случае истечения срока действия политики MTA-STS или возникновения проблем с данными TLSA.

Выполнить обслуживание 3.10 или перейти к пункту 3.11

Выбор между поддержкой патчей и переходом на другую ветку зависит от исходной ситуации и целей организации. На момент проведения исследования Postfix 3.10 остаётся поддерживаемой устаревшей веткой, тогда как 3.11 является стабильной веткой разработки. Поэтому регулярные исправления в рамках версии 3.10 целесообразны для существующих установок; однако их не следует приравнивать к функциональному обновлению до версии 3.11.

Переход на версию 3.11 оправдан, прежде всего, в том случае, если требуются её функции или долгосрочные целевые возможности. REQUIRETLS и вывод данных в формате JSON в определённых инструментах администрирования задокументированы как особенности более новой ветки и не должны учитываться в качестве функций Postfix 3.10. Перед переходом на новую ветку необходимо проверить совместимость параметров конфигурации, подключенных фильтров, аутентификации и автоматизации.

Для стабильной работы системы версии 3.10 без необходимости добавления новых функций требуется постоянное обновление патчей непосредственно подходящая мера. Тем не менее она требует контролируемого процесса, включающего резервное копирование, проверку пакетов, валидацию, проверку активации процесса и мониторинг. Смена отрасли, напротив, требует наличия профессионального повода и запланированного окна технического обслуживания; сам по себе более высокий номер версии не является достаточным критерием для принятия решения.