Почему почтовый сервер отвечает кодами 554 и 421

Коды 554 и 421 сами по себе не называют причину сбоя: смотрите полный ответ SMTP, этап диалога и запись в журнале. 554 означает отказ, который нельзя исправить простой повторной попыткой без изменения условий; 421 — временный отказ с закрытием соединения. Покажу, как идти от симптома к проверке Postfix.

Что означают SMTP-коды 554 и 421

Первая цифра SMTP-ответа задаёт класс результата. 4xx — временный отказ: отправляющая система обычно повторит доставку позднее. 5xx — постоянный отказ для этой попытки и с теми же параметрами; бесконечно повторять её бессмысленно. По RFC 5321 код 421 означает, что служба недоступна и закрывает канал, а 554 — общий отказ транзакции. Это описание класса ответа, не диагноз конкретной настройки.

Важны полный текст ответа и расширенный статус после основного кода: например, 5.7.1 указывает на проблему политики или безопасности, но сам по себе не доказывает, что виноваты пароль, SPF или relay. Один и тот же основной код может появиться на разных шагах SMTP-сеанса. Поэтому я фиксирую имя узла, время, отправителя и получателя, ответ целиком и этап — соединение, MAIL FROM, RCPT TO или DATA. Коротко: цифры дают направление, причина обычно находится рядом в тексте. Если нужна помощь с инфраструктурой, мы настраиваем корпоративную почту. Основной SMTP-код и расширенный статус — разные уровни подсказки. Первый знак основного кода говорит о временном или постоянном характере ответа, а текст после кода и расширенный статус уточняют область отказа. Даже формулировка «access denied» без имени узла и этапа не показывает, кто именно запретил операцию: отправитель, шлюз, принимающий сервер или политика адреса. Я сохраняю весь ответ без пересказа, потому что одно сокращённое слово в тикете легко меняет смысл.

Условный кейс: два ответа, одна жалоба

Представим условную сеть «Зенит Групп» — это пример из поля company, а не описание подтверждённого обращения. Сотрудник сообщает: «входящие письма не доходят», а в пересланных уведомлениях встречаются 554 и 421. Я не стал бы объявлять причиной ни перегрузку, ни конкретную строку конфигурации: сначала нужно отделить сообщения, которые принял ваш сервер, от тех, где внешний узел отказал ещё при соединении. Одинаковая жалоба пользователя может скрывать два независимых маршрута.

В первом уведомлении полный ответ 554 пришёл после RCPT TO от собственного MX. Тогда проверяют правила доступа и допустимость адреса получателя на стороне этого MX. Во втором случае внешний сервер вернул 421 при передаче исходящего письма; это временный отказ удалённой SMTP-службы, и локальная правка recipient restrictions может быть совершенно мимо. В примере не нужны выдуманные «20 минут» и обещание доставки через пять: решение зависит от фактической записи, а не от красивого таймера. Сначала отделяем два эпизода, затем проверяем каждый своим журналом. Для входящей почты особенно важно не спутать отказ вашего MX с отказом внешнего отправителя. Если сервер вернул ошибку в ответ на RCPT TO, это означает, что адрес получателя не был принят на этом этапе; письмо ещё не передано в DATA. Если отказ последовал после DATA, исследуйте журнал обработки содержимого и подключённые фильтры. Это помогает сузить круг проверок, но не даёт права заранее обвинять конкретный фильтр: сначала найдите запись компонента, который вынес решение.

Как найти нужную запись в журнале Postfix

Расположение журнала зависит от дистрибутива и способа настройки syslog. На одной системе это /var/log/maillog, на другой — /var/log/mail.log; Postfix также может писать в собственный файл или системный журнал. Не предполагайте путь по памяти: выясните, куда пишет именно этот сервер. В официальной инструкции Postfix указано, что при syslog имя файла задаётся конфигурацией syslog, а отдельный режим журналирования настраивается параметром Postfix maillog_file.

Если журнал — обычный текстовый файл, начните с предупреждений и ошибок, затем сузьте поиск по времени, адресу или идентификатору очереди. Например, для типичного файла можно выполнить команду из документации Postfix: grep -E '(warning|error|fatal|panic):' /var/log/maillog. Подставьте фактический путь своей системы. Утилита maillog с ключом -e не является универсальной штатной командой Postfix: такой совет лучше вычеркнуть, чем запускать неизвестный скрипт от администратора. Не включайте подробный режим логирования наугад — сначала используйте штатные записи, а временную отладку ограничивайте конкретным сервисом и временем. При фильтрации журнала не ищите только строки с буквами «554» и «421»: в журнале вашей стороны может быть записан результат доставки и пояснение удалённого узла, а не исходная строка SMTP-сеанса целиком. Сопоставление времени, queue ID, адреса назначения и текста статуса надёжнее поиска одного трёхзначного числа. Документация Postfix советует искать предупреждения и ошибки и отмечает, что важная причина часто находится раньше последующих сообщений. Начинайте с первой ошибки в цепочке.

