Повідомлення «Recipient address rejected»: чому дійсні користувачі все одно отримують повернення

Що насправді означає «Recipient address rejected»

Коли ви бачите «Recipient address rejected», ви не бачите одного стандартизованого повідомлення. Ви бачите інтерпретацію відмови від відправника під час SMTP-розмови—зазвичай у відповідь на RCPT TO: команду.

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

Типові статус-коди SMTP, які ви побачите

• 550 5.1.1 — користувач невідомий / поштова скринька недоступна (або система прикидається).
• 550 5.1.0 / 5.7.1 — політична відмова, яку можуть помилково маркувати як «address rejected».
• 551 / 553 — часто «не місцевий» або проблеми з синтаксисом адреси/політикою.
• 450 / 451 / 4.7.1 — тимчасова відмова (greylisting, обмеження швидкості, таймаут бекенда). У UI вони іноді виглядають як «recipient rejected», бо UI не завжди допомагає.

Ключова думка: «Recipient address rejected» не обов’язково означає, що користувач не існує. Це означає, що система прийому відмовилася прийняти пошту для цього отримувача на цей момент, з якоїсь причини. Багато систем за замовчуванням застосовують відмови на етапі отримувача як зручне місце для виконання політики.

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

Де відмова відбувається в SMTP (і чому це важливо)

SMTP — це діалоговий протокол. Це важливо, тому що на кожному етапі свої регулювання, свої логи і свої наслідки.

Релевантні етапи розмови

1. Connect / banner: ваш edge вітається. Тут може відбутися TLS-узгодження. Саме тут перевірка репутації IP може вбити з’єднання ще до етапу отримувача.
2. EHLO/HELO: можливості. Політичні механізми іноді застосовують перевірки HELO або вимагають TLS перед продовженням.
3. MAIL FROM: конверт-відправник. Рішення SPF/DMARC по вирівнюванню можуть впливати на подальше прийняття, іноді некоректно відтерміновуючись до RCPT.
4. RCPT TO: адреса отримувача. Саме тут зазвичай відбувається «recipient rejected». Перевірки існування отримувача, пошук у каталозі, маршрутизація до бекенд-поштових серверів і фільтри отримувача — все це тригериться тут.
5. DATA: тіло повідомлення. Сканування вмісту, обмеження розміру, перевірка на шкідливе ПЗ. Якщо відмовляють тут, семантика відскоку може виглядати зовсім інакше.

Якщо відмова стається на RCPT, очікуйте немає копії повідомлення на вашому боці (якщо ви навмисно не журнально не копіюєте чи не логируєте). Це означає, що ви налагоджуєтеся через логи та трасування, а не через поштові скриньки.

І так, можливо відмовити на RCPT тому, що ваш бекенд поштових скриньок повільний або недоступний. Системи роблять це, щоб не приймати пошту, яку вони не зможуть доставити. Пошта — це протокол збереження й пересилки, але багато реальних розгортань поводяться як синхронний RPC-сервіс.

Жарт №1: SMTP — єдиний протокол, де «550» може означати «немає такого користувача» і одночасно «у мене поганий день, не питайте чому».

Цікаві факти та історія (коротко, корисно)

• Факт 1: SMTP з’явився до сучасних систем ідентифікації; він призначався для співпраці, а не для екосистеми проти-спаму. Багато проблем «recipient rejected» — це політичні нашивки на старий протокол.
• Факт 2: Ідея відмовляти на RCPT стала популярною, бо приймати DATA для спаму дорого — канал, CPU для сканування і I/O диска.
• Факт 3: «Directory harvest attacks» (сканування наявних отримувачів) змусили адміністраторів вимикати перевірки отримувачів або брехати загальними помилками, що потім збиває з пантелику легітимних відправників.
• Факт 4: Greylisting (тимчасові 4xx відмови) був ранньою антиспам технікою, яка експлуатувала те, що добросовісні MTА повторюють спробу. Він досі спричиняє скарги, коли відправники неправильно не повторюють спроби.
• Факт 5: Catch-all скриньки колись були звичайною страховкою. Багато організацій їх вимкнули, щоб зменшити спам, що збільшило кількість жорстких 5xx відмов.
• Факт 6: DNSBL (чорні списки) ефективні в операціях, але можуть давати помилкові спрацьовування, які проявляються як відмови отримувача в залежності від місця застосування перевірок.
• Факт 7: Деякі MTA реалізують «callout» для отримувача (перевіряють отримувача запитом вниз по ланцюгу). Неправильна конфігурація таких callout може перетворити тимчасову повільність бекенда в «користувач невідомий».
• Факт 8: Існують інтернаціоналізовані адреси електронної пошти (SMTPUTF8), але багато систем все ще їх неправильно обробляють. Користувачі з не-ASCII локальною частиною можуть бути «дійсні» всередині і відхилені зовні.
• Факт 9: Великі провайдери дедалі частіше застосовують ліміти за швидкістю та виявлення аномалій, які можуть відхилити на RCPT як сигнал зловживання, а не як заяву про існування отримувача.

