Postfix “Relay access denied”: виправлення ретрансляції без створення відкритого ретранслятора

October 21, 2025 • February 3, 2026 • Читання: 6 хв • Views: 15

Було корисно?

Це завжди трапляється в найнезручніший момент: ваш додаток намагається надіслати лист для скидання пароля, а Postfix відповідає Relay access denied. Розробники кажуть: «А в мене на ноуті працює». Моніторинг каже, що черга зростає. Вхідна пошта повідомляє, що бізнес незадоволений.

Виправлення рідко буває «включити ретрансляцію для всіх». Правильне рішення — «дозволити ретрансляцію для потрібних речей». Postfix виконує свою роботу: відмовляється стати спам-пушкою. Ваше завдання — пояснити йому, кому дозволено ретранслювати, за яких умов і без зайвої двозначності.

Що насправді означає «Relay access denied»

«Relay access denied» — це спосіб Postfix сказати: «Я отримав повідомлення від клієнта, але за поточною політикою я не готовий переадресувати його до цієї цілі». Це збій політики, а не з’єднання. Сервер може прийняти SMTP-розмову, але відмовляється бути посередником.

Зазвичай це проявляється одним із таких способів:

Під час RCPT TO: 554 5.7.1 <user@remote.tld>: Relay access denied (класично)
У логах Postfix: NOQUEUE: reject: RCPT from ...: 554 5.7.1 ... Relay access denied; from=<...> to=<...>
Стеки додатків: «SMTP 554 Relay access denied»

Postfix вирішує, чи ретранслювати, на основі кількох понять:

Локальні домени отримувачів: речі, які цей сервер доставляє локально (через mydestination та virtual_mailbox_domains).
Домені ретрансляції: домени, для яких сервер готовий робити ретрансляцію (через relay_domains).
Довіра до клієнта: мережі чи ідентичності, яким дозволено ретранслювати (через mynetworks, SASL-автентифікацію, клієнтські TLS-сертифікати тощо).
Обмеження по отримувачу: ланцюжок правил, який вирішує так/ні під час RCPT (зазвичай у smtpd_recipient_restrictions або, у новішому стилі, smtpd_relay_restrictions).

За замовчуванням Postfix займає консервативну позицію: він приймає пошту для локальних доменів і відхиляє ретрансляцію на довільні віддалені домени, якщо клієнт не довірений. Помилка дратує, але це добрий знак, що ваш MTA не робить «масштабного розсилання» для спамерів.

Цитата, яку варто мати на стікері: «Hope is not a strategy.» — Gene Kranz. Політика SMTP така сама: визначайте її, а не сподівайтеся.

Швидкий план діагностики (перевірте це насамперед)

Це частина, яку ви виконуєте під час інцидент-дзвінка, коли хтось питає: «Можемо просто відкрити його?» Ні. Ось найшвидший шлях до відповіді «що зламалося» без відкриття шлюзів ретрансляції.

1) Підтвердьте, де відбувається відмова

Якщо відмова на RCPT TO з кодом 5.7.1, це політика (дозволи на ретрансляцію).
Якщо це на connect або MAIL FROM, у вас інший тип помилки (фаєрвол, вимоги TLS, обмеження відправника).

2) Визначте IP клієнта й домен отримувача

Потрібні IP клієнта й домен, який намагаються ретранслювати. Маючи ці два дані, ви можете вирішити, чи слід довіряти клієнту (mynetworks / SASL) і чи є отримувач локальним/ретранслюваним.

3) Перевірте три налаштування Postfix у цьому порядку

smtpd_relay_restrictions (або smtpd_recipient_restrictions в старих конфігураціях): чи стоять permit_mynetworks і/або permit_sasl_authenticated перед reject_unauth_destination?
mynetworks: чи містить воно клієнта?
mydestination, virtual_mailbox_domains, relay_domains: чи домен отримувача має бути локальним, віртуальним або ретранслюваним?

4) Якщо це сценарій з submission, перестаньте використовувати порт 25

Для користувачів/додатків, які повинні автентифікуватися, використовуйте сервіс submission на 587 (або 465) з SASL-автентифікацією та TLS. Порт 25 — для сервер‑до‑сервера SMTP. Ви можете використовувати його внутрішньо, але робіть це свідомо.

5) Переконайтеся, що ви випадково не створили відкритий ретранслятор

Перш ніж святкувати перемогу, протестуйте ретрансляцію з ненадійної мережі. Потрібний результат: «довірені клієнти можуть ретранслювати; випадкові інтернет‑клієнти не можуть».