• Установите направление доставки: входящая или исходящая
• Найдите журнал Postfix или syslog за нужное время
• Сохраните полный ответ SMTP и этап диалога
• Сверьте запись с идентификатором очереди и адресами

Проверьте правила приёма и relay в Postfix

Для отказа на RCPT TO проверьте, какие ограничения действуют на получателя и на релейную пересылку. В Postfix это разные задачи: smtpd_recipient_restrictions управляет проверками получателя, smtpd_relay_restrictions — политикой relay в современных версиях. Списки ограничений читаются слева направо до результата PERMIT, REJECT или DEFER, поэтому порядок правил имеет значение. Не вставляйте случайный permit в начало списка: можно изменить не только приём нужного письма, но и право пересылать почту.

Сравните фактические значения с ожидаемыми и проверьте карты доступа, локальные домены, relay-домены и доверенные сети. Путь к дополнительному файлу конфигурации нельзя угадывать по названию: стандартная основная конфигурация Postfix использует main.cf и master.cf, а включение других файлов зависит от конкретной настройки. additional.cf не является универсальным именем файла Postfix. Проверяйте именно активную конфигурацию и не добавляйте целые сети в доверенные ради одного отправителя. Исключение должно быть узким, обоснованным и проверенным на тестовом сообщении. Практический разбор безопасного relay есть в статье о правилах relay в Postfix. В Postfix порядок правил не косметика. Список проверок выполняется слева направо и останавливается на первом явном разрешении, запрете или временном отказе; поэтому перестановка элементов способна поменять результат для того же SMTP-клиента. До правки запишите исходный порядок, определите ожидаемое поведение для доверенного и внешнего отправителя, затем проверьте обе ветки. Если есть сомнение, сначала разберите это на тестовом окружении или с ограниченным контрольным сценарием.

Разберите 421 и отложенную доставку

Ответ 421 означает временную недоступность SMTP-службы и закрытие канала. RFC не говорит, что причиной обязательно стали CPU, память или переполненная очередь. Это может быть плановое завершение работы службы, ограничение политики, перегрузка или иной локальный отказ; точный смысл ищите в продолжении ответа и журнале сервера, который отправил 421. Если код пришёл от удалённого MX, нагрузка на ваш сервер может быть вообще ни при чём.

При временном отказе отправляющий сервер обычно ставит письмо на повторную доставку по своей политике. Проверьте, растёт ли очередь, повторяется ли ошибка для одного домена или возникает у разных получателей, и сравните ответы по времени. Не ускоряйте повторы без понимания причины и не удаляйте очередь, чтобы «разгрузить» сервер: так можно потерять письма. Если ваш Postfix выдаёт 421 входящему соединению, смотрите его журнал и ограничения службы; если ответил чужой сервер, зафиксируйте его полный текст и время, а затем проверьте состояние удалённого направления. Сравнение ответов по времени помогает отличить единичный эпизод от повторяющейся проблемы, но не превращает совпадение в причину. Например, одинаковый 421 у нескольких получателей на одном MX — повод проверить этот узел и маршрут к нему; ответы от разных MX требуют другой картины. Смотрите также, продолжает ли очередь повторять доставку и меняется ли ответ. Обнаруженная корреляция с ростом очереди — повод проверить нагрузку, но только журнал покажет, какой процесс и какое ограничение реально участвовали.

• Сравните ответы для одного домена и разных доменов
• Проверьте динамику очереди, не удаляя сообщения
• Определите, какой узел сформировал 421
• При повторении эскалируйте владельцу удалённого MX

Исправьте причину и проверьте результат

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

Проверка результата должна повторять исходный сценарий: тот же отправитель, получатель и маршрут. Убедитесь, что нужное письмо принято или передано дальше, а отказ не превратился в открытый relay или обход фильтра. Затем проверьте очередь и журналы на повторные отказы. В плановом режиме достаточно мониторить доступность приёма и рост очереди; алерт только на число 554 без контекста даст шум, поскольку этот код может сопровождать разные ситуации. Я записываю изменённое правило и причину: через месяц это экономит больше времени, чем ещё один героический поиск по всей конфигурации. Для регулярной работы полезно заранее определить состав обслуживания почтового сервера, включая контроль журналов и очереди. Контрольный прогон завершайте записью результата: какой ответ был до изменения, какое правило поменяли, какой тест повторили и что показал журнал после него. Это не бюрократия, а способ не отменить удачное исправление при следующем дежурстве. Если отказ сформировал внешний сервер, не маскируйте его локальным allowlist: передайте администратору удалённой стороны точный код, полный текст, время и идентификатор сообщения. Так у адресата будет материал для проверки, а не просьба «починить почту».

• Сохраните резервную копию настройки
• Проверьте конфигурацию и выполните reload при необходимости
• Повторите исходный сценарий доставки
• Проверьте журналы, очередь и отсутствие побочного эффекта

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