Таксономія випадків «дійсний користувач, але повернення»

1) Отримувач існує, але не на цьому сервері

Маршрутизація пошти надзвичайно буквальна. Якщо MX вказує не туди, або шлюз вважає себе авторитативним для домену, яким він не є, отримувач може бути «невідомим», бо питають не той сервер.

Поширені причини:

• MX записи змінилися, але ще не поширилися або кешуються неправильно.
• Split-brain: різні резолвери дають різні відповіді по MX.
• Кілька вхідних шляхів (хмарний фільтр + on-prem) з невідповідними правилами перевірки отримувачів.
• Застарілий список «relay domains» / «local domains» на edge MTA.

2) Перевірка отримувача залежить від пошуку в каталозі, який не працює

На етапі RCPT ваш edge може звертатися до LDAP/AD, SQL, API або плоскої мапи. Якщо цей пошук таймаутиться або повертає помилку, деякі конфігурації відмовляють безпечним способом (reject), а деякі впускають (accept and queue).

Fail-closed безпечніший щодо навантаження спамом. Він також створює серйозний інцидент при відмові каталогу, який інакше був би «просто повільним входом».

3) Поштова скринька існує, але псевдонім — ні

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

Це також відбувається з plus-адресацією, субадресацією і варіаціями з крапочками. Деякі системи їх приймають; деякі нормалізують; деякі відхиляють.

4) Бекенд поштового сховища впав або перевантажений; edge відмовляє на ранньому етапі

Якщо ваш edge перевіряє отримувачів, звертаючись до поштового сервера (LMTP, проксі, callout), то затримка у сховищі може проявитися як SMTP‑відмова отримувача. Тут робота інженера збереження даних стає цікавою у небажаний час.

Якщо метадані скриньок лежать на мережевому сховищі й воно «хворіє» — сплески латентності, майже повний пул, корупція метаданих або збої NFS — перевірки отримувачів можуть провалюватися й ви відмовите дійному користувачу.

5) Надмірно жорсткі правила антиспаму/антизловживань спрацьовують помилково

Політичні двигуни іноді відмовляють на RCPT, бо це дешево. Але коли ви підключаєте логіку вмісту або репутації до RCPT, тексти помилок можуть бути оманливими. «Recipient rejected» стає загальною обгорткою для «ваш IP виглядає підозрілим» або «ви надсилаєте занадто швидко».

6) Проблеми на стороні відправника (а вам все одно дістається звинувачення)

Деякі відправники не повторюють спроби при 4xx. Деякі переписують конверт. Деякі надсилають некоректні команди. Деякі використовують групову відправку, що тригерить обмеження на з’єднання. І деякі системи показують користувачеві загальне «address rejected» незалежно від реальної причини.

Жарт №2: Якщо ви коли-небудь почуваєтесь непотрібним, згадайте, що є поштові клієнти, які приховують SMTP статус-код «щоб усе було просто».

Швидкий план діагностики

Коли ви під тиском часу, вам не потрібна лекція. Потрібно швидко знайти вузьке місце і діяти.

Перше: класифікуйте відскок за фактичним SMTP кодом