Жарт #1: Відкритий ретранслятор — як залишити принтер бейджів у фойє: технічно зручно, духовно катастрофічно.

Основні принципи: дозволити ретрансляцію без перетворення на відкритий ретранслятор

Принцип A: «Довірений клієнт» — вузька категорія

mynetworks має містити лише мережі, які ви контролюєте і які дозволено відправляти пошту в інтернет через вас. Зазвичай це:

Loopback (127.0.0.0/8, [::1]/128)
Приватні підмережі, де розміщені лише сервери (не кав’ярні Wi‑Fi, не вся корпоративна мережа, якщо ви не любите інциденти)
VPN‑підмережа, призначена для серверного трафіку

Не додавайте 0.0.0.0/0. Не кладіть «усі RFC1918» туди, якщо вам не подобається відлагоджувати ноутбук фіндиректора, заражений шкідливим ПЗ.

Принцип B: Аутентифіковані користувачі ретранслюють; неаутентифіковані — ні

Ретрансляція для мобільних користувачів, CI‑раннерів і випадкових контейнерів вирішується через SASL‑автентифікацію на submission (587/465). Увімкніть TLS, вимагайте auth і дозволяйте ретрансляцію для аутентифікованих ідентичностей.

Принцип C: `reject_unauth_destination` — запобіжник

У ланцюжку обмежень reject_unauth_destination запобігає відкритому ретранслятору. Видалення його — не «тимчасове рішення». Це визнання помилки.

Postfix зазвичай оцінює ретрансляцію за допомогою smtpd_relay_restrictions (сучасний) та/або smtpd_recipient_restrictions (легасі). Безпечний шаблон виглядає так:

Дозволити довірені мережі
Дозволити аутентифікованих клієнтів
Відхилити неавторизовані призначення

Принцип D: Визначте, яким має бути ваш Postfix

«Relay access denied» часто виникає тому, що ніхто не вирішив, чи є ця машина:

MX / вхідний сервер (приймає пошту для ваших доменів)
Вихідний релей / smarthost (приймає від внутрішніх клієнтів і пересилає в інтернет)
Обидва (можливо, але вимагатиме акуратного розмежування політик)

Якщо воно й поєднує ролі, розділіть політику слухачів: порт 25 для поведінки MX; порт 587 для аутентифікованої submission; різні обмеження для кожної служби, де потрібно.

Принцип E: Дебажте з уявою SMTP‑транзакції

Рішення про ретрансляцію приймаються під час RCPT. Якщо ви не знаєте, що Postfix думає про клієнта (IP, SASL‑ім’я, стан TLS) і що він думає про домен отримувача (локальний/віртуальний/ретранслюваний), ви гадатимете. Гадання — це спосіб випустити відкритий ретранслятор.

Поширені реальні сценарії та правильне виправлення

Сценарій 1: Внутрішній додаток відправляє через порт 25 і отримує relay denied

Симптом: Сервер додатка на 10.0.2.15 підключається до Postfix і намагається відправити на user@gmail.com; Postfix відхиляє ретрансляцію.

Правильні виправлення:

Бажано: Перенесіть додаток на submission (587) з SASL‑автентифікацією; не покладайтеся на довіру по IP.
Допустимо в контрольованих мережах: Додайте лише той сервер (або його підмережу) у mynetworks.

Сценарій 2: Ваш Postfix — MX, і хтось чекав, що він буде ретранслювати вихідні повідомлення

Симптом: MX приймає вхідну пошту нормально. Вихідні з внутрішніх хостів не йдуть через relay denied.

Виправлення: Визначте: чи має MX бути вашим вихідним ретранслятором? Якщо так, поводьтеся з ним як з таким: увімкніть submission, SASL та політику виходу. Якщо ні — розгорніть окремий релей (рекомендовано) і тримайте MX суворим.

Сценарій 3: Ви неправильно налаштували `mydestination`, і Postfix вважає віддалений домен локальним

Симптом: пошта на user@partner.tld приймається, але потім відбивається локально або потрапляє в місцеві спроби доставки.

Виправлення: Видаліть домени, які вам не належать, з mydestination. Використовуйте relay_domains або транспортні мапи, коли ви дійсно маєте намір ретранслювати певні домени.

Сценарій 4: Ви використовуєте SMTP relayhost від провайдера й бачите relay denied для внутрішніх клієнтів

Симптом: Postfix налаштовано з relayhost = [smtp.provider.tld]:587 і локальні тести працюють, але внутрішні клієнти отримують relay denied.

