Postfix: ошибка Relay access denied — причины и решение

MAATRIX

Вы отправляете письмо через свой сервер, а в ответ прилетает 554 5.7.1 Relay access denied. Postfix ошибка Relay access denied означает ровно одно: сервер не считает вас тем, кому разрешено пересылать почту на чужой домен. Это защита от превращения вашего хоста в открытый релей для спамеров — и настраивается она несколькими понятными механизмами. Разберём, кто и почему получает этот отказ и как открыть отправку только своим, не открыв её всему интернету.

Что вообще значит «relay»

Релеинг — это пересылка письма, у которого и отправитель, и получатель внешние по отношению к серверу. Принять письмо для своего домена Postfix готов всегда. А вот взять письмо «со стороны» и отправить его на другой чужой домен он согласится только доверенным клиентам. Если бы он делал это для всех, ваш сервер за час занесли бы во все спам-листы, потому что через него погнали бы миллионы чужих писем.

Отсюда логика: Relay access denied — это не поломка, а сработавшая защита. Задача не «отключить проверку», а правильно объяснить Postfix, кто здесь свой. Своими бывают либо клиенты из доверенной сети (mynetworks), либо аутентифицированные по логину и паролю (SASL). Понимание этой развилки экономит часы: почти всегда лечение — добавить клиента в одну из двух категорий, а не ломать безопасность.

Читаем лог и находим клиента

Сначала выясните, кто именно получает отказ и с какого адреса. Журнал называет и IP клиента, и адрес получателя.

tail -f /var/log/mail.log
grep "Relay access denied" /var/log/mail.log | tail

Строка вида NOQUEUE: reject: RCPT from unknown[203.0.113.7]: 554 5.7.1 ... Relay access denied; from=<...> to=<...> говорит всё: клиент 203.0.113.7 пытался отправить письмо на внешний адрес, не будучи авторизованным. Дальше решаете, легитимный это клиент (ваше приложение, почтовый клиент сотрудника) или чужой перебор. Если это ваше приложение на том же сервере, а отказ всё равно есть — значит, оно ходит не через localhost, а через внешний IP, и не попадает в mynetworks. Это очень частый сценарий.

Разрешаем доверенную сеть через mynetworks

Клиенты, чьи адреса перечислены в mynetworks, релеят без пароля. Сюда должны попадать только те, кому вы полностью доверяете: сам сервер, ваша внутренняя подсеть.

postconf mynetworks

Правьте в /etc/postfix/main.cf:

mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/24

Ключевое предупреждение: никогда не пишите сюда 0.0.0.0/0 и не добавляйте широкие внешние диапазоны «чтобы заработало». Это буквально открытый релей — за сутки ваш IP окажется в чёрных списках, и почта перестанет доходить куда-либо вообще. Добавляйте только конкретные адреса и узкие подсети. Если ваше приложение и Postfix на одной машине, заставьте приложение слать через 127.0.0.1 — тогда оно попадёт под 127.0.0.0/8 без всяких паролей. После правки: systemctl reload postfix.

Аутентификация SASL для внешних клиентов

Когда письма шлют пользователи из интернета (почтовый клиент на ноутбуке, мобильное приложение), сеть у них каждый раз новая — в mynetworks их не пропишешь. Для них нужна аутентификация: клиент представляется логином и паролем, и только тогда получает право на релей. Обычно это связка Postfix + Dovecot SASL.

smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

Строка smtpd_relay_restrictions — сердце всей защиты. Читается она сверху вниз: пропустить своих из сети, пропустить авторизованных, всем остальным отказать в релее на чужие домены. Именно reject_unauth_destination в конце и выдаёт то самое Relay access denied — и это правильно, эта строка должна остаться. Ваша цель — не убрать её, а сделать так, чтобы легитимный клиент дошёл до permit_sasl_authenticated раньше. Приём почты по SASL должен идти по порту 587 (submission) с обязательным TLS, чтобы пароль не летел открытым текстом.

Проверяем submission-порт 587

Частая причина отказа у авторизованных клиентов — они стучатся на 25-й порт, где аутентификация может быть выключена, вместо 587-го. Порт 587 (submission) как раз предназначен для отправки почты авторизованными пользователями. Убедитесь, что он включён в master.cf:

submission inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

Проверьте, что порт слушается и принимает соединения:

ss -tlnp | grep -E ':(25|587)'
openssl s_client -connect ВАШ_ХОСТ:587 -starttls smtp

Если 587-й закрыт, клиент вынужден идти на 25-й, где для внешних адресов релей запрещён по определению — отсюда и отказ. Настройте клиентов на 587 с шифрованием STARTTLS, и большинство ошибок исчезнет само.

Когда сервер должен релеить для чужого домена

Иногда релей на «чужой» домен нужен легально — например, ваш сервер служит бэкап-MX или шлюзом для дочернего домена. В этом случае разрешение даётся не всем подряд, а точечно через relay_domains.

relay_domains = partner-domain.com
transport_maps = hash:/etc/postfix/transport

Так вы говорите: для писем в адрес partner-domain.com релеить можно, для всех прочих чужих — нет. Это безопаснее, чем расширять mynetworks, потому что открывает пересылку только для одного конкретного назначения, а не для любого получателя. Не путайте relay_domains (входящие письма, которые мы соглашаемся принять и передать дальше) с mynetworks/SASL (исходящие письма, которые нам приносят клиенты) — это две разные стороны релеинга.

Проверка и типичные грабли

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

postfix check
postconf -n | grep -E 'relay|mynetworks|sasl'
systemctl reload postfix

Типичные грабли: приложение шлёт через внешний IP сервера вместо 127.0.0.1; забыли перезагрузить Postfix после правки; в smtpd_relay_restrictions permit_sasl_authenticated стоит ниже reject_unauth_destination (порядок важен, до разрешения дело не доходит); включили SASL, но не подняли Dovecot-сокет private/auth. Проверяйте по одному, сверяясь с логом после каждой отправки.

Отдельно стоит помнить про совместимость старых и новых параметров. В свежих версиях Postfix за релей отвечает smtpd_relay_restrictions, а в старых конфигах ту же роль играл smtpd_recipient_restrictions. Если у вас смешаны оба, они могут конфликтовать, и вы будете править один, пока решение принимает другой. Оставьте один явный набор правил и держите логику отказа в smtpd_relay_restrictions — так поведение сервера станет предсказуемым, а отладка перестанет напоминать гадание.

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