Postfix 3.11.6 появился 10 августа 2026 года с набором исправлений безопасности и устойчивости для SMTP-сервера, Milter, MySQL-клиента и механизма проверки адресов. Самая заметная история релиза связана с ошибкой состояния SMTP: специально сформированная последовательность команд могла провести второе сообщение через часть проверок доступа, а некоторые исправленные дефекты тянулись в коде с конца 1990-х и начала 2000-х годов.
Postfix 3.11.6 исправляет рассинхронизацию SMTP после отклонения письма
Одна из самых серьёзных находок затрагивает состояние SMTP-сессии после того, как smtpd_end_of_data_restrictions отклоняет сообщение. В истории изменений Postfix указано, что ошибка появилась ещё в Postfix 2.2 в ноябре 2004 года: сервер не сбрасывал состояние команд MAIL FROM и RCPT TO после отказа на финальном этапе приёма письма.
Из-за этого специально подготовленный SMTP-клиент мог продолжить диалог в уже рассинхронизированной сессии. После отклонённого сообщения он отправлял RCPT TO и DATA без нового MAIL FROM, а Postfix принимал второе сообщение. В такой последовательности smtpd_end_of_data_restrictions мог пропустить ограничения check_recipient_access, поскольку внутренний счётчик получателей оставался больше единицы.
Суть проблемы хорошо видна именно на уровне протокола. SMTP-сервер хранит состояние текущей транзакции: отправителя, получателей и этап обработки сообщения. Если после ошибки эти данные сохраняются, следующая команда клиента начинает работать с фрагментами предыдущей транзакции. В Postfix 3.11.6 этот разрыв состояния закрыт.
Исследователи OpenAI Security сообщили и о связанном сценарии с Milter — интерфейсом, через который Postfix подключает внешние фильтры почты. Если Milter уже вернул решение принять сообщение по его конверту, а затем smtpd_end_of_data_restrictions отклонил письмо, Milter-клиент мог остаться в состоянии accept. Для следующего сообщения в той же рассинхронизированной SMTP-сессии часть политики фильтрации тогда не выполнялась.
Ошибки BDAT могли завершить smtpd сбоем или постепенно расходовать память
Команда BDAT используется расширением SMTP CHUNKING и позволяет передавать содержимое письма блоками. В Postfix обнаружились сразу две разные проблемы вокруг этого механизма.
Первая появилась в Postfix 3.4 в 2018 году. После ошибки BDAT сервер мог сохранить состояние RCPT TO. Удалённый клиент затем отправлял DATA без корректной пары MAIL FROM и RCPT TO, что приводило к чтению нулевого указателя и аварийному завершению процесса smtpd.
Вторая ошибка касалась истории SMTP-команд. Большое количество очень маленьких запросов BDAT заставляло сервер накапливать данные в памяти. Такой поток позволял удалённому клиенту создавать сценарий истощения памяти в процессе SMTP-сервера.
Для почтовой инфраструктуры разница между этими случаями существенна. Первый сценарий бьёт по конкретному процессу обработки соединения, второй способен удерживать ресурсы серией мелких запросов. Оба дефекта находятся на сетевой границе Postfix, где данные поступают непосредственно от SMTP-клиента.
MySQL-проверка сертификата и TLS-сессии получили отдельные исправления
В Postfix 3.11.6 вошло исправление для конфигураций, где таблицы Postfix хранятся в MySQL. Настройка tls_verify_cert = yes в MySQL-клиенте Postfix фактически не включала проверку сертификата при работе с Oracle MySQL 8 и более новыми версиями. Ошибку и исправление передала OpenAI Security.
Такой параметр обычно задаёт ожидаемое поведение TLS-соединения с базой данных: клиент должен проверять сертификат сервера. При проблеме в Postfix администратор мог видеть включённую настройку и рассчитывать на проверку, хотя клиентская библиотека работала иначе.
Ещё одно изменение разделяет TLS session tickets между SMTP-сервисами, описанными в master.cf. Теперь билет TLS-сессии получает привязку к имени конкретного сервиса. Один SMTP-сервис из master.cf больше не принимает билет, выданный другим сервисом из того же файла конфигурации.
Это касается установок, где на одном Postfix работают несколько SMTP-точек входа — например, разные сервисы для обычного SMTP, submission или отдельных политик. Разделение session tickets уменьшает пересечение состояния между такими сервисами.
Address verification cache можно было отравить через локальную отправку
Ещё один дефект существовал с Postfix 1.1 и датируется ноябрём 2002 года. Он связан с кэшем проверки адресов — механизмом, который запоминает результаты проверки существования или доступности адресата.
Локальный пользователь мог через postdrop отправить специальный address verification probe с конвертом или содержимым, которое Postfix позднее отклонял. В кэше при этом появлялась отрицательная запись для проверяемого адреса.
Если сервер использовал address verification, такая отрицательная запись заставляла SMTP-сервер отклонять письмо на адрес, который в обычной ситуации должен был приниматься. В upstream HISTORY этот сценарий прямо описан как denial of service для систем с включённой проверкой адресов.
Здесь атака требует локальной возможности отправлять данные через postdrop, поэтому модель угроз отличается от удалённых SMTP-сценариев. Последствие при успешном использовании проявляется уже во входящей почте: корректный адрес временно воспринимается как недоступный из-за отравленного результата проверки.
В релиз попали дефекты, которые пережили несколько поколений Postfix
История Postfix 3.11.6 примечательна возрастом части исправленного кода. В изменениях перед релизом встречаются ошибки, появившиеся до первого публичного alpha-выпуска Postfix, а также дефекты начала 2000-х годов.
Среди них есть обработка очень коротких имён файлов очереди в postsuper, ошибки старой функции совместимости strerror(), проблема в SMTP-клиенте при разборе расширенного status code и дефект fast flush server, который мог запускать лишние сканирования очереди. Рядом с ними находятся значительно более свежие проблемы — например, регрессия postscreen_dnsbl.c, обнаруженная уже после июньского исправления 2026 года.
Значительную часть старых дефектов нашла Qualys при помощи Claude Mythos Preview. Несколько августовских проблем, включая рассинхронизацию SMTP, BDAT, MySQL TLS и address verification cache, были переданы OpenAI Security. Получился редкий для patch-релиза срез истории проекта: в одном цикле исправлений сошлись код 1990-х, механизмы эпохи Postfix 2.x и функции веток 3.x.
Отдельных CVE-идентификаторов для перечисленных августовских находок в проверенных upstream-записях на момент подготовки материала нет. Поэтому их корректнее различать по описанию дефекта, затронутому модулю и дате появления в HISTORY.
Вместе с Postfix 3.11.6 обновились шесть предыдущих веток
Исправления выпущены сразу для нескольких линий Postfix. Свежая стабильная ветка получила 3.11.6, а параллельно появились сборки для более ранних серий:
| Ветка | Новая версия |
| 3.11 | 3.11.6 |
| 3.10 | 3.10.13 |
| 3.9 | 3.9.14 |
| 3.8 | 3.8.20 |
| 3.7 | 3.7.22 |
| 3.6 | 3.6.20 |
| 3.5 | 3.5.27 |
Такой набор версий показывает, что исправления затрагивают общий код, накопленный за много лет. Часть найденных проблем появилась задолго до современных веток и поэтому присутствовала сразу в нескольких поколениях Postfix.
При этом ветки 3.5–3.7 уже находятся за пределами обычного срока поддержки. Их новые сборки закрывают рассматриваемую группу дефектов, а состав более ранних исправлений в этих сериях отличается от поддерживаемых веток.
Postfix 3.11.6 фиксирует состояние SMTP и продолжает аудит старого кода
После Postfix 3.11.5 июльский аудит продолжился и дошёл до участков, которые напрямую влияют на сетевую обработку почты, TLS и внутренние кэши. В 3.11.6 исправлены сценарии рассинхронизации SMTP, сбои и расход памяти вокруг BDAT, проверка сертификата MySQL, изоляция TLS session tickets и отравление address verification cache.
Самый любопытный вопрос остаётся вокруг глубины этого аудита. Upstream HISTORY показывает находки с датами появления от 1997 года до 2026-го, поэтому текущая серия исправлений уже стала проверкой нескольких поколений кода Postfix. Какие ещё старые участки дадут похожие результаты после дальнейшего анализа, пока неизвестно.
