Пошта catch‑all: чому вона руйнує доставляння листів і безпечні альтернативи

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

Catch‑all — це еквівалент інструкції на рецепції приймати будь‑які пакунки з ім’ям «Any Name» і складати їх у вестибюлі.
Ви почуватиметеся дуже корисними, аж поки не з’явиться пожежник.

Що насправді робить поштова скринька catch‑all

Поштова скринька catch‑all (іноді «accept-all» або «default address») — це правило маршрутизації пошти, яке приймає повідомлення для будь‑якого отримувача на вашому домені
— включно з отримувачами, яких не існує — і доставляє їх у поштову скриньку (або pipe), якою ви керуєте.

Практично це означає, що ваш SMTP‑сервер перестає казати «550 5.1.1 user unknown» і починає відповідати «250 ok» майже на все.
Це змінює те, як інша частина екосистеми електронної пошти ставиться до вас.

Чому команди вмикають catch‑all (звичайні причини)

• Страх пропустити листи: «Що як клієнт набере saless@domain.com замість sales@domain.com?»
• Перехідна латка: старі псевдоніми, колишні відділи, старі адреси додатків.
• Спадкова звичка: хтось налаштував це десять років тому й ніхто не хоче торкатися пошти.
• Неправильне розуміння «deliverability»: вважають, що менше bounce‑ів = вища репутація.

Що catch‑all вам дає насправді

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

Чому catch‑all руйнує доставляння (механізми, а не враження)

1) Ви стаєте магнітом для спаму за визначенням

Спамери не мусять вгадувати адреси, коли домен приймає все. Вони можуть «зливати» випадкові отримувачі на ваш домен, і ви це приймете.
Як тільки вони дізнаються (через тести), що ваш домен — accept-all, ваш трафік потрапляє в їхні інструменти до категорії «високий прийом».
Це не особисто; це економіка.

Ваш обсяг вхідної пошти зростає. Ще важливіше — зростає обсяг шкідливої пошти: неіснуючі отримувачі, адреси, згенеровані ботами, dictionary‑атаки та підроблені домени відправників.
Це не залишається «тільки вхідним». Воно впливає на репутацію домену так, що проявляється пізніше, коли ви надсилаєте пошту назовні.

2) Ви руйнуєте важливий зворотний зв’язок: валідацію отримувача

SMTP має бути моментом фільтрації. Якщо користувача не існує, правильно відхилити на RCPT TO з кодом 5xx.
Catch‑all це прибирає. Ви приймаєте повідомлення, створюєте навантаження на зберігання і потім змушені справлятися з цим далі по ланцюжку.

Обробка далі часто перетворюється на «позначити як спам» або «видалити». Для вашої скриньки це нормально, але ви не відхилили на протоколі — відправник отримав 250 OK і вважає доставку успішною.

3) Ви створюєте «фантомне доставляння»: менше bounce, гірша репутація

Часте нерозуміння керівництва: «Bounces погані, тому давайте їх уникати». Ні.
Непотрібні bounce‑и — це погано. Точні bounce‑и — це гігієна.

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

4) Ви підвищуєте ймовірність backscatter (і дратуєте інших операторів)

Backscatter — це коли ваша система приймає лист і пізніше генерує bounce на підроблену адресу MAIL FROM.
Якщо ви приймаєте спам на випадкові отримувачі та потім вирішуєте, що «не можете доставити», ви можете генерувати повідомлення про недоставку невинним третім сторонам.

Багато сучасних MTA намагаються уникати цього, але конфігурації з catch‑all часто йдуть разом зі слабкими правилами маршрутизації та авто‑відповідачами.
Скарги на backscatter можуть сильно вдарити по IP або репутації домену.

5) Ви замилюєте сигнали DMARC/SPF/DKIM

DMARC — це не просто галочка. Це політика та канал звітності, який показує, хто вас підробляє і як приймачі обробляють вашу пошту.
Catch‑all дозволяє великій кількості вхідного мотлоху «успішно доставлятись» всередині, що заохочує погані робочі процеси:
пересилання підозрілої пошти, авто‑відповіді або випадкову взаємодію зі спуфінгом.

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

6) На зберігання та надійність це теж впливає (так, справді)

Пошта — це сховище. Пошта також — необмежений вхідний ввід від користувачів.
Поштова скринька catch‑all — класичний шлях до:

• Перевищення квот поштових скриньок (потім все повертається, включно з легітимною поштою).
• Проблем з індексацією/пошуком (IMAP‑сервери не люблять мільйони повідомлень у одній папці).
• Розростання резервних копій і складнощі відновлення (та скринька стає вашим гіршим набором даних).
• Плутанину під час інцидентного реагування («чому ця скринька 200 ГБ?»).

Жарт №1: Поштова скринька catch‑all — як /dev/null, тільки за це ще й треба платити, і іноді вона відправляє сердиті відповіді.

7) Ви підвищуєте ризик випадкового витоку даних

Неправильно адресована пошта іноді містить рахунки, контракти, облікові дані або персональні дані.
З catch‑all ви тихо приймаєте пошту, призначену для інших організацій теж — в тому числі через типографічні помилки в домені.
Ви тільки що стали сховищем даних чужих помилок.

8) Ви руйнуєте можливість ухвалювати точні політичні рішення

Коли все маршрутизовано в одне місце, усе виглядає однаково. Це руйнує вашу здатність:

• Розрізняти транзакційну та людську пошту
• Встановлювати ліміти та правила фільтрації для окремих псевдонімів
• Запроваджувати політики зберігання для конкретних поштових скриньок
• Застосовувати принцип найменших привілеїв (хто може що читати)

Catch‑all — це антипатерн, бо це одна корзина для гетерогенних ризиків.
З точки зору надійності: ви злили кілька доменів відмов у одне.

Цікаві факти та історичний контекст

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

1. Ранній SMTP (1980‑ті) припускав співпрацю мереж. Перевірка отримувача не була проблемою ворожого поля; нині це так.
2. Команди VRFY/EXPN раніше допомагали підтверджувати отримувачів. Сьогодні їх часто відключають, бо вони полегшують directory harvesting.
3. «Прийняти, а потім фільтрувати» історично було поширено, бо диск був дешевший за інженерний час. Нині дорогою частиною є репутація.
4. Спам вибухнув у 1990‑х, і dictionary‑атаки (спроби пошти на загальні імена) стали звичними; catch‑all — це фактично дозвіл на таку атаку.
5. SPF з’явився, щоб обмежити підробку через авторизацію IP відправника, але він крихкий при пересиланнях, тож пізніше люди більше покладалися на DKIM/DMARC.
6. DKIM зробив автентифікацію на рівні вмісту практичною, але не вирішив питання «чи існує цей отримувач?» Catch‑all все одно ламає цей сигнал.
7. DMARC ввів вирівнювання й політику, а також звіти. Ці звіти цінні, тільки якщо ви не тонете в мотлохові.
8. Сучасні провайдери пошти оцінюють домени та IP за залученістю і скаргами; прийняття великої кількості мотлоху підвищує ймовірність поганих взаємодій.
9. Plus‑адресація (user+tag@domain) стала популярною як безпечна альтернатива для «невідомих адрес» без прийняття буквально всього.

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

Коли доставляння або вхідний спам стає огидним, і catch‑all може бути причиною, не починайте з філософських дебатів. Тріажуйте як оператор.
Перевірте вузькі місця: поведінку протоколу, індикатори репутації й стан зберігання.

По-перше: підтвердьте, що ви справді приймаєте невідомих отримувачів

• Використайте SMTP‑тести проти ваших MX: чи приймає він RCPT TO для випадкового користувача?
• Перевірте конфіг MTA на наявність default транспорту, recipient maps або luser_relay.

По‑друге: кількісно оцініть шкоду (обсяг, джерела та режими відмов)

• Зразок логів: скільки різних неіснуючих отримувачів на годину?
• Топ IP/ASN, топ HELO‑імен, топ конвертів відправників.
• Зростання черги та шаблони bounce‑ів (тимчасові відмови проти постійних).

По‑третє: перевірте, чи catch‑all не маскує іншу проблему

• Повна квота поштової скриньки? Таймаути IMAP? Затримки в сховищі?
• Неправильно сконфігуровані псевдоніми/переадресації, які створюють петлі?
• Чи не потрапляє ваша вихідна пошта в спам тому, що домен виглядає брудним?

По‑четверте: вирішіть питання із обмеженням шкоди

• Негайно: відхиляйте невідомі отримувачі під час SMTP.
• Короткостроково: додайте явні аліаси для відомих помилок/важливих адрес.
• Середньостроково: впровадьте структуровану обробку вхідної пошти й security‑огляд для неправильно адресованих листів.

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