Виправлення: Ваш Postfix не ретранслює для цих клієнтів. Або додайте їхню мережу до mynetworks (строго), або вимагайте від них SASL‑автентифікацію через submission.

Сценарій 5: Kubernetes/контейнери: вихідний IP не той, що ви думаєте

Симптом: Ви додали підмережу вузла до mynetworks, але relay denied зберігається; логи показують інший IP (NAT, overlay‑мережа).

Виправлення: Довіряйте IP, який реально бачите в логах. Краще: вимагайте auth на submission і припиніть вгадувати overlay‑CIDR.

Практичні завдання: команди, виводи, рішення (12+)

Ось що робити на живій машині. Кожне завдання містить: команду, що означає її вивід і яке рішення ухвалити далі.

Завдання 1: Підтвердьте точну відмову в логах

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log
Jan 03 10:14:22 mx1 postfix/smtpd[18422]: NOQUEUE: reject: RCPT from app1.internal[10.0.2.15]: 554 5.7.1 <user@gmail.com>: Relay access denied; from=<noreply@corp.example> to=<user@gmail.com> proto=ESMTP helo=<app1.internal>
Jan 03 10:14:22 mx1 postfix/smtpd[18422]: disconnect from app1.internal[10.0.2.15] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

Що це означає: IP клієнта — 10.0.2.15. Відмова на RCPT. Проблема політики.

Рішення: Визначте, чи має 10.0.2.15 бути довіреним через mynetworks, чи змусити його аутентифікуватися (submission).

Завдання 2: Перевірте ефективні налаштування Postfix для обмежень ретрансляції

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_relay_restrictions|smtpd_recipient_restrictions|mynetworks|mydestination|relay_domains|virtual_mailbox_domains|inet_interfaces|smtpd_tls_security_level|smtpd_sasl_auth_enable)'
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8 [::1]/128
relay_domains = $mydestination
smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
smtpd_relay_restrictions =
smtpd_sasl_auth_enable = no
smtpd_tls_security_level = may
virtual_mailbox_domains =

Що це означає: Тільки localhost може ретранслювати (mynetworks — loopback). Немає SASL. Обмеження по отримувачу включають reject_unauth_destination (добре).

Рішення: Якщо хочете, щоб внутрішні додатки ретранслювали, або розширте mynetworks, або ввімкніть submission + SASL і тримайте mynetworks вузьким.

Завдання 3: Перевірте, чи IP клієнта в mynetworks (без гадань)

cr0x@server:~$ postconf mynetworks
mynetworks = 127.0.0.0/8 [::1]/128

Що це означає: 10.0.2.15 не довірений.

Рішення: Не додавайте «просто 10.0.0.0/8», якщо не можете захистити таке рішення. Краще — submission з auth для всього, що не в тісно контрольованій підмережі.

Завдання 4: Перевірте конфігурацію на рівні сервісів (submission vs smtp)

cr0x@server:~$ sudo postconf -M | egrep '^(smtp/inet|submission/inet|smtps/inet)'
smtp/inet = smtpd
submission/inet = submission smtpd
smtps/inet = smtps smtpd

Що це означає: Існують служби submission і smtps. Це добре — тепер упевніться, що вони налаштовані вимагати auth і дозволяти ретрансляцію для аутентифікованих клієнтів.

Рішення: Налаштуйте submission з smtpd_tls_security_level=encrypt і smtpd_sasl_auth_enable=yes, плюс обмеження.

Завдання 5: Перевірте які слухачі портів (не припускайте, що systemd зробив це)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|587|465)\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=812,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=812,fd=18))
LISTEN 0      100          0.0.0.0:465       0.0.0.0:*    users:(("master",pid=812,fd=19))

Що це означає: Postfix слухає 25, 587, 465. Це має значення для експозиції.

Рішення: Якщо ця машина не має обслуговувати інтернет на портах submission, обмежте доступ через фаєрвол або inet_interfaces / прив’язку сервісу.

Завдання 6: Налаштуйте безпечну базову політику ретрансляції (сучасний Postfix)

Відредагуйте /etc/postfix/main.cf і встановіть:

cr0x@server:~$ sudo postconf -e 'smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination'
cr0x@server:~$ sudo postconf -e 'smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination'
...output...

Що це означає: Ви помістили два безпечні «дозволи» перед критичним «запереченням».

Рішення: Якщо ви використовуєте обидва параметри, тримайте їх узгодженими. Краще використовувати smtpd_relay_restrictions для логіки ретрансляції, а smtpd_recipient_restrictions для додаткових перевірок, але в реальності ви часто побачите обидва.