• Якщо це 5xx, це жорстка відмова. Припускайте проблему конфігурації/політики, поки не доведете інше.
• Якщо це 4xx, це тимчасова відмова. Припускайте обмеження швидкості, greylisting або збій/латентність бекенда.
• Якщо UI повернення не показує коди, вимагайте сирі заголовки або SMTP‑транскрипт. Ніяких транскриптів — ніякої впевненості.

Друге: підтвердіть маршрутизацію пошти (DNS і володіння edge)

• Перевірте MX через кілька резолверів.
• Підтвердіть, що хост, який відмовляє, дійсно належить вам (або вашому вендору), а не застарілому шлюзу.
• Переконайтеся, що домен налаштовано послідовно на всіх вхідних вузлах.

Третє: відтворіть проблему через SMTP-сесію проти того ж edge

• Використайте openssl s_client для STARTTLS і надішліть ручний RCPT TO.
• Порівняйте поведінку для відомого робочого користувача та для «того, що відбивається».
• Шукайте відмінності: мапінг псевдонімів, регістр символів, субадресація, варіанти домену.

Четверте: прочитайте логи приймача на точці відмови

• Знайдіть точну причину відмови в логах MTA (не у переказаному повідомленні про повернення).
• Визначте, чи відмова прийшла від: мап отримувачів, LDAP, сервісу політики, спам‑фільтра або downstream callout.

П’яте: вирішіть, чи тимчасово відкрити прийом

Якщо каталоги/бекенди ненадійні і у вас є ємність черги, розгляньте тимчасове прийняття й очікування пошти замість відмови на RCPT. Це дає час і захищає бізнес‑трафік. Але й збільшує кількість спаму. Це дорослий компроміс — приймайте свідомо.

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

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

Завдання 1: Перевірте повернення на предмет справжнього SMTP статусу

cr0x@server:~$ grep -E "Status:|Diagnostic-Code:|Final-Recipient:" -n bounce.eml
12:Final-Recipient: rfc822; user@example.com
13:Action: failed
14:Status: 5.1.1
15:Diagnostic-Code: smtp; 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table

Значення: Це жорстка відмова на етапі отримувача, і текст вказує на проблему локального мапінгу отримувачів («virtual mailbox table»).

Рішення: Не витрачайте час на теорії про спам/репутацію. Йдіть одразу до конфігурації перевірки отримувачів і мап.

Завдання 2: Підтвердіть MX записи для домену

cr0x@server:~$ dig +short MX example.com
10 mx1.mailgw.example.net.
20 mx2.mailgw.example.net.

Значення: Вхідна пошта має надходити на ці шлюзи.

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

Завдання 3: Перевірте MX з іншого резолвера (полювання на split-brain)

cr0x@server:~$ dig @1.1.1.1 +short MX example.com
10 mx1.mailgw.example.net.
20 mx2.mailgw.example.net.

Значення: Публічний резолвер погоджується. Добрий знак.

Рішення: Якщо внутрішні резолвери дають інші відповіді, виправте кешування/форвардинг DNS всередині мережі перед зміною поштових конфігів.

Завдання 4: Підтвердіть ідентичність сервера, що відмовляє, і ім’я TLS

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mailgw.example.net:25 -servername mx1.mailgw.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN = mx1.mailgw.example.net
issuer=CN = Example Internal Issuing CA

Значення: Ви спілкуєтесь з очікуваним шлюзом, і сертифікат відповідає.

Рішення: Продовжуйте з живим SMTP‑тестом проти того самого endpoint.

Завдання 5: Ручне відтворення RCPT‑відмови через SMTP

cr0x@server:~$ printf "EHLO test.example.net\r\nMAIL FROM:<probe@test.example.net>\r\nRCPT TO:<user@example.com>\r\nQUIT\r\n" | nc -w 5 mx1.mailgw.example.net 25
220 mx1.mailgw.example.net ESMTP Postfix
250-mx1.mailgw.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
250 2.1.0 Ok
550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table
221 2.0.0 Bye

Значення: Сам шлюз відмовляє отримувачу до DATA. Це не downstream перевірка вмісту.

Рішення: Перевірте Postfix virtual mailbox maps, alias maps, LDAP maps або делегування політики.

Завдання 6: Перевірте, чи адреса присутня в Postfix мапах

cr0x@server:~$ postmap -q "user@example.com" /etc/postfix/virtual_mailbox_maps
mailboxes/example.com/user/