Нижче — конкретні завдання, які можна виконати на типовому Linux‑MTA стеці (приклади для Postfix, з деякими Exim/Dovecot/інструментами).
Кожне завдання містить команду, що означає її вивід і рішення на її основі.

Завдання 1: Доведіть поведінку catch‑all через пряму SMTP‑сесію

cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
250 2.1.5 Ok
quit
221 2.0.0 Bye

Значення: Якщо ви отримуєте «250 2.1.5 Ok» для явно випадкового отримувача, ви приймаєте невідомих отримувачів (catch‑all або еквівалент).

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

Завдання 2: Перевірте Postfix на класичну настройку catch‑all (luser_relay)

cr0x@server:~$ postconf -n | egrep 'luser_relay|local_recipient_maps|virtual_alias_maps|virtual_mailbox_maps|recipient_delimiter'
luser_relay = catchall
local_recipient_maps =
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox

Значення: luser_relay направляє невідомих локальних отримувачів на локальну адресу. Порожній local_recipient_maps також може означати «приймати все».

Рішення: Приберіть luser_relay і відновіть валідацію отримувачів через local_recipient_maps або правильні virtual mailbox maps.

Завдання 3: Підтвердіть, чи Postfix валіднує отримувачів під час RCPT

cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_relay_restrictions|smtpd_delay_reject'
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination

Значення: Нічого тут явно не відхиляє невідомих отримувачів. Це не завжди помилка, але це типовий пропуск.

Рішення: Додайте механізм валідації отримувачів (наприклад, коректні local_recipient_maps / virtual_mailbox_maps і reject_unlisted_recipient там, де доречно).

Завдання 4: Знайдіть шаблони «accept-all» у логах (неіснуючі отримувачі)

cr0x@server:~$ sudo grep -R "to=<.*@example.net>" /var/log/mail.log | tail -n 5
Jan  4 09:14:31 mx1 postfix/qmgr[1123]: 9A2B13C4D: to=<xyqzqj@example.net>, relay=local, delay=0.2, status=sent (delivered to mailbox)
Jan  4 09:14:32 mx1 postfix/qmgr[1123]: 7D1E22F8A: to=<billingg@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan  4 09:14:33 mx1 postfix/qmgr[1123]: 1F3D9C0AA: to=<hr-dept@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan  4 09:14:35 mx1 postfix/qmgr[1123]: 4C0D22B19: to=<asdkjhasd@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan  4 09:14:36 mx1 postfix/qmgr[1123]: 55B9CC1E0: to=<customer.service@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)

Значення: Випадкові отримувачі, що виглядають як «deliver to mailbox», — сильний індикатор, що валідація отримувача не відбувається.

Рішення: Якщо більше ніж тривіальна частка отримувачів — сміття, вимкніть catch‑all і додайте явні аліаси для легітимних варіантів.

Завдання 5: Визначте топ імен отримувачів (щоб помітити dictionary‑атаки)

cr0x@server:~$ sudo awk -F'to=<' '/postfix\/(qmgr|local)/ {for (i=1;i<=NF;i++) if ($i ~ /^to=</) {gsub(/^to=<|>,.*/,"",$i); print $i}}' /var/log/mail.log | \
cut -d@ -f1 | sort | uniq -c | sort -nr | head -n 10
  418 info
  377 admin
  265 support
  201 sales
  188 contact
  173 test
  166 hr
  144 billing
  121 webmaster
  110 noreply

Значення: Це найчастіше таргетовані локальні частини. «admin/info/support» високо — класична поведінка dictionary‑спаму.

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

Завдання 6: Перевірте глибину черги (симптом catch‑all + спам‑потоку)

cr0x@server:~$ mailq | tail -n 3
-- 1245 Kbytes in 812 Requests.

Значення: Зростаюча черга вказує на вузьке місце далі по ланцюжку (доставка, content scanning, диск I/O) або на зловживання зверху.

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

Завдання 7: Перевірте, чи ви генеруєте backscatter (зовнішні bounce‑и)

cr0x@server:~$ sudo grep -E "status=bounced|mailer-daemon|postmaster" /var/log/mail.log | tail -n 8
Jan  4 09:22:18 mx1 postfix/bounce[2219]: 6A1F2C9D3: sender non-delivery notification: 1B3C0D9AA
Jan  4 09:22:18 mx1 postfix/qmgr[1123]: 1B3C0D9AA: from=<>, size=3120, nrcpt=1 (queue active)
Jan  4 09:22:19 mx1 postfix/smtp[2281]: 1B3C0D9AA: to=<innocent@victim.tld>, relay=mx.victim.tld[203.0.113.8]:25, delay=1.2, status=sent (250 OK)