Завдання 7: Додайте суворо обмежену внутрішню мережу до mynetworks

cr0x@server:~$ sudo postconf -e 'mynetworks=127.0.0.0/8 [::1]/128 10.0.2.0/24'
cr0x@server:~$ postconf mynetworks
mynetworks = 127.0.0.0/8 [::1]/128 10.0.2.0/24

Що це означає: Тільки підмережа 10.0.2.0/24 може ретранслювати без auth. Не вся дата-центр зона. Не весь корпоративний простір.

Рішення: Якщо не можете чітко визначити невелику підмережу, не робіть довіру по IP. Використовуйте submission + auth.

Завдання 8: Увімкніть SASL‑автентифікацію (на сервері) для submission

На практиці це часто Dovecot SASL. Спочатку переконайтеся, що Postfix вважає SASL увімкненим:

cr0x@server:~$ sudo postconf -e 'smtpd_sasl_auth_enable=yes'
cr0x@server:~$ sudo postconf -e 'smtpd_sasl_type=dovecot'
cr0x@server:~$ sudo postconf -e 'smtpd_sasl_path=private/auth'
cr0x@server:~$ sudo postconf smtpd_sasl_auth_enable smtpd_sasl_type smtpd_sasl_path
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Що це означає: Postfix буде звертатися до Dovecot для автентифікації клієнтів.

Рішення: Якщо у вас немає Dovecot, не копіюйте ці значення сліпо. Використовуйте Cyrus SASL або стек автентифікації, який підтримує ваша платформа. Рішення — «аутентифікація існує і працює» перед тим, як покладатися на неї.

Завдання 9: Вимагайте шифрування й автентифікацію на submission

Відредагуйте /etc/postfix/master.cf для override сервісу submission (приклад):

cr0x@server:~$ sudo postconf -P 'submission/inet/smtpd_tls_security_level=encrypt'
cr0x@server:~$ sudo postconf -P 'submission/inet/smtpd_sasl_auth_enable=yes'
cr0x@server:~$ sudo postconf -P 'submission/inet/smtpd_client_restrictions=permit_sasl_authenticated,reject'
...output...

Що це означає: Submission вимагає TLS і auth (або відкидає). Це суттєво зменшує можливість зловживань.

Рішення: Якщо ваші клієнти не вміють TLS, оновіть їх. Не знижуйте безпеку сервера задля старих бібліотек, якщо вам не подобається ризик.

Завдання 10: Перезавантажте Postfix безпечно й перевірте помилки конфігурації

cr0x@server:~$ sudo postfix check
postfix/postfix-script: warning: /etc/postfix/main.cf: unused parameter: smtpd_relay_restrictions
cr0x@server:~$ sudo systemctl reload postfix
...output...

Що це означає: Попередження підказує, що ваша версія Postfix або шлях конфігурації можуть не використовувати цей параметр, або він перекритий налаштуваннями служби.

Рішення: Не ігноруйте попередження. Підтвердьте версію Postfix і переконайтеся, що ви редагуєте правильний файл конфігурації. За потреби використовуйте параметр, який підтримує ваша версія (smtpd_recipient_restrictions на старих збірках).

Завдання 11: Підтвердьте версію Postfix і очікувані можливості

cr0x@server:~$ postconf mail_version
mail_version = 3.5.23

Що це означає: Досить нова версія, щоб зазвичай використовувати smtpd_relay_restrictions. Якщо ви бачили «unused parameter», щось інше не так (опечатка, неправильний файл, chroot, паковані значення за замовчуванням).

Рішення: Перевірте шлях до живого конфіг‑файлу і впевніться, що редагуєте правильний екземпляр (контейнери, кілька інсталяцій Postfix тощо).

Завдання 12: Протестуйте політику SMTP з довіреного хоста (позитивний тест)

cr0x@server:~$ swaks --to user@gmail.com --from noreply@corp.example --server mx1 --port 25
=== Trying mx1:25...
=== Connected to mx1.
<-  220 mx1 ESMTP Postfix
 -> EHLO app1.internal
<-  250-mx1
<-  250 PIPELINING
 -> MAIL FROM:<noreply@corp.example>
<-  250 2.1.0 Ok
 -> RCPT TO:<user@gmail.com>
<-  250 2.1.5 Ok
...output...

Що це означає: Ретрансляція тепер працює з тестованого клієнт‑середовища.

Рішення: Зробіть негативний тест із ненадійної мережі. Успіх без цього — не успіх.

Завдання 13: Переконайтеся, що ви не відкритий ретранслятор (негативний тест)