Значення: Мапа містить запис і відображається на шлях до поштової скриньки.

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

Завдання 7: Підтвердіть, які мапи фактично використовує Postfix

cr0x@server:~$ postconf -n | egrep "virtual_mailbox_maps|virtual_alias_maps|relay_domains|mydestination|smtpd_recipient_restrictions"
mydestination = localhost
relay_domains = example.com
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unknown_recipient, reject_unlisted_recipient
virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps
virtual_mailbox_maps = ldap:/etc/postfix/ldap/virtual_mailbox_maps.cf

Значення: Перевірка отримувачів примусова (reject_unlisted_recipient), і mailbox map заснована на LDAP, а не на hash-файлі.

Рішення: Перестаньте редагувати /etc/postfix/virtual_mailbox_maps. Виправте LDAP‑пошук: облікові дані, base DN, фільтр або підключення.

Завдання 8: Протестуйте LDAP‑пошук напряму (перевірка: «чи бреше каталог?»)

cr0x@server:~$ ldapsearch -x -H ldap://ldap1.example.net -b "ou=People,dc=example,dc=net" "(mail=user@example.com)" dn mail
dn: uid=user,ou=People,dc=example,dc=net
mail: user@example.com

Значення: LDAP містить адресу.

Рішення: Якщо Postfix все ще відмовляє, проблема в конфігурації LDAP‑мапи (невідповідність фільтра, ім’я атрибуту, дозволи bind DN) або в періодичних LDAP‑відмовах.

Завдання 9: Перевірте логи Postfix на конкретну причину відмови

cr0x@server:~$ sudo grep -R "reject: RCPT from" /var/log/mail.log | tail -n 5
Jan 04 09:42:11 mx1 postfix/smtpd[28411]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Значення: Відмова відбувається в smtpd з «NOQUEUE» (повідомлення ніколи не приймалося). Це політичне рішення на «приході».

Рішення: Зосередьтеся на переліченні/пошуку отримувачів і обмеженнях; не витрачайте час на пошук повідомлення в черзі.

Завдання 10: Перевірте файл LDAP‑мапи, який використовує Postfix

cr0x@server:~$ sudo sed -n '1,120p' /etc/postfix/ldap/virtual_mailbox_maps.cf
server_host = ldap1.example.net
search_base = ou=People,dc=example,dc=net
query_filter = (mail=%s)
result_attribute = mail
bind = yes
bind_dn = cn=postfix,dc=example,dc=net

Значення: Ця мапа повертає атрибут mail. Це підходить для перевірки наявності, але не завжди для маршрутизації пошти.

Рішення: Якщо Postfix очікує шлях призначення/шаблон поштової скриньки, а ви повертаєте саму електронну адресу, ви можете отримати «unknown in virtual mailbox table». Узгодьте result_attribute з тим, як ви доставляєте (наприклад, атрибут шляху maildir), або використовуйте окремі мапи для перевірки існування та для призначення.

Завдання 11: Перевірте таймаути бекенда, які маскуються під «unknown user»

cr0x@server:~$ sudo journalctl -u postfix -S "10 min ago" | egrep -i "timeout|ldap|defer|reject" | tail -n 20
Jan 04 09:40:02 mx1 postfix/ldap[28122]: warning: ldap_search: Timeout
Jan 04 09:40:02 mx1 postfix/smtpd[28115]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 450 4.1.1 <user@example.com>: Recipient address rejected: temporary lookup failure; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Значення: LDAP‑пошук таймаутиться; відмова тимчасова (4xx). Деякі відправники все одно покажуть це як «повернення».

Рішення: Розглядайте це як порушення SLO залежності: виправте латентність/підключення LDAP. Розгляньте fail-open або кешування для перевірок існування отримувачів.

Завдання 12: Перевірте, чи ви застосовуєте greylisting або ліміти швидкості на RCPT