Значення: Ваш сервер відправляє повідомлення про недоставку третім сторонам. Якщо оригінальний MAIL FROM був підроблений (дуже часто у спамі), це backscatter.

Рішення: Припиніть приймати пошту, яку не можете доставити. Відхиляйте під час SMTP невірні отримувачі і розгляньте вимкнення out‑of‑band bounce‑ів для політичних відхилень по вмісту.

Завдання 8: Перевірте розмір скриньки та кількість повідомлень (реальність зберігання)

cr0x@server:~$ sudo doveadm mailbox status -u catchall@example.net messages vsize INBOX
messages=284112
vsize=19748377291

Значення: ~284k повідомлень і ~19.7GB в одній INBOX — місце, де продуктивність IMAP починає коштувати вам інцидентів.

Рішення: Якщо ви змушені тримати скриньку‑поглинач, обертайте її (щоденні папки), застосуйте ретеншн і тримайте її поза доступом користувачів IMAP. Краще відхилення.

Завдання 9: Перевірте ємність файлової системи та тиск на inode

cr0x@server:~$ df -h /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       500G  456G   19G  97% /var/vmail

Значення: На 97% використання — ви в одному сплеску від збоїв доставки. Catch‑all робить сплески нормою.

Рішення: Обмежте проблему, відхиляючи невідомих отримувачів і чистячи сховище catch‑all. Потім вирішіть ємність (розширення, переміщення або застосування квот/ретеншн).

Завдання 10: Знайдіть петлі аліасів та неправильні маршрути (catch‑all може їх створювати)

cr0x@server:~$ sudo postmap -q catchall /etc/aliases
catchall@example.net

Значення: Тут catchall резольвиться в адресу того самого домену. Це не обов’язково петля, але часто є джерелом проблем у поєднанні з virtual alias правилами.

Рішення: Переконайтеся, що sink‑скринька — це конкретний запис у mailbox map, а не ще один аліас, що може перекидуватися. Краще: усунути її.

Завдання 11: Перевірте поведінку virtual mailbox map (Postfix)

cr0x@server:~$ sudo postmap -q realuser@example.net /etc/postfix/vmailbox
realuser@example.net    example.net/realuser/

Значення: Цей отримувач існує як пункт призначення поштової скриньки.

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

Завдання 12: Протестуйте відхилення невідомих отримувачів після змін конфігурації

cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
550 5.1.1 <this-user-should-not-exist-9f3a@example.net>: Recipient address rejected: User unknown in local recipient table
quit
221 2.0.0 Bye

Значення: Це бажана поведінка. Відхиляти на RCPT час з чітким 550.

Рішення: Залиште так. Потім додайте явні аліаси для бізнес‑критичних адрес, які раніше «ловилися» catch‑all.

Завдання 13: Підтвердіть, що DKIM підписування застосовується до вихідної пошти

cr0x@server:~$ sudo grep -R "DKIM-Signature" -n /var/log/mail.log | tail -n 3
Jan  4 09:40:01 mx1 opendkim[901]: 3F2AB19C0: DKIM-Signature field added (s=mail, d=example.net)
Jan  4 09:40:05 mx1 opendkim[901]: 8C1DA22A1: DKIM-Signature field added (s=mail, d=example.net)
Jan  4 09:40:07 mx1 opendkim[901]: 7A0BC11E2: DKIM-Signature field added (s=mail, d=example.net)

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

Рішення: Якщо DKIM‑підписування відсутнє, виправте це перед тим, як підвищувати DMARC‑енфорсмент, інакше створите власний інцидент доставляння.

Завдання 14: Перевірте DMARC‑політику для вашого домену (швидка перевірка DNS)

cr0x@server:~$ dig +short TXT _dmarc.example.net
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.net; ruf=mailto:dmarc-forensic@example.net; fo=1"

Значення: Політика — p=none (лише моніторинг). Це поширено, але означає, що приймачі не просять карантинувати/відкидати підроблені листи.

Рішення: Залишайте моніторинг, доки не виправите catch‑all. Коли стабілізуєтеся, рухайтеся до p=quarantine, а потім до p=reject поетапно.

Завдання 15: Виявити застосування квот до поштової скриньки (або їх відсутність)

