Postfix + Dovecot: как разбирать ошибки 552 и 554 и настраивать лимиты без боли

В связке Postfix + Dovecot коды 552 и 554 часто воспринимаются как «почта сломалась». На практике это обычно предсказуемый отказ по лимиту или политике: слишком большое письмо, переполненный ящик, превышение количества подключений, антиспам/ограничения на входе или отказ удалённого сервера при исходящей доставке.

Задача администратора — не «подкрутить всё подряд», а сначала понять, кто вернул код и на каком этапе: входящий SMTP (приём) → локальная доставка в ящик (LMTP/local) → исходящая SMTP-доставка на внешний MX. Один и тот же 552 может означать и лимит размера у вас, и квоту в Dovecot, и ограничение на стороне получателя.

Ниже — практический разбор: где смотреть логи, как быстро классифицировать сценарий и как безопасно настраивать ключевые параметры message_size_limit в Postfix и mail_max_userip_connections в Dovecot.

Что означают 552 и 554 в SMTP и почему важен источник

SMTP-коды — это часть протокола, но в жизни важнее контекст: какая подсистема пишет отказ и какой текст причины стоит рядом.

• 552 — чаще всего «превышен лимит» (размер сообщения, квота, ограничение ресурса).
• 554 — «транзакция отклонена» (политика, фильтр, антиспам, ограничения при приёме или отказ внешнего MX).

Сначала выясните фазу и компонент: postfix/smtpd (вход), postfix/lmtp/postfix/local (локальная доставка), postfix/smtp (исход на внешний MX). Дальше настройки становятся очевиднее.

Шаг 1. Определить фазу отказа по логам Postfix

Обычно логи Postfix лежат в /var/log/mail.log или /var/log/maillog. Ищите по признакам NOQUEUE, reject, status=bounced, status=deferred, а также по queue id (идентификатору в очереди).

Быстрый поиск свежих событий и отказов

grep -E "postfix/|dovecot" /var/log/mail.log | tail -n 200

grep " NOQUEUE" /var/log/mail.log | tail -n 80

Интерпретация простая:

• NOQUEUE: reject — отказ на входе, письмо не попало в очередь Postfix.
• Есть queue id (например, 3F2A012345) — письмо принято; дальше смотрите, где именно оно «упало» (LMTP/local или исходящий SMTP).

Маркерные строки для трёх фаз

• Входящий приём: postfix/smtpd, client=, NOQUEUE, reject.
• Локальная доставка: postfix/lmtp или postfix/local, получатель to=<user@yourdomain>, часто упоминание LMTP-сокета Dovecot.
• Исходящая доставка: postfix/smtp, есть relay=, dsn=5.x.x, status=bounced или status=deferred.

552: размер, квота, лимиты. Как отличить и что чинить

Код 552 — про «слишком много», но «много чего» именно подсказывает текст рядом с кодом и компонент в логе.

Сценарий A: Postfix режет по размеру (message_size_limit)

Если Postfix отклоняет письмо по размеру, в логах обычно встречаются формулировки вроде «message size exceeds fixed maximum message size» или близкие.

Проверяем текущие значения:

postconf message_size_limit

postconf mailbox_size_limit

Важно не путать:

• message_size_limit — максимальный размер одного сообщения, которое Postfix примет/передаст (в байтах).
• mailbox_size_limit — лимит на размер ящика на уровне Postfix (часто ставят 0, чтобы квоты контролировал Dovecot).

Пример: поднять лимит до 50 МБ (52428800 байт) и применить:

postconf -e 'message_size_limit = 52428800'

systemctl reload postfix

Если используете submission (587) и в master.cf есть переопределения через -o, проверьте, что там не задан другой message_size_limit.

Сценарий B: 552 на LMTP-доставке в Dovecot из-за квоты

Классика: Postfix письмо принял, но при доставке в локальный ящик Dovecot вернул 552 с текстом вроде «Quota exceeded» или «Mailbox is full». В Postfix это обычно видно как ошибка в postfix/lmtp (или postfix/local).

Минимальный чек-лист, чтобы не гадать:

• Свободное место и inode: df -h и df -i.
• Включены ли квоты Dovecot и какой драйвер используется (quota/quota2).
• Права на каталог mailbox/Maildir и ошибки файловой системы.

Если у вас квоты на Dovecot, полезно держать mailbox_size_limit в Postfix равным 0, чтобы не получить «двойной контроль» и неожиданные отказы.

Для углубления по квотам и “мусорным” предупреждениям Dovecot пригодится материал: разбор предупреждений quota2 и очистка состояния квот.

Сценарий C: 552 вернул внешний сервер получателя

Если в логах postfix/smtp и рядом ответ удалённого MX с 552, то вы уже «упёрлись» в лимит/квоту на стороне получателя (или в его политику по размеру). Поднятие message_size_limit у вас не поможет: письмо не приняли там.

Что делать практически: зафиксировать точный текст ответа из логов, уменьшить вложение или менять способ передачи больших файлов (ссылка вместо вложения). Если это регулярная коммуникация с конкретным доменом — согласовать лимиты с админами той стороны.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

554: отказ по политике/фильтрам. Где искать причину и что проверять

554 — «коварный» код: им обозначают и антиспам, и запрет relay, и репутационные блокировки, и правила policy/milter. Лечится не «настройкой лимита», а разбором конкретного текста отказа и источника.

Сценарий A: 554 на входе (NOQUEUE reject) — ваши smtpd restrictions/policy

Если Postfix отклоняет на этапе SMTP-диалога, в логе будет NOQUEUE: reject и строка формата 554 5.7.1 .... Типовые причины:

• Попытка relay без авторизации.
• Проверки HELO/EHLO, rDNS/PTR и несоответствия имени.
• Отказ policy-сервиса или milter (антиспам/серые списки/скоринг).

Что сделать по делу:

• Найти отказ по IP: строка содержит client= и причину.
• Снять активную конфигурацию Postfix: postconf -n.
• Проверить ограничения в smtpd_*_restrictions и исключения для доверенных источников (сайт, CRM, мониторинг), но без «широких белых списков».

Если проблема связана с брутфорсом/подбором паролей и из-за этого вы ужесточали правила, часто помогает нормальная автоматизация блокировок. По теме можно использовать: настройка Fail2ban для Postfix и Dovecot.

Сценарий B: 554 при исходящей доставке — вас отклонил внешний MX

Когда postfix/smtp получает 554 от удалённого сервера, это почти всегда «политика получателя»: репутация IP, несоответствие SPF/DKIM/DMARC, подозрительный контент, превышение частоты, требования к PTR/HELO. Dovecot тут ни при чём.

Практический подход: выписать точный текст ответа, сопоставить с вашей схемой отправки и доменной аутентификацией, затем менять поведение/настройки точечно (а не «вдруг пройдёт»).

Dovecot: лимит соединений и проблемы клиентов (mail_max_userip_connections)

Иногда «письма не приходят/не синхронизируются» путают с SMTP-ошибками, а проблема на самом деле в IMAP/POP3: один пользователь с одного IP (часто NAT офиса) открывает слишком много одновременных соединений. Dovecot ограничивает это параметром mail_max_userip_connections.

Как это выглядит в симптомах

• Клиенты «то подключаются, то нет», периодические отваливающиеся сессии.
• В логах Dovecot сообщения о превышении лимита соединений.
• По сети видно много TCP-сессий к 143/993/110/995.

Проверить лимит и оценить число соединений

doveconf -n | grep -E "mail_max_userip_connections"

ss -tnp | grep -E ':(143|993|110|995) ' | head

ss -tn | grep -E ':(143|993|110|995) ' | wc -l

Как безопасно поднять mail_max_userip_connections

Поднимайте лимит только после понимания, почему соединений много (несколько устройств, агрессивный polling, зависшие клиенты). На офисном NAT один IP может обслуживать десятки устройств — но бесконтрольный рост сессий быстро упирается в память, IO и лимит открытых файлов.

Пример значения (подбирайте по нагрузке):

mail_max_userip_connections = 20

Обычно это задают в /etc/dovecot/conf.d/10-mail.conf (или вашем файле с лимитами). Применение:

systemctl reload dovecot

