Debian/Ubuntu: как исправить Source IP address not allowed by ACL в Postfix relayhost

Ошибка Source IP address not allowed by ACL в Postfix почти всегда возникает в сценарии, когда сервер отправляет почту не напрямую, а через внешний relayhost или smarthost. Обычно это выглядит так: локальное приложение передаёт письмо Postfix, тот принимает его в очередь, пытается доставить через внешний SMTP-сервер и получает отказ ещё до нормальной отправки.

Смысл сообщения простой: удалённый SMTP-сервер не разрешает вашему исходящему IP-адресу использовать этот relay по своим правилам доступа. Но на практике причина может быть шире: неверный relayhost, неподходящий порт, отсутствие SASL-аутентификации, не тот исходящий IP после NAT или ограничения по домену отправителя.

На Debian и Ubuntu диагностика одинакова: смотрим логи, проверяем реальные параметры Postfix, сверяем хост, порт, аутентификацию и выясняем, какой IP действительно видит внешняя сторона.

Эта ошибка почти никогда не лечится простым перезапуском Postfix. Сначала нужно понять, какой SMTP-сервер используется, откуда реально идёт соединение и что именно запрещает ACL удалённой стороны.

Как распознать проблему по логам Postfix

Начинать лучше с логов. На Debian и Ubuntu это чаще всего /var/log/mail.log или журнал systemd.

sudo tail -n 100 /var/log/mail.log
sudo journalctl -u postfix -n 100 --no-pager

Ищите имя relayhost, SMTP-код ответа и сам текст Source IP address not allowed by ACL. Важны также порт, queue ID и этап, на котором пришёл отказ.

postfix/smtp[12345]: ABCDE12345: to=<user@example.net>, relay=smtp.provider.tld[203.0.113.10]:587, delay=1.2, delays=0.02/0.01/1/0.2, dsn=5.7.1, status=bounced (host smtp.provider.tld[203.0.113.10] said: 554 5.7.1 Source IP address not allowed by ACL (in reply to RCPT TO command))

По одной строке лога уже можно понять многое:

• на какой хост и порт Postfix действительно подключается;

• проходит ли соединение до стадии RCPT TO;

• есть ли признаки SASL и TLS;

• не маскируется ли под ACL другая политика провайдера.

Если у вас ещё не настроен сам сервер под почтовые отправки через submission, пригодится материал про Postfix submission с SMTP AUTH и TLS: он помогает быстро сверить базовую схему работы.

Что проверить в конфигурации relayhost

Следующий шаг — вывести активную конфигурацию Postfix и убедиться, что relay настроен так, как вы ожидаете.

postconf -n

Минимальный набор параметров для внешнего SMTP relay обычно выглядит так:

relayhost = [smtp.provider.tld]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Здесь есть несколько типичных ошибок. Первая — отсутствие квадратных скобок вокруг хоста в relayhost. Если написать просто smtp.provider.tld:587, Postfix может попытаться делать MX-поиск и уйти не туда, куда вы планировали. Для smarthost обычно используют формат [hostname]:port.

Вторая ошибка — несоответствие между relayhost и записью в smtp_sasl_password_maps. Postfix сопоставляет данные строго, поэтому хост и порт должны совпадать точно.

sudo cat /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo ls -l /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

Пример содержимого файла:

[smtp.provider.tld]:587 username:strongpassword

После изменений перечитайте конфигурацию:

sudo systemctl reload postfix

Именно на этом этапе часто выясняется, что логин и пароль есть, но база sasl_passwd.db не собрана, права неверные или хост в карте отличается от хоста в relayhost.

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

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

Подробнее

Если вы переносите почтовые и веб-сервисы на новый сервер, удобнее работать там, где сеть и исходящие адреса предсказуемы. Для таких задач обычно практичнее использовать VDS с понятной маршрутизацией и полным контролем над Postfix, firewall и outbound-трафиком.

Почему ошибка возникает даже при правильном логине и пароле

Это очень частый сценарий. Администратор уверен, что учётные данные корректны, TLS включён, порт верный, но SMTP-сервис всё равно отвечает ACL-ошибкой. Причина в том, что многие relay-провайдеры проверяют не только логин, но и исходящий IP, домен отправителя, envelope sender и правильный endpoint.

Например, вы мигрировали приложение на новый сервер Debian или Ubuntu, скопировали старый main.cf и sasl_passwd, но новый хост выходит в интернет уже с другого белого IP. Провайдер SMTP не знает этот адрес и блокирует relay. Снаружи это выглядит как странная ситуация: TCP-порт доступен, TLS поднимается, а отправка не работает.

Ещё одна частая история — NAT. Сервер видит у себя внутренний адрес или адрес из облачной сети, а внешний SMTP-сервис видит совершенно другой IP. Если allowlist настроен на старый или другой адрес, вы получите ту же ошибку.

Когда SMTP-провайдер пишет про source IP, ориентироваться нужно не на локальный адрес интерфейса, а на тот внешний IP, с которым соединение реально выходит в интернет.

Как узнать, какой исходящий IP реально использует сервер

Если сервер работает за NAT, с несколькими адресами или через отдельный шлюз, сначала определите маршрут до relayhost.

ip addr
ip route
ip route get 203.0.113.10

Команда ip route get особенно полезна: она показывает, через какой интерфейс и с каким исходным адресом ядро планирует соединение к SMTP-серверу.