cr0x@server:~$ sudo doveadm quota get -u catchall@example.net
Quota name=User quota Type=STORAGE Value=0 Limit=0
Quota name=User quota Type=MESSAGE Value=0 Limit=0

Значення: Немає встановлених квот. Catch‑all без квот — це повільний інцидент.

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

Завдання 16: Обмежуйте швидкість зловмисників на краю (пом’якшення під час видалення catch‑all)

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_message_rate_limit|smtpd_client_connection_rate_limit'
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 60

Значення: Базові ліміти налаштовані. Якщо їх немає — ви покладаєтесь на надію та CPU.

Рішення: Додайте ліміти як тимчасовий щит. Перманентне рішення: припинити приймати невідомих отримувачів.

Три корпоративні міні‑історії (усі надто реальні)

Міні‑історія 1: Інцидент через хибне припущення

Середня B2B компанія перейшла від хостингу пошти до самопідтримуваного Postfix + Dovecot, бо «це ж просто пошта».
Під час cutover хтось включив catch‑all на домені, щоб не втратити повідомлення з деактивованих скриньок.
Припущення було просте: приймаємо все зараз, почистимо потім.

Через два тижні Sales почали скаржитися, що потенційні клієнти «ігнорують». Насправді не ігнорують. Вихідні послідовності потрапляли в спам у кількох великих отримувачів.
Тим часом вхідна catch‑all‑скринька приймала постійний потік спаму і неправильно адресованої пошти… плюс тисячі RCPT‑проб у день.
Ніхто не помічав, бо технічно «все працювало»: пошта приймалася й доставлялася кудись.

SRE на виклику знайшов catch‑all‑скриньку на десятки гігабайтів, а IMAP час від часу таймаутився в пікові години.
Тікети підтримки показували відсутність легітимної вхідної пошти — насправді вона не зникла; вона була похована під сміттям і повільною індексацією.
Поштова інфраструктура була достатньо здоровою, щоб не дзвонити уночі, але достатньо хворою, щоб коштувати грошей.

Виправлення не було гламурним. Вони прибрали catch‑all, додали явні аліаси для топових помилкових адрес і відхиляли невідомих отримувачів під час SMTP.
Обсяг спаму одразу впав. IMAP стабілізувався. Доставляння покращилось протягом кількох тижнів, коли домен перестав поводитися як sink для прийому.

Урок: «Почистимо потім» — це не план, коли інтернет має право писати у ваше сховище.

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

Глобальна сервісна фірма хотіла зменшити навантаження helpdesk від bounce‑ів під час реорганізації.
У них були десятки старих адрес відділів, які люди все ще використовували. Замість підтримки аліас‑мапи хтось запропонував «розумну спрощену» ідею:
увімкнути catch‑all і використовувати фільтри для маршрутизації пошти за ключовими словами.

Здавалося розумно. Але це змінювало їхній профіль ризику в одну ніч.
Раптом була прийнята будь‑яка випадкова локальна частина. Спам‑фільтри були змучені. CPU шлюзу зріс.
Catch‑all‑скринька стала смітником, і — що гірше — маршрутизація за ключовими словами створювала хибні спрацьовування.

Легітимні рахунки опинялися у загальній скриньці через слова, що співпадали з внутрішнім правилом.
Декілька повідомлень постачальників затримувалися через автоматичну сортування, що викликало конкуренцію і повтори.
І тому, що система не робила bounce для невідомих отримувачів, зовнішні відправники не виправляли адреси; проблема ніколи не зникала природним шляхом.

Вони відкотили зміни і зробили нудну, але правильну річ: підтримують аліас‑мапу, тримають короткий список тимчасових переадресацій і відхиляють невідомих отримувачів.
«Оптимізація» зменшила один вид шуму (bounce‑и), створивши більший і дорожчий вид шуму (неправильне доставляння й обробку).

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

SaaS‑компанія обслуговувала пошту для кількох брендів під однією інфраструктурою.
У них було жорстке правило: жодних catch‑all на основних доменах. Будь‑які винятки вимагали письмового обґрунтування і обмеження в часі.
Обґрунтування зазвичай відхиляли, бо «можемо щось пропустити» — не інженерна вимога, а тривога.

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

Якось на них націлилася таргетована спам‑кампанія: масові RCPT‑проби на admin/info/support варіанти.
Їхні шлюзи залишилися спокійними. Невідомі отримувачі одразу відхилялися. Обсяг спаму й надалі існував, але він не розростався в необмежене накопичення в скриньках.
Ще важливіше — їхній моніторинг був чистим: відхилення були видимі як відхилення, а не як «доставлено у скриньку, яку ніхто не читає».