cr0x@server:~$ swaks --to victim@remote.tld --from attacker@remote.tld --server mx1 --port 25 --ehlo evil.remote.tld
=== Trying mx1:25...
=== Connected to mx1.
<-  220 mx1 ESMTP Postfix
 -> EHLO evil.remote.tld
<-  250-mx1
 -> MAIL FROM:<attacker@remote.tld>
<-  250 2.1.0 Ok
 -> RCPT TO:<victim@remote.tld>
<-  554 5.7.1 <victim@remote.tld>: Relay access denied
...output...

Що це означає: Ненадійний клієнт не може ретранслювати на віддалений домен. Це бажаний результат.

Рішення: Якщо цей тест пройшов успішно (тобто повідомлення пройшло), у вас інцидент, а не функція.

Завдання 14: Перевірте класифікацію домену отримувача (локальний чи ретранслюваний)

cr0x@server:~$ postconf mydestination relay_domains virtual_mailbox_domains
mydestination = $myhostname, localhost.$mydomain, localhost
relay_domains = $mydestination
virtual_mailbox_domains =

Що це означає: Сервер вважає локальними лише своє ім’я хоста/localhost. Він не ретранслює для конкретних доменів за замовчуванням.

Рішення: Якщо ви очікуєте, що він приймає пошту для corp.example, додайте його до mydestination (локальна доставка) або налаштуйте віртуальні домени. Якщо ви хочете ретранслювати corp.example на інший бекенд, використовуйте relay_domains та транспорт.

Завдання 15: Перегляньте чергу, щоб відрізнити «відхиляє» від «приймає, але збоїть далі»

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
B3C2A1D4F9      1249 Fri Jan  3 10:18:01  noreply@corp.example
                                         user@gmail.com

-- 1 Kbytes in 1 Request.

Що це означає: Це повідомлення було прийняте й поставлене в чергу; проблема може бути тепер у вихідній доставці (DNS, заблокований порт 25, автентифікація relayhost), а не в дозволі на ретрансляцію.

Рішення: Якщо пошта стоїть у черзі, ви вже пройшли стадію «relay access denied». Переключіть усунення несправностей на логи вихідної доставки та мережевий egress.

Завдання 16: Прослідкуйте одне повідомлення в черзі від початку до кінця

cr0x@server:~$ sudo postcat -q B3C2A1D4F9 | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_size:            1249            1249
message_arrival_time:    Fri Jan  3 10:18:01 2026
sender: noreply@corp.example
*** MESSAGE CONTENTS ***
Received: from app1.internal (app1.internal [10.0.2.15])
        by mx1 (Postfix) with ESMTP id B3C2A1D4F9
        for <user@gmail.com>; Fri,  3 Jan 2026 10:18:01 +0000 (UTC)
Subject: test
...output...

Що це означає: Підтверджує особу клієнта і отримувача, корисно для аудиту й доведення, який хост відправляв.

Рішення: Якщо ви бачите несподіваний хост‑відправник, ваша межа довіри по IP неправильна. Виправте mynetworks і фаєрвол, потім дослідіть той хост.

Три короткі історії з корпоративних поштових рубежів

Міні‑історія 1: Інцидент через неправильне припущення

У них був VM‑релей, який усі вважали «працюючою інфраструктурою»: він існував — отже, працював. Команда додатків розгорнула новий сервіс в іншій підмережі після реорганізації мережі. Та ж дата-центрова зона, та сама компанія, інший CIDR.

Розгортання було чистим, доки не прийшов перший лист для скидання пароля. Postfix відповів «Relay access denied», і сервіс деградував так, ніби це збій автентифікації. Інженер on‑call дивився в код, бо «SMTP — це просто ще один HTTP‑запит, так?» Ні, це не так.

Неправильне припущення було простим: mynetworks нібито включало «усі внутрішні мережі». Насправді там було саме одне /24 з давніх часів, а єдина документація — коментар у конфігураційному файлі, який ніхто не читав.

Виправили, додавши нову підмережу в mynetworks. Друге, важливіше виправлення — перенесли додатки на аутентифікований submission на 587 і звузили mynetworks до кількох інфраструктурних машин. Менше винятків по IP — менше сюрпризів у майбутньому.

Міні‑історія 2: Оптимізація, що повернулася боком

Інша компанія вирішила «зменшити складність», використовуючи один екземпляр Postfix для всього: вхідний MX, вихідний релей і внутрішні сповіщення. Один сервер, одна IP, одне місце для патчів. Діаграма виглядала чудово.

