Приложение сообщило об отправке, но уведомления нет у получателя. Начните с границы, которую приложение действительно проверило: соединение с relay, ответ на адрес получателя или ответ после передачи всего сообщения. Затем найдите письмо по queue ID на принявшем его Postfix и проверьте исход передачи следующему узлу. Так можно отличить отказ на входе, отложенную доставку и окончательную ошибку после приёма письма.
Содержание и переходы
Для проверки нужна одна контролируемая цепочка и запись её результатов. Уведомление о проверке отправляют тестовому получателю; реальные клиентские адреса для этого не нужны. Ниже разобран изолированный лабораторный пример. Его конфигурацию допуска relay нельзя переносить на рабочий сервер без проверки собственной политики.
1. Сначала нарисуйте путь уведомления
В нашем опыте путь выглядел так:
SMTP-клиент → Postfix relay → контролируемый следующий SMTP-узелВ реальной системе после этого узла могут быть другие серверы и конечное почтовое хранилище. Поэтому в карточке теста нужны отдельные поля:
| Что записать | Зачем |
|---|---|
| Время теста и тестовый адрес | Связать попытку с журналами нужного узла |
| Этап и ответ SMTP | Установить, какую операцию подтвердил или отклонил сервер |
| Queue ID первого relay | Найти дальнейшую обработку принятого письма |
| Исход у следующего узла | Отличить передачу от временного или постоянного отказа |
| Факт появления у контролируемого получателя | Проверить конечную границу, если она входит в тест |
Если последнее поле не проверяли, оставьте его неизвестным. Отсутствие письма в очереди само по себе не объясняет, дошло ли оно: нужен журнал и наблюдение на принимающей стороне.
2. Что именно проверялось на стенде
Использовались Postfix 3.7.11, Debian 12 и Python 3.11. Контейнер работал с отключённой внешней сетью (--network none); клиент, relay и следующий узел общались через loopback. Все почтовые адреса были синтетическими в доменах .invalid.
На участке клиент → relay применялся STARTTLS с проверкой сертификата по лабораторному CA и проверкой IP SAN 127.0.0.1. Участок relay → следующий узел был открытым SMTP внутри изолированного контейнера. Таким опытом нельзя подтвердить сквозное TLS-шифрование или корректность сертификатов внешнего почтового провайдера.
Разрешённый клиент допускался через mynetworks. SASL-аутентификация в опыте не проверялась. Если рабочее приложение входит по логину и паролю, его механизм аутентификации требует отдельной проверки: результат этого стенда её не заменяет.
3. Различайте RCPT и окончательный ответ после DATA
SMTP-сервер отвечает на отдельные команды. Успешный ответ на адрес получателя ещё не подтверждает приём всего сообщения. После DATA важно сохранить окончательный ответ на завершённое сообщение, а не только промежуточный ответ, разрешающий передачу данных.
RFC 5321, §§4.2 и 6.1 различает временные отрицательные ответы 4xx и постоянные 5xx. Успешное завершение DATA означает принятие ответственности данным сервером. Наблюдение за последующей доставкой остаётся отдельной задачей.
В первом сценарии клиент, не входящий в доверенную сеть, попытался передать письмо внешнему тестовому получателю. При политике permit_mynetworks, Postfix ответил на RCPT:
454 4.7.1 Relay access deniedДо DATA дело не дошло. Для этой конфигурации это временный отказ 454. Не заменяйте его в описании ожидаемым 550 и не делайте из него вывод об отправке письма в очередь. Проверять следует доступ клиента к relay и применённые ограничения именно этого listener.
4. Один приём письма — три разных продолжения
Для разрешённого клиента первый relay принял сообщение и вернул после DATA ответ 250 с queue ID. Дальнейший результат зависел от ответа следующего узла.
| Сценарий | Первый relay после DATA | Наблюдение дальше | Что доказано |
|---|---|---|---|
| Следующий узел принимает письмо | 250, 8AD9B100DD | status=sent, dsn=2.0.0; тестовый узел сохранил DATA | Передача контролируемому следующему узлу |
| Следующий узел отвечает на RCPT кодом 450 | 250, 8C1C7100DF | status=deferred, dsn=4.0.0; письмо присутствует в deferred | Первый relay принял письмо, дальнейшая передача отложена |
| Следующий узел отвечает на RCPT кодом 550 | 250, 8D00F100DD | status=bounced, dsn=5.0.0; сформировано уведомление о недоставке | Первый relay принял письмо, затем зафиксировал постоянный отказ следующего узла |
В последнем сценарии было установлено soft_bounce=no. В журнале исходное письмо связано с DSN 8F584100EA. Контролируемый следующий узел принял уведомление на синтетического отправителя; у уведомления был пустой envelope sender и часть message/delivery-status.
Это важная диагностическая развилка: приложение могло получить успешный ответ первого relay, хотя следующая передача завершилась отказом. Проверяйте дальнейший исход по журналу и уведомлению о недоставке, а не меняйте задним числом смысл ответа 250.
В успешном сценарии мы подтвердили сохранение DATA следующим узлом. Реальный пользовательский почтовый ящик в опыте не участвовал; утверждать доставку во «Входящие» по этому измерению нельзя.
5. Как связать журнал и очередь
Возьмите queue ID из ответа первого relay и найдите относящиеся к нему события в журнале этого же экземпляра Postfix. Для лабораторного временного отказа цепочка была такой:
Первый relay: 250, queued as 8C1C7100DF
Следующий узел: 450 на RCPT TO
Журнал первого relay: status=deferred, dsn=4.0.0
Очередь: queue_id=8C1C7100DF, queue_name=deferredВ стенде очередь прочитана командой postqueue -j: в сохранённом результате осталось ровно это письмо. Для просмотра очереди также предусмотрен postqueue -p. Это команды наблюдения; для первоначальной диагностики не требуется принудительно выпускать всю очередь или удалять сообщения.
Проверяйте время и экземпляр сервера вместе с идентификатором. Нельзя искать ID на произвольном relay и считать отсутствие совпадения доказательством потери письма.
После 450 мы проверили постановку в deferred. Доставку после восстановления следующего узла в этот прогон не включали. Если задача — доказать восстановление, нужен следующий самостоятельный результат: устранённая причина, последующая попытка передачи и наблюдение у получателя. Само ожидание в очереди этого не доказывает.
6. Карточка результата и следующая проверка
| Наблюдение | Следующая проверка |
|---|---|
| Отказ до DATA | Этап отказа, политика TLS/relay и способ допуска клиента |
| DATA принято, письмо в deferred | Ответ следующего узла, причина задержки и состояние очереди |
| DATA принято, затем bounced | Постоянный отказ следующего узла и связанное уведомление о недоставке |
| В журнале sent | Какой узел принял сообщение и какую конечную границу проверили |
| Нет записи по queue ID | Тот ли экземпляр Postfix, время и ID выбраны; есть ли исходный ответ приложения |
Полезный итог теста выглядит конкретно: «первый relay принял DATA, queue ID такой-то; следующий узел ответил 450 на RCPT; сообщение осталось в deferred; восстановление доставки не проверялось». Формулировка «почта работает» скрыла бы незавершённую часть проверки.
Частые вопросы
Ответ 250 означает, что уведомление дошло человеку?
Укажите, на каком этапе и от какого сервера получен этот ответ. В нашем опыте 250 после DATA подтверждал приём первым relay, после чего следующая передача могла закончиться sent, deferred или bounced. Появление в конечном ящике проверяют отдельно.
Почему отказ в relay оказался 454, а не 550?
На стенде применялось defer_unauth_destination, и наблюдался ответ 454 на RCPT для недоверенного клиента. Это результат данной политики. Не подменяйте наблюдаемый код кодом из другого руководства или конфигурации.
Что означает deferred после успешного DATA?
Первый relay принял сообщение, но очередная попытка следующей передачи завершилась временным отказом. В лаборатории следующий узел ответил 450 на RCPT, а письмо сохранилось в очереди. Последующее восстановление доставки здесь не измерялось.
Проверили ли вы вход по SMTP-логину и паролю?
Нет. Допуск разрешённого клиента был основан на mynetworks; SASL не проверялся. Для клиента с аутентификацией это отдельная часть теста.
Нужно ли покупать отдельный почтовый сервер для такой проверки?
Эта процедура проверяет существующую цепочку уведомлений и не определяет потребность в новом оборудовании. Если задача состоит в выборе платформы для корпоративной почты, ей посвящён отдельный материал о подборе почтовного сервера.
Источники и границы результата
- Методика опыта: изолированный стенд от 13.11.2026, Postfix 3.7.11/Debian 12; четыре сценария с фиксацией ответов, очереди, журнала и событий контролируемого следующего узла.
- SMTP: RFC 5321, §§4.2, 4.2.5 и 6.1.
- Справочная документация: политика relay Postfix и postqueue. Наблюдения по очереди в статье относятся к описанному лабораторному опыту.
Текст описывает диагностику на контролируемом примере. Он не содержит результатов внешней доставки, SASL-проверки или восстановления после 450.
Авторство и границы проверки
Материал подготовлен при участии ИИ по документации и результатам изолированного лабораторного опыта. Проверки внешней доставки, SASL и восстановления после ответа 450 в этот опыт не входили. Пример не заменяет проверку собственной политики relay.