Післяінцидентний огляд був майже нудним. Це комплімент.
Їхня «правильна, але не захоплива» політика не дозволила поганому дню перетворитися на квартал‑довге падіння доставляння.

Безпечні альтернативи: як зберегти надійність без catch‑all

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

Вам не потрібен catch‑all, щоб не втратити легітимну пошту. Потрібні три речі:
(1) явні аліаси для того, що вам справді потрібно,
(2) безпечна обробка неправильно адресованих повідомлень,
(3) видимість того, що люди намагаються надіслати.

Альтернатива 1: Явні мапи аліасів (з відповідальністю)

Підтримуйте контрольований список рольових адрес: support@, sales@, billing@, security@ тощо.
Додавайте відомі опечатки (billingg@), якщо це дійсно цінно, але розглядайте їх як тимчасові.

Відповідальність важлива. Кожен аліас має мати відповідальну команду і SLA‑очікування, навіть якщо це «best effort».

Альтернатива 2: Plus‑адресація для користувачів і систем

Якщо потрібна гнучкість (трекинг, адреси для сервісів), використовуйте plus‑адресацію:
user+tag@example.net. Ви можете приймати необмежену кількість тегів, але не приймати необмежену кількість локальних частин.

Це дає відчуття «ніколи не губити пошту» для легітимних адрес, водночас відхиляючи випадкові отримувачі.

Альтернатива 3: Контрольований sink на окремому субдомені

Якщо бізнес дійсно потребує приймати неправильно адресовану пошту під час міграції, робіть це на виділеному субдомені:
legacy.example.net або oldmail.example.net.

• Окремий MX і окрема межа репутації (наскільки це практично).
• Жорстка політика ретеншну (наприклад, 7–14 днів).
• Строгий контроль доступу і аудит.
• Ліміти швидкості і сильне фільтрування.

Тримайте blast radius обмеженим.

Альтернатива 4: SMTP‑валідація отримувача через інтеграцію з директорією

Якщо у вас є реальна директорія користувачів (LDAP/AD) або джерело істини в базі, інтегруйте валідацію отримувачів.
Для віртуальних доменів джерелом авторитету є ваші virtual_mailbox_maps або еквівалент.

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

Альтернатива 5: Використовуйте адресу для інгесту в систему тикетингу (не catch‑all)

Багато команд вмикають catch‑all, бо хочуть, щоб «anything@domain йшло в Support».
Не робіть цього. Налаштуйте невеликий набір intake‑адрес (support@, help@, billing@) і направляйте їх у тикетинг.
Для всього іншого: відхиляйте.

Альтернатива 6: Моніторинг «невідомих отримувачів» без прийому пошти

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

Агрегуйте лічильники RCPT TO відхилень і топ‑рядки локальних частин. Ви отримуєте розвідку без зберігання корисного навантаження.
Навантаження — це недостовірний ввід; вам він не потрібен, щоб покращити адресну гігієну.

Парафраз вимоги: Вернер Фогельс часто підкреслює, що потрібно проектувати на відмову й автоматизувати відновлення; електронна пошта — не виняток.

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

Це шаблони, які я бачу, коли catch‑all втягнуто. Вони не теоретичні. Це список «чому пищить тривога».

1) Симптом: обсяг вхідного спаму раптом подвоївся

Корінна причина: Ваш домен виявлено як accept‑all; спамери збільшили RCPT‑spray.

Виправлення: Відхиляйте невідомих отримувачів на RCPT‑етапі. Додайте ліміти швидкості. Тримайте явні аліаси для рольових акаунтів.

2) Симптом: легітимна пошта клієнта «зникає»

Корінна причина: Вона не зникає; вона похована у великому sink‑скриньці або затримана через індексацію/блокування IMAP.

Виправлення: Приберіть catch‑all. Якщо тимчасово тримаєте sink, доставляйте в не‑IMAP‑піплайн з ротацією і ретеншном.

3) Симптом: ваша вихідна пошта частіше потрапляє в спам

Корінна причина: Деградація репутації домену через шумні патерни поведінки, потенційний backscatter і погані операційні сигнали.

Виправлення: Припиніть accept‑all, переконайтеся, що DKIM корректний, опублікуйте розумну DMARC‑політику і стабілізуйте вхідну гігієну.