Вони оптимізували й політику. Хтось вирішив, що ланцюжок обмежень «занадто суворий» для внутрішніх додатків і посипав навколо себе правила permit, поки пошта не почала текти. Реліз відбувся в п’ятницю, бо звісно.

У вихідні той сервер почав шлити багато листів. Не їхню пошту. Частина проходила від дивних IP‑адрес, які вважалися «внутрішніми» через пул VPN‑клієнтів і надто широке mynetworks. Коли спамери знаходять відкритий ретранслятор, вони не зберігають це в секреті.

Вранці понеділка репутація IP впала, легітимна пошта стала відкладатися, а черги виходу вибухнули. Вони «оптимізували» себе в інцидент з репутацією. Виправлення було нехитрим: розділити вхідні й вихідні ролі, звузити mynetworks, вимагати SASL на submission і тримати reject_unauth_destination там, де треба.

Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію

Велике підприємство мало шар релеїв, який майже ніколи не потрапляв у заголовки. Це було навмисно. Вони ставилися до нього як до будь‑якої продакшн‑системи: контроль змін, менеджмент конфігурацій і нудний, але ефективний рукопис процедур.

Одного дня команда безпеки внесла зміну до мережевого ACL, яка ненавмисно спричинила NAT‑шлях для певних підмереж. Раптом логи Postfix показали клієнтські IP з іншого діапазону. Ретрансляція зупинилася для кількох сервісів, але радіус проблем залишився малим, бо ніхто не покладався на «всю внутрішню мережу» як на довірену.

On‑call дотримався рукопису: перевірив логи на предмет IP клієнта, перевірив наявність у mynetworks, підтвердив роботу submission‑auth, потім вирішив, чи тимчасово додати вузький CIDR. Вони додали /28 як тимчасове рішення і створили тикет для виправлення NAT‑шляху.

Оскільки в рукописі був негативний тест на відкритий ретранслятор, вони також перевірили, що сервер усе ще відкидає зовнішні запити. Ніякого відкритого ретранслятора, ніякої шкоди репутації, ніякої паніки. Нудне виявилося кращим.

Цікаві факти й історичний контекст (8 пунктів)

Відкриті ретранслятори колись були звичними. Ранній інтернет покладався на добру поведінку; зловживання змусили MTA жорсткішати за замовчуванням.
Postfix створили як безпечнішу альтернативу Sendmail. Wietse Venema проєктував його з орієнтацією на безпеку: множинні процеси, мінімальні привілеї і межі ізоляції.
Позиція індустрії змінилася на початку 2000‑х. Великі провайдери почали активно блокувати або заносити у списки відкриті ретранслятори, змушуючи адміністраторів приймати жорсткіші політики.
reject_unauth_destination став центральним елементом. Це фактично «не ретранслюй, крім випадків явного дозволу», що є єдино розумним за замовчуванням сьогодні.
Порт 587 з’явився через безлад на порту 25. Submission стандартизували, щоб кінцеві користувачі могли автентифікуватися й відправляти пошту без плутанини з сервер‑до‑сервер SMTP.
RBL змінювали операційну поведінку. Реєстри в реальному часі дали приймачам змогу швидко карати погану поведінку; інколи занадто швидко.
NAT і контейнери ускладнили «довіру по IP». Сучасна інфраструктура зменшує достовірність твердження «цей IP = той хост»; автентифікація масштабується краще.
«Relay denied» часто є сигналом успіху. Це означає, що ваш MTA відмовився бути зброєю — поки ви не налаштували його неправильно.

Поширені помилки: симптом → корінь проблеми → виправлення

Цей розділ навмисно конкретний. Якщо ви впізнаєте свій симптом, отримаєте виправлення, яке не перетворює ваш поштовий сервер на громадський сервіс.

Помилка 1: «В мене працює локально, але не з інших серверів»

Симптом: sendmail з хоста Postfix працює; віддалі сервери отримують Relay access denied.
Корінь проблеми: mynetworks містить лише loopback або обмеження не дозволяють вашому внутрішньому CIDR.
Виправлення: Додайте вузький CIDR у mynetworks або вимагайте submission‑auth. Не розширюйте до «усього приватного простору».

Помилка 2: «Ми прибрали reject_unauth_destination і це вирішило проблему»

Симптом: Пошта стала текти, а потім репутація впала. Або моніторинг показує незвичний обсяг вихідної пошти.
Корінь проблеми: Ви створили відкритий ретранслятор (або майже).
Виправлення: Поставте reject_unauth_destination назад. Додайте permit_mynetworks і permit_sasl_authenticated перед ним. Тестуйте негативний сценарій з ненадійних мереж.