cr0x@server:~$ sudo grep -R "greylist\|rate\|policyd\|postscreen" /var/log/mail.log | tail -n 10
Jan 04 09:41:09 mx1 postfix/smtpd[28307]: warning: unknown[203.0.113.77]: SASL LOGIN authentication failed: authentication failure
Jan 04 09:41:12 mx1 postfix/smtpd[28411]: NOQUEUE: reject: RCPT from sender-gw.remote.net[203.0.113.77]: 451 4.7.1 Service unavailable - try again later; from=<sender@remote.net> to=<user@example.com> proto=ESMTP helo=<sender-gw.remote.net>

Значення: Відмова 451 4.7.1: тимчасова, ймовірно політична (greylisting, захист від зловживань чи проблеми автентифікації).

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

Завдання 13: Перевірте, чи домен обробляється як локальний/relay коректно

cr0x@server:~$ postconf -n | egrep "mydestination|virtual_mailbox_domains|relay_domains"
mydestination = localhost
relay_domains = example.com, example.org
virtual_mailbox_domains = example.com

Значення: Домен одночасно присутній у relay і virtual mailbox. Це підозріло; може змінити, які перевірки використовуються.

Рішення: Уточніть архітектуру: або ви хостите скриньки (virtual mailbox domains), або ви ретранслюєте на інший кінцевий пункт (relay_domains). Змішана конфігурація часто призводить до відмов для дійсних користувачів на одній з доріг.

Завдання 14: Підтвердіть, що поштова скринька існує на диску

cr0x@server:~$ sudo ls -ld /var/vmail/example.com/user
drwx------ 12 vmail vmail 4096 Jan  4 09:10 /var/vmail/example.com/user

Значення: Maildir існує на диску. Добре.

Рішення: Якщо перевірки отримувачів все ще відмовляють, проблема не в «відсутній папці», а скоріше в мапуванні/пошуку або в дозволах/контексті SELinux.

Завдання 15: Перевірте стан сховища і умови «майже заповнено», які змушують системи відмовляти отримувачів

cr0x@server:~$ df -h /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       2.0T  1.9T   80G  96% /var/vmail

Значення: 96% заповнення тома пошти. Багато MTA і агентів доставки починають поводитися дивно при високому використанні, і деякі політичні шари відмовляють ранньо, щоб уникнути вибуху черги.

Рішення: Невідкладно звільніть місце: розширте, очистіть або перемістіть скриньки. Не налаштовуйте SMTP-помилки, поки сховище сигналить про проблему.

Завдання 16: Перевірте тиск черги (якщо ви приймаєте пошту, але потім відтерміновуєте доставку)

cr0x@server:~$ mailq | tail -n 5
-- 2435 Kbytes in 512 Requests.

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

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

Три корпоративні міні-історії з практики

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

Вони перенесли вхідний фільтр до хмарного шлюзу безпеки пошти. План зміни пройшов, відкочування готове, тести — добре. Команда припустила, що перевірка отримувачів буде ідентичною, бо «це просто форвардинг пошти».

У понеділок вранці частина користувачів почала отримувати відмови від зовнішніх відправників з «550 5.1.1 user unknown». Внутрішньо все виглядало нормально: користувачі могли листуватися між собою і отримували пошту від кількох партнерів. Виглядало випадково — а це завжди довга справа.

Неправильне припущення було тонким: старий edge приймав пошту для всіх отримувачів і дозволяв поштовому рівню вирішувати, що валідне. Новий шлюз робив перевірку отримувачів на RCPT, синхронізуючи фід каталогу. Оновлення фіду відставало. Нові псевдоніми і групи ще не потрапили, і шлюз відхиляв їх як невідомі.

Термінове виправлення було операційним, а не філософським: збільшили частоту синхронізації каталогу і тимчасово відключили строгі відмови для певних шаблонів адрес, поки синхронізація не стабілізувалась. Довгострокове виправлення — управління: будь-яка зміна ідентичності, що впливає на адреси, мусить розглядатися як production‑конфіг і мати гарантії поширення і спостережуваність.

Усі вивчили старий урок ще раз: «форвардинг пошти» — міф. Кожен вузол — точка виконання політики. Якщо ви не знаєте, який вузол авторитативний за існування отримувача, у вас не поштовий сервіс — у вас генератор повернень.

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

Велика організація потерпала від спаму і спроб збору адрес. Хтось запропонував оптимізацію: відхиляти невідомих отримувачів одразу на edge, до сканування контенту. Це зекономило б CPU і диск. Ідея в принципі правильна, але деталях катастрофічна.