4) Симптом: зростання черги й велике навантаження у «випадкові» періоди

Корінна причина: Спам‑сплески приймаються, а потім накопичуються у content scanning/AV/IMAP доставці, насичуючи CPU або диск.

Виправлення: Перенесіть відхилення раніше (RCPT‑перевірки), обмежте швидкість і перевірте продуктивність диска. Не зберігайте те, що слід відхилити.

5) Симптом: надходять скарги про bounce‑спам, який ви «відправили»

Корінна причина: Backscatter від прийняття повідомлень і пізнішого відсилання NDR на підроблені адреси.

Виправлення: Відхиляйте невірні отримувачі й політичні відмови під час SMTP, уникайте генерації NDR для непроаутентифікованих/підроблених відправників.

6) Симптом: одна скринька споживає абсурдне місце

Корінна причина: Catch‑all як необмежений sink, часто без квот або ретеншну.

Виправлення: Агресивно видаляйте/обертайте, встановіть квоти і заберіть catch‑all маршрут. Побудуйте pipeline моніторингу відхилень натомість.

7) Симптом: команда безпеки знаходить чутливі чужі дані у вашій скриньці

Корінна причина: Неправильно адресована пошта інших доменів (типо‑помилки) приймалася тихо.

Виправлення: Припиніть accept‑all. Додайте процес для обробки неправильно адресованої пошти (повідомити відправника, безпечно видалити, задокументувати).

8) Симптом: внутрішні команди покладаються на випадкові адреси «бо так працює»

Корінна причина: Catch‑all створює погані внутрішні контракти; люди перестають підтримувати коректні адреси.

Виправлення: Приберіть catch‑all і змусьте явний дизайн інтерфейсів: визначені аліаси, відповідальність і управління змінами.

Жарт №2: Catch‑all — чудовий спосіб отримати «нульових bounce‑ів» так само, як відключення моніторингу дає «нуль алертів».

Контрольні списки / покроковий план

Покроково: видалення catch‑all без шкоди для бізнесу

1. Інвентаризуйте, що саме ловить catch‑all.
   Витягніть топ отримувачів з логів (Завдання 5) і складіть список топ‑50–200 локальних частин.
   Визначте, які з них легітимні аліаси, які опечатки варто зберегти, а які — сміття.
2. Створіть явні аліаси для легітимних отримувачів.
   Тримайте список коротким і під відповідальністю. Направляйте в команди або в тикетинг, а не на персональні скриньки за замовчуванням.
3. Впровадьте відхилення отримувачів.
   Нехай невідомі отримувачі падають на RCPT часі (Завдання 12). Це фактичне виправлення.
4. Додайте моніторинг відхилених отримувачів.
   Сповіщайте про сплески. Вибірково зберігайте топ‑локальні частини відхилень. Ви хочете видимість без зберігання payload.
5. Запровадьте квоти/ретеншн для будь‑якого залишкового sink.
   Якщо тримаєте тимчасово, ставте її як небезпечні відходи: маленька, закрита і спорожняється за графіком.
6. Комунікуйте зміни.
   Повідомте внутрішні команди: невідомі адреси тепер відхиляються; ось підтримувані адреси. Це запобігатиме «поштовому рулетці».
7. Запустіть період плавного переходу з таргетованими аліасами.
   Для старих адрес створюйте явні редиректи з датами закінчення. Вкажіть дату в тікеті.
8. Перевірте вихідну автентифікацію.
   Підтвердіть DKIM‑підписування і статус DMARC (Завдання 13–14). Видалення catch‑all часто супроводжується посиленням політик.
9. Вимірюйте результати.
   Слідкуйте за обсягом вхідного спаму, глибиною черги, ростом скриньок і кількістю запитів про відсутню пошту.

Контрольний список: як виглядає «добре» після зміни

• Випадковий RCPT TO отримує 550 на SMTP‑етапі.
• Рольові адреси існують явно й моніторяться.
• Обсяг вхідного спаму падає і залишається нижчим.
• Глибина черги корелює з реальним навантаженням, а не з випадковими сплесками.
• У логах немає патернів backscatter.
• Catch‑all‑скринька (якщо є) — мала, обертається і обмежена в часі.
• Звіти DMARC переглядаються і мають практичну цінність (не шпалери).

Контрольний список: якщо наполягаєте на збереженні catch‑all (правила знезараження)