Если у узла несколько IP, проверьте параметры smtp_bind_address и smtp_bind_address6.

postconf smtp_bind_address
postconf smtp_bind_address6

При необходимости можно зафиксировать конкретный исходящий IPv4:

sudo postconf -e 'smtp_bind_address=198.51.100.25'
sudo systemctl reload postfix

Но делайте это только если точно понимаете схему маршрутизации. Неправильный адрес в smtp_bind_address даст уже не ACL-ошибку, а таймауты или невозможность соединиться.

Проверка SMTP-подключения вручную

Когда логов недостаточно, полезно повторить подключение к relayhost вручную. Для порта 587 с STARTTLS удобно использовать OpenSSL.

openssl s_client -starttls smtp -crlf -connect smtp.provider.tld:587 -servername smtp.provider.tld

После установки соединения можно проверить ответ на приветствие:

EHLO host.example.com

Если в ответе есть AUTH, это хороший признак. Если же проблемный сервер получает ACL-отказ, а другой сервер или старая машина проходят тот же тест без ошибок, причина почти наверняка в allowlist или политике провайдера.

Типовые причины Source IP address not allowed by ACL

Новый сервер, старый allowlist

После миграции на новый узел SMTP-провайдер по-прежнему ждёт старый IP, поэтому новый сервер блокируется.

Перепутан сервер для submission и сервер для trusted relay

Один endpoint работает для обычных клиентов с AUTH на 587 порту, другой — только для доверенных IP. Если выбрать не тот, получите ACL-отказ.

Несовпадение relayhost и sasl_passwd

Даже небольшое различие в имени хоста или порте может привести к тому, что Postfix не применит нужные учётные данные.

Исходящая отправка идёт с другого IP

Это часто встречается на серверах с несколькими интерфейсами, policy routing или NAT на стороне облака.

Провайдер ограничивает домен отправителя

Иногда текст про ACL скрывает запрет на неподтверждённый sender domain или envelope sender.

Используется порт 25 вместо 587

Для клиентской отправки через relay провайдер может требовать только submission-порт с TLS и AUTH.

Рабочая схема исправления на Debian и Ubuntu

Если нужен короткий и надёжный порядок действий, используйте такой алгоритм:

1. Проверьте фактический relayhost через postconf -n.

2. Сверьте хост и порт с документацией SMTP-провайдера.

3. Убедитесь, что включён smtp_sasl_auth_enable.

4. Проверьте файл /etc/postfix/sasl_passwd и базу .db.

5. Сопоставьте запись в sasl_passwd с точным значением relayhost.

6. Определите реальный внешний IP для соединения к relayhost.

7. Если провайдер использует allowlist, добавьте туда новый IP.

8. Перечитайте конфигурацию и отправьте тестовое письмо.

Пример минимально корректной настройки:

sudo postconf -e 'relayhost=[smtp.provider.tld]:587'
sudo postconf -e 'smtp_sasl_auth_enable=yes'
sudo postconf -e 'smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options=noanonymous'
sudo postconf -e 'smtp_tls_security_level=encrypt'
sudo postconf -e 'smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt'

Файл с логином и паролем:

sudo sh -c 'printf "%s\n" "[smtp.provider.tld]:587 username:strongpassword" > /etc/postfix/sasl_passwd'
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Тестовая отправка:

printf 'Subject: postfix relay test

relay test
' | sendmail -v admin@example.net

Ключ -v полезен тем, что показывает SMTP-диалог подробнее и позволяет быстро увидеть, на каком шаге приходит отказ.

Как отличить проблему Postfix от проблемы провайдера SMTP

Если Postfix подключается к нужному relayhost, доходит до TLS и AUTH, но сервер всё равно отвечает Source IP address not allowed by ACL, почти наверняка ограничение находится на стороне SMTP-провайдера.

Перед обращением в поддержку подготовьте:

• точное время ошибки;

• внешний IP сервера;

• имя relayhost и порт;

• фрагмент лога Postfix с queue ID и SMTP-кодом;

• подтверждение, что используется smtp_sasl_password_maps.

Если после исправления ACL письма уже уходят, но есть проблемы с попаданием в спам или репутацией отправителя, дальше имеет смысл проверить DNS и почтовую аутентификацию. Для этого пригодится статья про настройку SPF, PTR и доставляемости Postfix.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Если вы переносите почтовый домен или разворачиваете новый сервис, не забудьте заранее проверить DNS-записи и делегирование. Для этого может пригодиться регистрация доменов и нормальный контроль над зоной, чтобы быстро править MX, SPF, DKIM и PTR-связанные настройки.

Что делать, чтобы проблема не повторялась

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

• храните настройки relayhost и smtp_sasl_password_maps в системе управления конфигурацией;

• документируйте, нужен ли провайдеру SMTP allowlist по IP;

• фиксируйте исходящий IP только там, где это действительно необходимо;

• после миграции проверяйте тестовую отправку до ввода сервера в продакшен;

• следите за очередью Postfix и bounce-логами, а не только за жалобами приложений.

Итог прост: при ошибке Source IP address not allowed by ACL нужно проверять не только сам Postfix, но и модель авторизации внешнего SMTP relay. Сначала подтвердите правильный smarthost, затем сверьте SASL, после этого выясните реальный исходящий IP и только потом меняйте конфигурацию. В большинстве случаев проблема решается либо обновлением allowlist у провайдера, либо исправлением одной-двух строк в настройках relayhost и smtp_sasl_password_maps.