Помилка 3: «Ми додали наш домен у mydestination, щоб він ретранслювався»

Симптом: Пошта для домену приймається, але доставляється локально, відбивається або потрапляє в неправильний механізм ящиків.
Корінь проблеми: Плутанина між «локальною доставкою» і «ретрансляцією для домену».
Виправлення: Використовуйте relay_domains і транспортні мапи, якщо ви ретранслюєте до іншої поштової системи; mydestination — тільки для локальної доставки.

Помилка 4: «Ми довірили всю VPN‑підмережу»

Симптом: Випадкові кінцеві точки можуть відправляти зовнішню пошту без auth; безпека тривожиться справедливо.
Корінь проблеми: Пули VPN‑клієнтів — не «сервери». Довіра по IP — некоректна межа.
Виправлення: Вимагайте SASL‑автентифікацію для віддалих користувачів; видаліть діапазони VPN‑клієнтів з mynetworks.

Помилка 5: «Ми увімкнули submission, але ретрансляція все одно відкидається»

Симптом: Клієнт аутентифікується (або думає, що аутентифікується) на 587, але RCPT все ще отримує relay denied.
Корінь проблеми: Відсутній permit_sasl_authenticated у ланцюжку обмежень ретрансляції для тієї служби, або service override для submission фактично не вимагає auth.
Виправлення: Додайте permit_sasl_authenticated до smtpd_relay_restrictions і/або override submission; підтвердьте в логах появу sasl_username=.

Помилка 6: «Ми додали підмережу, але Postfix все одно каже relay denied»

Симптом: Ви додали 10.0.2.0/24, але логи показують клієнта як 10.244.3.18 або якесь NAT IP.
Корінь проблеми: NAT, proxy, overlay‑мережі або додаток не надсилає з того місця, де ви думаєте.
Виправлення: Довіряйте тому, що показують логи Postfix. Відкоригуйте mynetworks або припиніть довіряти IP і перейдіть на auth‑базований submission.

Помилка 7: «Ми використали relayhost і думали, що клієнти зможуть ретранслювати»

Симптом: Postfix може відправляти зовнішні листи при локальному запуску, але внутрішні клієнти отримують relay denied.
Корінь проблеми: Налаштування relayhost впливає на вихідну доставку від самого Postfix; воно не авторизує вхідних клієнтів автоматично.
Виправлення: Налаштуйте авторизацію вхідних клієнтів (mynetworks або submission‑auth) окремо.

Жарт #2: SMTP простий, поки в нього не встрять люди, після чого він перетворюється на інтерпретативний танець з логами.

Чеклісти / покроковий план

Покроково: Виправлення relay denied для внутрішніх серверів (модель довіри по IP)

Визначте IP клієнта з логів (tail -n 50 /var/log/mail.log).
Розв’яжіться, чи слід довіряти клієнту (чи це сервер, який ви контролюєте, патчений і моніториться?).
Додайте вузький CIDR до mynetworks (переважно /32 або /28–/24, не /8).
Переконайтеся, що обмеження містять: permit_mynetworks, потім reject_unauth_destination.
Перезавантажте й протестуйте з довіреного хоста (позитивний тест).
Протестуйте з ненадійного хоста (негативний тест), щоб підтвердити, що не сталося відкритого ретранслятора.
Задокументуйте CIDR і власника (майбутній ви буде дякувати за це).

Покроково: Виправлення relay denied для користувачів/додатків (модель auth через submission)

Увімкніть submission (587) і забезпечте, щоб він слухав лише там, де передбачено (фаєрвол/прив’язка).
Вимагайте TLS на submission (smtpd_tls_security_level=encrypt для тієї служби).
Увімкніть SASL‑автентифікацію (Dovecot або Cyrus) і перевірте логування аутентифікації.
Дозвольте ретрансляцію для аутентифікованих (permit_sasl_authenticated перед reject_unauth_destination).
Опціонально обмежте ідентичності відправників для користувачів/додатків, щоб зменшити ризик зловживань.
Протестуйте з реальним клієнтом, який аутентифікується і відправляє на віддалений домен.
Запустіть негативний тест на відкритий ретранслятор на порту 25 з ненадійних мереж.

Покроково: Розділення прийому (MX) і вихідного релею (краща практика)