Іноді бізнес наполягає. Добре. Тоді працюйте з ним як з небезпечною функцією:

• Обмежте в часі: дата закінчення, власник і план відкату.
• Розділіть: бажано окремий субдомен і MX.
• Агресивно лімітуйте швидкість: підключення й повідомлення.
• Не виставляйте це через IMAP: доставляйте в pipeline обробки, а не в людську скриньку.
• Ретеншн: швидке видалення. Ви не будуєте архів.
• Огляд безпеки: контроль доступу, аудит і обробка інцидентів для неправильно адресованих даних.

FAQ

1) Чи завжди поштова скринька catch‑all погана?

В продакшні на основному домені: так, зазвичай це негатив. Рідкісний допустимий випадок — строго контрольований, обмежений в часі період міграції,
бажано на окремому субдомені з жорстким ретеншном і лімітами.

2) Хіба відхилення невідомих отримувачів не допомагає спамерам перелічувати валідних користувачів?

Може допомагати, але на практиці спамери вже пробують загальні імена та рольові акаунти. Ви мінімізуєте перелічування за допомогою лімітів швидкості, tarpits і відключення директорних команд (VRFY/EXPN).
Accept‑all гірше: воно гарантує прийом і запрошує більший обсяг зловживань.

3) Ми ввімкнули catch‑all через помилки клієнтів. Що робити натомість?

Створюйте явні аліаси для високовартісних опечаток (billingg@, saless@) і встановлюйте їм термін дії після виправлення джерела помилок (вебсайт, PDF, записи постачальників).
Використовуйте логи, щоб знаходити реальні опечатки, а не гадати.

4) Чи шкодитиме відключення catch‑all доставлянню через збільшення bounce‑ів?

У вас буде більше точних bounce‑ів, що добре. Це змушує відправників тримати чистоту списків і зменшує мотлох у вхідному потоці.
Мета — не «нуль bounce‑ів», а «bounce‑и тільки там, де треба».

5) Чи плюс‑адресація — це ризик безпеки?

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

6) Ми на Microsoft 365 / Google Workspace. Чи важливий catch‑all?

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

7) Як зберігати видимість неправильно адресованої пошти після відключення catch‑all?

Логуйте RCPT‑відхилення і агрегуйте відхилені локальні частини. Сповіщайте про сплески і створіть звіт «топ відхилених отримувачів».
Це дає інтелект без зберігання недовіреного payload.

8) А що щодо «catch‑all», що ловить тільки певні патерни?

Роутинг за патернами може бути прийнятним, якщо він детермінований і вузький (наприклад, user+tag), але «будь‑що → support» все ще є catch‑all у масці.
Якщо патерн дозволяє довільні імена отримувачів, ви знову приймаєте контрольований атакований ввід на великому масштабі.

9) У нас багато брендових доменів і треба приймати все, бо партнери вгадують адреси. Який компроміс?

Використовуйте рольові акаунти й добре рекламований каталог адрес. Якщо треба приймати невідомі отримувачі, робіть це на виділеному intake‑субдомені з ретеншном,
а потім вимагайте від відправників виправити адресу після короткого grace‑періоду. Не дозволяйте цьому стати постійним.

10) Як швидко відновиться доставляння після видалення catch‑all?

Зменшення спаму відбудеться миттєво. Ефекти на репутацію можуть тривати дні‑тижні залежно від обсягу і того, як приймачі оцінюють ваш домен/IP.
Ключ — послідовність: стабільна поведінка, автентифікована вихідна пошта і відсутність backscatter.

Наступні кроки

Якщо у вас зараз є catch‑all на основному домені, практичні наступні кроки прості:

1. Запустіть SMTP‑тест (Завдання 1) і підтвердіть accept‑all‑поведінку.
2. Витягніть топ отримувачів з логів (Завдання 5) і створіть короткий список власних аліасів.
3. Вимкніть catch‑all / відновіть валідацію отримувачів (Завдання 2–3), потім протестуйте знову (Завдання 12).
4. Обмежте тимчасову sink‑скриньку квотами й ретеншном (Завдання 8 і 15).
5. Слідкуйте за глибиною черги, використанням диска і ознаками backscatter (Завдання 6, 9, 7).

Надійність пошти — це не героїка. Це вміння відмовлятися від нісенітниць рано, послідовно й з логами, яким можна довіряти.
Catch‑all — протилежність цьому. Приберіть його, і ваша поштова система знову почне працювати як інженерна система.