Вони реалізували перевірку отримувачів через живі виклики з edge до поштових серверів. Поштові сервери базувались на навантаженому кластері сховища, що час від часу мали сплески латентності під час знімків. Більшість користувачів майже не помічали, бо доставка могла затриматись і врешті відновитись. Але з callout‑ами на RCPT, 300 мс сплеск перетворювався на SMTP таймаут і на відмову.

Раптово під час вікон знімків edge став відхиляти дійсних отримувачів як «невідомих». Зовнішні відправники бачили жорсткі помилки. Внутрішній моніторинг показував «поштові сервери в порядку», бо сервери були запущені, але повільні. Графіки сховища показували сплеск, але ніхто не зв’язував це з поведінкою SMTP, поки SRE не відтворив SMTP‑транскрипт.

Виправлення не полягало в відключенні захисту від спаму. Виправлення — перестати використовувати синхронні залежності бекенду для перевірки існування отримувача. Вони перейшли на кешований список отримувачів на edge з обмеженою застарілістю і налаштували таймаути так, щоб при помилках lookup допустити відкриття при обмеженні швидкості для підозрілих відправників. Також узгодили час знімків сховища та пікові години пошти. Нудна робота узгодження — великий ефект.

Оптимізація — чудово, але тільки коли ви розумієте нові режими відмов, які купуєте. Тут вони поміняли «спам‑навантаження» на «зв’язування систем», де надійність гине.

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

Фінансова команда поскаржилась, що інвойси певному співробітнику повертаються з «recipient address rejected». Співробітник точно існував. Усі чекали довгого дня розкопок пошти.

Команда пошти мала одну нудну практику: кожну вхідну SMTP‑відмову логували з структурованим кодом причини від політичного двигуна, і логи були доступні за отримувачем і IP відправника. Нічого особливого. Просто дисципліноване логування і зберігання.

Вони запитали логи і знайшли, що той самий IP відправника тригерив правило ліміту після сплеску повідомлень до кількох отримувачів. Двигун політик відхилив на RCPT з 451 4.7.1, але система відправника показала це як жорсткий bounce для користувача. Фраза «recipient rejected» була обманом інтерфейсу.

Оскільки у них були точні час, назва правила і SMTP‑код, вони зробили прицільний фікс: тимчасово додали IP до білого списку і попросили партнера налаштувати повторні спроби. Ніяких грубих змін конфігурацій. Інцидент закрили швидко, і команда виглядала «магічно компетентною» — попри те, що вони були просто дисципліновано компетентні.

Спостережуваність — це не гламурно, але це різниця між інцидентом і детективним романом. У продакшені ви хочете інциденти, а не романи.

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

1) Симптом: «550 5.1.1 user unknown» для користувача, який існує

Корінна причина: Edge робить строгі перевірки отримувачів проти застарілого або дефектного каталогу/мапи.

Виправлення: Перевірте, яка мапа авторитативна (postconf -n), протестуйте lookup напряму, виправте синк/LDAP таймаути. Розгляньте кешування і fail-open для помилок lookup.

2) Симптом: Повернення тільки від деяких зовнішніх відправників

Корінна причина: Розділена маршрутизація (різні MX‑цілі), відправник кешує старий MX, або партнер використовує конкретний шлях шлюзу з відмінними політиками перевірки отримувачів.

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

3) Симптом: Лише псевдоніми повертаються; основна адреса працює

Корінна причина: Відсутня мапа псевдонімів, псевдонім видалено або псевдонім не попадає в фід каталогу, який використовує edge.

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

4) Симптом: Випадкові отримувачі повертаються під час пікових годин

Корінна причина: Перевірка отримувача залежить від латентності бекенда (LDAP, callout до поштового сервера, сховище). Таймаути викликають відмови.

Виправлення: Підвищте стійкість: локальний кеш, адекватні таймаути, fail-open для тимчасових помилок, і розділіть throttle‑и за спамом від перевірок існування отримувача.

5) Симптом: «Recipient address rejected», але SMTP код — 5.7.1