Тримайте MX суворим: порт 25 відкритий, без загальної ретрансляції, приймає лише ваші вхідні домени.
Розгорніть вихідний релей: приймає з внутрішніх мереж і/або через submission‑auth, пересилає зовні.
Розділіть репутації IP: вихідна IP може мати ліміти та моніторинг окремо.
Використовуйте явну маршрутизацію: внутрішні клієнти звертаються до релею; MX не стає catch‑all.
Аудитуйте обидва: логи, поведінка черги та рівень відмов ретрансляції дають чіткі сигнали.

FAQ (питання, які люди справді задають)

1) Що робить `reject_unauth_destination` насправді?

Воно відхиляє отримувачів, які не входять у ваші локальні/віртуальні/relay‑домени, якщо клієнт не авторизований для ретрансляції. Це головне правило запобігання відкритому ретранслятору в багатьох Postfix‑налаштуваннях.

2) Чи безпечно додавати підмережу додатку в `mynetworks`?

Це може бути безпечно, якщо підмережа містить лише контрольовані сервери (не кінцеві пристрої) і у вас сильна захищеність хостів. Ризик є, коли мережі спільні, динамічні або включають VPN‑клієнтів. Auth на 587 масштабується краще.

3) Чому не просто дозволити ретрансляцію для всіх RFC1918?

Тому що RFC1918‑діапазони з’являються там, де ви не очікуєте: пул VPN, неправильно налаштований NAT, лабораторні мережі, випадково мостовані в прод, і інколи атакуючий з внутрішньою присутністю. Широкі межі довіри погано старіють.

4) Чи виправити це, встановивши `relay_domains = *`?

Ні. Це класичний шлях до «ми фактично стали відкритим ретранслятором». Relay domains визначають, для яких доменів ви будете ретранслювати як сервіс; вони не замінюють авторизацію клієнтів.

5) Мої користувачі віддалені. Чи потрібно відкривати порт 25 вхідний?

Для submission користувачів — ні. Використовуйте порт 587 (або 465) з TLS і auth. Порт 25 — для сервер‑до‑серверу. Якщо ви керуєте MX, тоді потрібен порт 25 для інтернет‑доставки.

6) Я увімкнув SASL, але досі relay denied. Що шукати в логах?

Шукайте sasl_username= у логах smtpd під час сесії. Якщо його немає — автентифікація не відбулася. Якщо він є — переконайтеся, що permit_sasl_authenticated входить до ланцюжка обмежень ретрансляції для тієї служби.

7) Чи можна дозволити ретрансляцію лише до певних зовнішніх доменів?

Так. Це політичний вибір: використовуйте перевірки політики (recipient access maps), щоб дозволяти лише затверджені зовнішні домени для неаутентифікованих клієнтів, а для всього іншого вимагайте auth. Будьте обережні: ви створюєте набір правил, який доведеться підтримувати під тиском.

8) Як зрозуміти, чи я випадково створив відкритий ретранслятор?

Протестуйте з ненадійної мережі: спробуйте відправити від недомашнього відправника до недомашнього отримувача через ваш сервер. Правильний результат — відхилення на RCPT з Relay access denied (або схожим повідомленням). Також стежте за логами на незвичний обсяг виходів і невідомі IP‑адреси.

9) Чому Postfix інколи відхиляє «Relay access denied» навіть для мого домену?

Якщо домен не указано в mydestination або virtual_mailbox_domains (або не налаштовано як relay‑домен), Postfix трактує його як не‑локальний і застосовує правила ретрансляції. Спочатку виправте класифікацію домену.

10) Чи варто запускати вхідні й вихідні ролі на одному екземплярі Postfix?

Можна, але ви погоджуєтеся на складність політик. Якщо є можливість — розділіть ролі: MX‑вхід і вихідний релей мають різні ризики й операційні вимоги.

Висновок: практичні наступні кроки

«Relay access denied» — це не Postfix, який ускладнює життя. Це Postfix, що відмовляється стати чимось на кшталт інструмента спамерів. Ваше виправлення — чітко визначити, кому дозволено ретранслювати і як: вузька довіра по IP для контрольованих серверів, аутентифікований submission для усього іншого, і reject_unauth_destination має залишатися на своєму місці.

Наступні кроки, які ви можете виконати сьогодні:

Витягніть один реальний рядок лога і визначте IP клієнта + домен отримувача.
Вирішіть, чи повинен цей клієнт бути довіреним по IP. Якщо сумніваєтеся — вимагайте auth.
Застосуйте безпечний ланцюжок обмежень і перезавантажте Postfix, спочатку запустивши postfix check.
Запустіть обидва тести: «довірений клієнт може ретранслювати» і «ненадійний клієнт не може».
Опишіть політику в одному абзаці і покладіть поруч з конфігом. Майбутній ви буде втомленим і вдячним.