Если после повышения стало хуже (рост соединений, нагрузка, задержки), верните значение назад и ищите первопричину: зависшие клиенты, неправильные таймауты, проблемы сети или слишком частая проверка почты.

Согласование лимитов Postfix и Dovecot: типичные ловушки

Размер письма — это цепочка ограничений

• Postfix: message_size_limit.
• Фильтры (антивирус/антиспам): часто имеют свои ограничения по размеру/архивам.
• Веб-интерфейсы: лимиты upload на стороне приложения и веб-сервера.
• Внешние провайдеры: их лимиты действуют независимо от ваших настроек.

Цель — не «сделать безлимит», а выбрать разумный максимум (обычно 25–50 МБ) и объяснить пользователям, что большие файлы лучше отправлять ссылкой, а не вложением.

Квоты — лучше один источник истины

Если квоты контролирует Dovecot, часто логично держать mailbox_size_limit в Postfix равным 0, чтобы не ловить конфликтующие отказы. Если же квоты управляются иначе (например, на уровне ФС/хранилища) — согласуйте политику, чтобы пользователю не приходили разные ошибки «в разное время».

Соединения — проверьте ресурсы ОС

При увеличении mail_max_userip_connections убедитесь, что хватает системных лимитов и ресурсов:

• открытые файлы: ulimit -n и лимиты systemd,
• память,
• диск и IO (особенно Maildir с большим числом файлов).

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Алгоритм: как чинить 552/554 за 15 минут

1. Определите фазу по логу: smtpd (вход), lmtp/local (локальная доставка), smtp (исход на внешний MX). Признак входного отказа — NOQUEUE.

2. Снимите полный текст ответа (строку с 552/554). Там обычно уже написано: size limit, quota, policy, spam.

3. Если размер: проверьте message_size_limit и наличие переопределений в master.cf; согласуйте лимит с остальными слоями.

4. Если квота/диск: df -h, df -i, квоты Dovecot, права на mailbox.

5. Если соединения: проверьте Dovecot-логи и mail_max_userip_connections, оцените число IMAP/POP3-сессий, поднимайте умеренно.

6. Если 554/552 от внешнего MX: это требования получателя. Начинайте с текста отказа и аутентификации домена/репутации, а не с «поднятия лимитов».

Шпаргалка команд

Postfix: лимиты и активная конфигурация

postconf message_size_limit

postconf mailbox_size_limit

postconf -n | head -n 200

Поиск 552/554 и маркеров отказа в логах

grep -E " (552|554) " /var/log/mail.log | tail -n 50

grep -E "NOQUEUE: reject|status=bounced|status=deferred" /var/log/mail.log | tail -n 120

Dovecot: лимит и базовая диагностика соединений

doveconf -n | grep -E "mail_max_userip_connections"

ss -tn | grep -E ':(143|993|110|995) ' | wc -l

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

Можно ли поставить message_size_limit = 0, чтобы убрать 552?

Не стоит. «Безлимит» в SMTP повышает риск DoS по памяти/диску/очереди и не гарантирует доставку: внешние провайдеры всё равно ограничивают размер. Практичнее выбрать адекватный максимум и согласовать его по всей цепочке.

Я увеличил message_size_limit, но 552 осталась. Почему?

Потому что 552 мог вернуть не ваш Postfix: квота Dovecot на LMTP-доставке или внешний MX получателя. Всегда смотрите компонент в логе: smtpd, lmtp или smtp.

Как понять, что виноват mail_max_userip_connections?

В логах Dovecot обычно есть явная строка о превышении лимита соединений, а по сети видно всплеск IMAP/POP3-сессий. Если подняли лимит и стало лучше — обязательно разберите причину всплеска (клиенты, NAT, частота проверки, зависания), чтобы проблема не вернулась в виде нагрузки.

Итог

552 и 554 в Postfix + Dovecot почти всегда лечатся правильной идентификацией фазы и чтением текста ответа. Сначала логи и компонент, потом точечная правка: message_size_limit — для размера, квоты/диск — для переполнения, mail_max_userip_connections — для перегруза по IMAP/POP3. Такой подход экономит часы и снижает шанс «открыть» сервер избыточными послаблениями.