Корінна причина: Політична відмова (репутація, автентифікація, вимога TLS, блокування відправника), яка подається з оманливим текстом від UI або шлюзу.

Виправлення: Використовуйте логи/транскрипт. Якщо це політика — налаштуйте її. Не витрачайте час на перевірку поштової скриньки.

6) Симптом: Нові працівники отримують повернення кілька годин після створення

Корінна причина: Затримка поширення ідентичності в пошті (синхронізація каталогу, політика адресної книги, синхронізація хмарного шлюзу). Edge відмовляє, поки дані не приїдуть.

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

7) Симптом: Тільки інтернаціоналізовані адреси відхиляються зовнішньо

Корінна причина: Невідповідність обробки SMTPUTF8/IDN; шлюз або відправник не підтримує UTF‑8 у локальній частині або очікує punycode для доменів.

Виправлення: Забезпечте підтримку SMTPUTF8 кінцю в кінець або уникайте не‑ASCII локальних частин для зовнішніх адрес. Для доменів підтвердьте узгоджені налаштування IDN.

8) Симптом: Користувач існує, але пошта повертається після міграції скриньки

Корінна причина: Атрибут маршрутизації пошти (targetAddress, таблиця маршрутизації пошти або внутрішня транспортна мапа) не оновлений скрізь; деякі шлюзи все ще вказують на старе сховище.

Виправлення: Проведіть аудит атрибутів маршрутизації, забезпечте тимчасові 4xx на старому сховищі замість жорстких 5xx під час міграції, і зберігайте переадресацію/ретрансляцію аж до повної консистентності cutover.

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

Покроково: розбираємо тикет «дійсний користувач повернувся» як дорослі

1. Отримайте сире повернення. Попросіть повні заголовки і SMTP‑діагностичний рядок. Скриншоти — це декорація.
2. Видобудьте: SMTP‑код, хост, що відмовив, часову мітку, отримувача, конверт‑відправника, IP відправника якщо вказано.
3. Підтвердіть маршрутизацію: MX записи і чи хост, що відмовив, на вході відповідно до очікувань.
4. Відтворіть: ручна SMTP‑сесія до хоста, що відмовив; протестуйте і вказаний, і контрольний отримувач.
5. Читайте логи: знайдіть запис NOQUEUE: reject і модуль (smtpd, policy, ldap, postscreen).
6. Визначте ворота: мапи отримувачів, каталог, політичний двигун, ліміт швидкості, callout або маршрутизація вниз по ланцюгу.
7. Виправте ворота: запис мапи, синхронізація псевдонімів, тонке налаштування таймаутів, білий список, здоров’я бекенда або виправлення DNS/маршрутизації.
8. Вирішіть тимчасове пом’якшення: fail-open для lookup, тимчасове прийняття й чергування, або партнери в білому списку.
9. Підтвердіть через той самий відтворювальний тест. Не чекайте, поки партнер «спробує пізніше» без доказу.
10. Занотуйте клас інциденту. Якщо ви не зможете класифікувати наступного разу, ви не виправили проблему як слід.

Чек-лист: вибори архітектури, що зменшують ці інциденти

• Визначте, де перевіряється існування отримувача: edge чи поштовий рівень. Бути явним.
• Якщо перевірка на edge — кешуйте з визначеним вікном застарілості й моніторингом стану синху.
• Розділяйте «невідомий користувач» і «політична відмова» у логах і в SMTP‑відповідях (чіткі enhanced status codes допомагають).
• Надавайте перевагу 4xx при збоях залежностей (LDAP таймаут, callout до поштового сервера). 5xx має означати «це ніколи не спрацює».
• Тримайте вхідні шляхи консистентними (кілька MX, хмарні шлюзи, регіональні edge). Одна й та сама логіка отримувачів скрізь.
• Інструментуйте та зберігайте логи відмов достатньо довго, щоб зіставляти з бізнес‑таймлайнами.
• Моніторинг ємності сховища — це моніторинг пошти, якщо метадані й доставка залежать від нього.

Чек-лист: чого не робити (бо здається продуктивним)

• Не «промивайте DNS» як перший крок. Спочатку перевірте відповіді DNS і поведінку кешування.
• Не вимикайте перевірку отримувачів глобально в паніці без оцінки ризику спам‑потоку.
• Не редагуйте файли мап, якими Postfix не користується (перевірте postconf -n перед змінами).
• Не ігноруйте 4xx; деякі відправники не повторюють спроби, і ви все одно матимете інцидент.
• Не приймайте пошту бездумно, якщо не можете безпечно її поставити в чергу (диск майже повний, черга вже зростає).

Питання й відповіді

1) Якщо користувач може увійти, чому пошта каже «user unknown»?

Бо ідентичність для входу і ідентичність для маршрутизації пошти — це різні системи. Edge може перевіряти інший вигляд каталогу, застарілу синхронізацію або інший атрибут (основна адреса проти псевдоніму).

2) Чи завжди «Recipient address rejected» — наша помилка?

Ні. Це може бути відправник, який не повторює спроби при 4xx, відправник, який використовує застарілий MX, або інтерфейс, що спрощує будь-яку відмову до «адреса відхилена». Ваше завдання — довести, де відмова сталася і чому.

3) Чи слід відхиляти невідомих отримувачів на edge?

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

4) У чому різниця між відмовою на RCPT і після DATA?

Відмова на RCPT відбувається до прийому тіла повідомлення; це дешевше і уникає чергування. Відмова після DATA дає більше контексту (сканування вмісту), але ви вже прийняли більше роботи і можливо доведеться формувати DSN залежно від поведінки.

5) Чому деякі повернення показують 550, але реальна проблема — лімітування швидкості?

Деякі шлюзи використовують загальні 5xx коди для різних політик, а деяке програмне забезпечення відправника згортає кілька помилок у «address rejected». Завжди дивіться на enhanced status code і точний діагностичний текст у логах.

6) Чи справді проблеми зі сховищем можуть спричиняти «recipient rejected»?

Так. Якщо перевірка отримувача залежить від метаданих поштової скриньки на диску або від callout до поштового сервера, який уповільнений через латентність сховища, edge може таймаутитися й відмовити отримувачу.

7) Яке найнадійніше тимчасове полегшення під час збою каталогу?

Якщо у вас є ємність черги: при помилках lookup робіть fail-open (приймайте пошту і відтерміновуйте доставку), при цьому обмежуючи по IP і застосовуючи базові контрзаходи проти зловживань. Якщо немає ємності черги, можливо доведеться тимчасово 4xx‑таймфаїлити.

8) Чому це відбувається лише для нових акаунтів?

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

9) Партнер наполягає, що отримав жорсткий bounce, а ми бачимо 451 тимчасові відмови. Хто правий?

Обидва. Ви повернули тимчасову відмову; їхня система вирішила трактувати це як постійне (або їхній UI так відобразив). Якщо це важливий партнер, попросіть підтвердити поведінку повторних спроб і розгляньте сферичний whitelist.

10) Як уникнути оманливих текстів помилок?

Ви не можете контролювати UI відправників, але можете контролювати свої SMTP‑відповіді. Використовуйте точні enhanced status codes і додавайте коротку причину, що відповідає внутрішньому runbook‑ключу («policy:rate-limit», «lookup:ldap-timeout»).

Висновок: наступні кроки, які реально зробити

«Recipient address rejected» — це не діагноз. Це симптом рішення, прийнятого на етапі RCPT — часто політичною машиною, яка прагне бути ефективною. Ваше завдання — знайти точний gate і вирішити, чи він має бути суворим, кешованим або тимчасово відкритим.

Зробіть наступні кроки:

1. Уніфікуйте спосіб збору повернень: вимагаючи SMTP‑код, хост, що відмовив, і часову мітку.
2. Зробіть перевірку отримувачів явною: який хоп авторитативний і що відбувається при помилках lookup.
3. Інструментуйте причини відмов у структурованих логах і зберігайте їх достатньо довго, щоб співставляти з бізнес‑таймлайнами.
4. Аудитуйте залежності: латентність LDAP, callout до поштових серверів і ємність сховища. Якщо вони можуть відхиляти отримувачів — вони частина вашого вхідного SLO.
5. Програйте швидкий план діагностики один раз, коли ви не в полум’ї інциденту. Майбутнє‑ви буде менш дратівливим.