Електронна пошта: Забагато отримувачів — зупиніть зловживання та виправте легітимні масові розсилки

February 2, 2026 • February 3, 2026 • Читання: 5 хв • Views: 6

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

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

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

Що насправді означає «забагато отримувачів» (і чому це існує)

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

Залежно від того, де ви вдаритесь об стіну, ви побачите різні SMTP-коди та різну поведінку:

Під час SMTP-транзакції (фаза RCPT TO): Приймальний сервер відкидає додаткових отримувачів. Типові відповіді: 452 4.5.3 Too many recipients, 550 5.5.3 Too many recipients або текст від постачальника.
До SMTP (політика відправлення): Сервіс відправлення (Exchange, Postfix submission, хмарний шлюз) відхиляє повідомлення за політикою, лімітами відправника або обмеженнями отримувачів.
Після прийняття (правило політики/транспорту): Повідомлення прийнято, але потім відкладено, поміщено в карантин або повернуто, бо розширення списків робить його таким, що перевищує політику.
На стороні застосунку: Ваша бібліотека або постачальник API відхиляє запит, бо ви перевищили ліміти на отримувачів у повідомленні або розмір пакетної заявки.

Обмеження не є необов’язковими. Без них поштові системи перетворяться на дешеві гармати для спамерів і дорогі нагрівачі для ваших CPU. Кепи отримувачів — одні з небагатьох засобів, які одночасно зменшують зловживання й не дають «легітимним» масовим відправленням розвалити інфраструктуру.

Цитата, яку варто тримати на стіні:
Надія — це не стратегія. — Джин Кранц

Жарт №1: Поштові системи як ліфти: якщо спробувати втиснути 200 людей, ви все одно тільки опуститесь.

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

SMTP спочатку передбачав дружніх пірів. Ранню поштову архітектуру будували за допущенням співпраці; жорсткі засоби проти зловживань з’явилися пізніше, коли спам став бізнес-моделлю.
RFC 5321 задає очікування, не вашу політику. Стандарти SMTP визначають механіку розмови; ліміти отримувачів явно залишені реалізаціям і локальній політиці.
Списки розсилки змінили радіус ураження. Коли розширення списків стало поширеним, одна адреса «To:» могла означати тисячі доставок, що навантажує черги й репутацію.
«Забагато отримувачів» часто 4xx, не 5xx. Багато систем відкладають замість остаточного відхилення, щоб не втратити легітимну пошту під час тимчасових піків навантаження.
Ліміти отримувачів — це проти зловживань і помилок конфігурації. Баг, який циклічно проходить таблицею контактів, може створити повідомлення з тисячами RCPT-команд; ліміти зупиняють витік на ранньому етапі.
Деякі постачальники рахують розширених отримувачів, інші — ні. У однієї системи «50 отримувачів» означає «50 RCPT-команд», а в іншої — «50 після розширення списків». Ця різниця руйнує міграції.
Велика кількість отримувачів впливає на TLS та CPU. SMTP-транзакція може пройти, але перевірки політик по кожному отримувачу, підпис DKIM і сканування контенту зростають у вартості з кожною адресою.
Репутація — за відправною ідентичністю, а не за намірами. Провайдери не дбають, чи ваша розсилка на 5 000 отримувачів — «повідомлення безпеки» чи «хто попросив»; вони бачать обсяг і скарги.
Класичні MTA були спроєктовані для store-and-forward. Саме тому ви можете «прийняти зараз, доставити пізніше» у чергу. Це стійкість — але саме там ховаються відставання.

Практична модель: де з’являються обмеження отримувачів

1) Відправник (застосунок або користувач)

Ваш CRM, інструмент моніторингу, HR-платформа і навіть cron job можуть генерувати пошту. Багато з цих
інструментів думають: «пошта = один API виклик» і з радістю вставлять 2 000 отримувачів в одне повідомлення, бо так простіше.
Саме так вас блокують.

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

2) Submission і політика виходу (де дорослі ставлять правила)

Сервера відправлення (authenticated SMTP, Exchange transport, хмарний шлюз) — правильне місце для застосування меж по користувачах і застосунках.
Якщо ви не застосуєте ліміти тут, ви дозволяєте кожному ноутбуку й кожному скомпрометованому паролю вирішувати долю вашої репутації.

Типові контролі:

Ліміт отримувачів на повідомлення (жорсткий кап).
Ліміт швидкості повідомлень на відправника (повідомлень за хвилину).
Ліміт швидкості отримувачів на відправника (отримувачів за хвилину) — кращий для масових патернів.
Політики за доменом отримувача (внутрішні vs зовнішні).
Сканування контенту й DLP, що може погано масштабуватися з кількістю отримувачів.

3) MTA (Postfix/Exchange/etc.) і черга

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

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

4) Приймальні сервери (те, що ви не контролюєте)

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

Швидкий план діагностики: знайдіть вузьке місце швидко

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

Перш за все: визначте точку застосування (відправник, submission, MTA, приймач)

Подивіться на текст відскоку або відхилення. Чи вказує він на ваш сервер, ваш шлюз або віддалений домен?
Перевірте SMTP-код відповіді. 4xx натякає на відкладення; 5xx — на політику/остаточне відхилення.
Знайдіть рядок журналу, що відповідає Message-ID або queue ID. Це — істина на місці.

По-друге: виміряйте радіус ураження

Чи це один відправник? Один застосунок? Один підмережа? Чи всі?
Тільки внутрішні отримувачі, чи зовнішні теж?
Одне велике повідомлення або багато середніх?

По-третє: вирішіть режим реагування

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

Жарт №2: Підняття лімітів отримувачів, щоб вирішити затор — наче купити більший сміттєвий бак, щоб загасити пожежу на кухні.

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

Завдання нижче припускають середовище Linux MTA (Postfix поширений), з systemd журналами.
Навіть якщо ви використовуєте Exchange або хмарний шлюз, та сама логіка: знайдіть компонент, що застосовує обмеження, перевірте налаштований ліміт і підтвердіть, що відбувається під навантаженням.

Завдання 1: Знайти точне відхилення в логах (Postfix через journal)

cr0x@server:~$ sudo journalctl -u postfix --since "1 hour ago" | grep -E "too many recipients|Recipient address rejected|5\.5\.3|4\.5\.3" | tail -n 20
Jan 04 10:12:09 mx1 postfix/smtpd[21455]: NOQUEUE: reject: RCPT from mailclient[10.20.3.44]: 452 4.5.3 Too many recipients; from=<alerts@corp.example> to=<dl-all@corp.example> proto=ESMTP helo=<host44>

Що це означає: Відхилення відбулося під час SMTP RCPT, на mx1, у smtpd. Це рішення політики при вхідному з’єднанні (submission або relay).
Це не віддалений приймач.

Рішення: Підтвердіть, який параметр Postfix або демон політики застосовує обмеження отримувачів для цього сервісу (порт 25 vs 587), потім вирішіть, чи виправляти поведінку відправника або налаштувати виняток для довіреного відправника.

Завдання 2: Визначити клієнта і чи це аутентифікована відправка

cr0x@server:~$ sudo journalctl -u postfix --since "1 hour ago" | grep "sasl_username" | tail -n 10
Jan 04 10:12:09 mx1 postfix/smtpd[21455]: warning: unknown[10.20.3.44]: SASL LOGIN authentication failed: authentication failure

Що це означає: Та сама IP-адреса з’являється, але проходження автентифікації не вдалось. Це або неправильна конфігурація, або зловживання.

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

Завдання 3: Інспектувати налаштування ліміту отримувачів Postfix

cr0x@server:~$ sudo postconf | grep -E "smtpd_recipient_limit|default_recipient_limit|smtpd_client_recipient_rate_limit|smtpd_recipient_restrictions"
default_recipient_limit = 1000
smtpd_recipient_limit = 100
smtpd_client_recipient_rate_limit = 0
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Що це означає: smtpd_recipient_limit=100 — жорсткий кап під час SMTP-діалогу для цього демона.
default_recipient_limit впливає на внутрішні доставки та деяку поведінку черги; це не те саме обмеження.

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

Завдання 4: Перевірити переозначення для сервісів у master.cf (submission vs smtp)

cr0x@server:~$ sudo postconf -n | head
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no

cr0x@server:~$ sudo grep -nE "^(smtp|submission|smtps)\s" /etc/postfix/master.cf
13:smtp      inet  n       -       y       -       -       smtpd
26:submission inet n       -       y       -       -       smtpd

cr0x@server:~$ sudo sed -n '13,40p' /etc/postfix/master.cf
smtp      inet  n       -       y       -       -       smtpd

submission inet n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_limit=500

Що це означає: Submission має вищий кап отримувачів (500), ніж порт 25. Добра практика: суворіше для неаутентифікованого вхідного, більш гнучко для аутентифікованих користувачів/застосунків.

Рішення: Якщо відхилення сталося на smtp сервісі (порт 25), але відправник повинен використовувати submission (587), виправляйте маршрутизацію й облікові дані замість підняття лімітів на порті 25.

Завдання 5: Підтвердити, яким портом скористався клієнт (packet capture, коротко і хірургічно)

cr0x@server:~$ sudo timeout 15 tcpdump -ni any 'host 10.20.3.44 and (port 25 or port 587)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:12:09.112233 eth0  IP 10.20.3.44.51234 > 10.20.1.10.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
10:12:09.112300 eth0  IP 10.20.1.10.25 > 10.20.3.44.51234: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0

Що це означає: Клієнт звертається до порту 25, а не 587. Це типово для MTA, не для застосунків/користувачів.

Рішення: Перенесіть клієнта на submission (587) з аутентифікацією й відповідними пер-ідентифікаторними контролями. Тримайте порт 25 суворим.

Завдання 6: Перевірити розмір черги і чи не маскують ліміти проблему пропускної здатності

cr0x@server:~$ mailq | head -n 30
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
6F2A512345      3292 Thu Jan  4 10:10:01  alerts@corp.example
                                         user1@external.example
                                         user2@external.example

9C8B7128AA      8410 Thu Jan  4 10:10:05  hr@corp.example
                                         dl-all@corp.example
-- 52 Kbytes in 2 Requests.

Що це означає: Є повідомлення в черзі; не обов’язково погано. Але якщо черга постійно зростає, ліміти отримувачів можуть бути наслідком зворотного тиску.

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

Завдання 7: Проінспектувати повідомлення в черзі на кількість отримувачів і заголовки

cr0x@server:~$ sudo postcat -q 9C8B7128AA | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            8410             8410
message_arrival_time: Thu Jan  4 10:10:05 2026
sender: hr@corp.example
named_attribute: rewrite_context=local
recipient: dl-all@corp.example
*** MESSAGE CONTENTS ***
Received: from hr-app (10.20.9.15) by mx1 with ESMTPA; Thu, 4 Jan 2026 10:10:05 +0000
To: dl-all@corp.example
Subject: Updated handbook policy

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

Рішення: Визначте, де відбувається розширення списку (сервер каталогів, MTA alias maps, менеджер списків). Встановіть ліміти на розширені отримувачі й надайте погоджений канал для масових відправлень.

Завдання 8: Перевірити розмір розширення alias/баз даних (приклад: Postfix virtual aliases)

cr0x@server:~$ sudo postmap -q dl-all@corp.example /etc/postfix/virtual
user1@corp.example,user2@corp.example,user3@corp.example,user4@corp.example,user5@corp.example

Що це означає: Список розширюється локально в кілька отримувачів. Якщо це відображення стане величезним, ви зіткнетеся з лімітами або проблемами продуктивності.

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

Завдання 9: Перевірити здоров’я DNS (бо «забагато отримувачів» іноді просто «надто повільно»)

cr0x@server:~$ dig +time=2 +tries=1 mx external.example
;; ANSWER SECTION:
external.example.   300  IN  MX  10 mx.external.example.

cr0x@server:~$ dig +time=2 +tries=1 mx.external.example a
;; ANSWER SECTION:
mx.external.example. 300 IN A 203.0.113.25

Що це означає: DNS відповідає швидко. Якби він був повільним або таймаутив, ваш MTA міг би накопичувати чергу та почати відкладати, що люди плутають з «лімітами отримувачів».

Рішення: Якщо DNS повільний: виправте резолвери, кешування і правила файрволу. Тиск на чергу часто проявляється як дивні політичні симптоми.

Завдання 10: Протестувати поведінку приймача віддалено контрольованою SMTP-сесією

cr0x@server:~$ nc -v mx.external.example 25
Connection to mx.external.example 25 port [tcp/smtp] succeeded!
220 mx.external.example ESMTP

cr0x@server:~$ printf "EHLO mx1.corp.example\r\nMAIL FROM:<test@corp.example>\r\nRCPT TO:<a@external.example>\r\nRCPT TO:<b@external.example>\r\nDATA\r\nSubject: test\r\n\r\ntest\r\n.\r\nQUIT\r\n" | nc mx.external.example 25
220 mx.external.example ESMTP
250-mx.external.example
250 PIPELINING
250-SIZE 52428800
250 HELP
250 2.1.0 Ok
250 2.1.5 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF;
250 2.0.0 Accepted
221 2.0.0 Bye

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

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

Завдання 11: Виявити одного відправника, що генерує аномальний обсяг

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | grep " from=<" | sed -n 's/.*from=<\([^>]*\)>.*/\1/p' | sort | uniq -c | sort -nr | head
  842 alerts@corp.example
  115 hr@corp.example
   23 noreply@corp.example

Що це означає: Один відправник домінує. Це або реальний інцидент (шторм моніторингу, скомпрометований токен), або запланована кампанія, яка забула використати масовий канал.

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

Завдання 12: Перевірити налаштування вихідної паралельності (Postfix), бо «просто підняти ліміт» — це пастка

cr0x@server:~$ sudo postconf | grep -E "default_process_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|qmgr_message_active_limit"
default_process_limit = 100
qmgr_message_active_limit = 20000
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

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

Рішення: Налаштуйте паралельність і затримки за напрямком (особливо для великих провайдерів) замість збільшення кількості отримувачів у повідомленні. «Швидше» часто означає «швидше заблокують».

Завдання 13: Підтвердити, чи фільтр контенту є реальним вузьким місцем

cr0x@server:~$ systemctl status rspamd | sed -n '1,12p'
● rspamd.service - Rspamd Mail Filter
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-01-04 08:01:22 UTC; 2h 12min ago
       Docs: man:rspamd(8)

cr0x@server:~$ sudo journalctl -u rspamd --since "30 min ago" | tail -n 5
Jan 04 10:11:58 mx1 rspamd[1322]: lua; task; slow task: 2.34 seconds: id: <20260104101158.12345@mail>

Що це означає: Фільтрація повільна під поточним навантаженням. Великі відправлення множать сканування й операції підписання залежно від архітектури.

Рішення: Виправте продуктивність фільтра, масштабування або правила обходу для довірених внутрішніх масових каналів. Не піднімайте лиміти отримувачів, щоб «нагодувати» повільний фільтр.

Завдання 14: Додати цілеспрямований тимчасовий тротл для стримання інциденту (Postfix anvil)

cr0x@server:~$ sudo postconf -e "smtpd_client_message_rate_limit = 60"
cr0x@server:~$ sudo postconf -e "smtpd_client_recipient_rate_limit = 300"
cr0x@server:~$ sudo systemctl reload postfix

cr0x@server:~$ sudo postconf | grep -E "smtpd_client_message_rate_limit|smtpd_client_recipient_rate_limit"
smtpd_client_message_rate_limit = 60
smtpd_client_recipient_rate_limit = 300

Що це означає: Ви встановили норми для клієнтів. Це не «виправляє» масову пошту; це дає вам час і захищає іншу частину системи.

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

Проєктування легітимних масових відправлень, які не тригерять ліміти

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

Переважний патерн: один отримувач на повідомлення (з персоналізацією)

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

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

Так, це більше повідомлень. Саме тому масова відправка має використовувати інженерний канал: виділений IP/пул, чіткі квоти й явний контроль швидкості.

Допустимий внутрішній патерн: контрольоване розширення списків, сувора авторизація відправників

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

Правила, що тримають внутрішні масові розсилки в межах:

Дозволяти великі списки тільки певним відправникам. Решта повинні використовувати процес запиту або модерований список.
Встановлювати рівневі обмеження: малі списки (до 50) — відкриті; середні (50–500) — потребують авторизації; великі — потребують модерації або спеціального інструмента.
Сегментувати за функцією: «всі співробітники» — для аварійних і обов’язкових повідомлень, не для опитувань про обід.
Робити розширення видимим: логувати кількість розширених отримувачів і хто його ініціював.

Chunking (коли не можна відправляти по одному отримувачу)

Деякі системи (legacy-застосунки, певні інструменти сповіщення) не можуть надсилати по одному отримувачу, але можуть відправляти кількох отримувачів.
Тоді chunking — ваш друг:

Тримайте кожне повідомлення нижче найменшого відомого ліміту отримувачів на вашому шляху (submission, шлюз, віддалені домени).
Інтервал між пакетами за контролем швидкості: отримувачі за хвилину, не повідомлення за хвилину.
Розділяйте внутрішніх і зовнішніх отримувавачів. Завжди. Різні політики, різні наслідки.

Не плутайте списки розсилки з масовою поштою

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

Зупинка зловживань без побічних наслідків

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

Як виглядає зловживання в світі лімітів отримувачів

Один внутрішній хост намагається відправити повідомлення з сотнями RCPT TO команд.
Скомпрометований обліковий запис швидко відсилає до багатьох зовнішніх отримувачів, часто з подібними темами.
Невдачі групуються навколо проблем автентифікації, незвичних HELO імен або невідомих клієнтів.
Ваша черга заповнюється відкладеною поштою до багатьох доменів з повторними спробами.

Контролі, що працюють (і не руйнують легітимні відправки)

Окрема submission для застосунків: різні облікові дані, різні ліміти, різні логи. Якщо щось зламається, зламається тільки той шлях.
Ліміти отримувачів за відправником: обмежуйте отримувачів/хвилину на користувача/застосунок, а не лише отримувачів/повідомлення.
Кепи отримувачів за рівнем довіри: наприклад, 50 для загальних користувачів, 500 для аутентифікованих сервісів-застосунків, 5 000 для спеціальної масової системи з моніторингом.
Allowlist виходу за призначенням: сповіщення моніторингу — на малу групу; HR — тільки внутрішні; маркетинг — через масову інфраструктуру.
Алерти на аномалії: «відправник перевищив базовий рівень у 10 разів» краще, ніж «черга палає» щоразу.

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

Якщо людина хоче надіслати на 2 000 отримувачів, вона не повинна робити це з Outlook через корпоративний SMTP submission.
Не тому, що люди погані. Бо люди зайняті, і зайняті люди натискають «відправити» двічі.

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

Три корпоративні міні-історії (анонімізовано, правдоподібно)

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

Середня компанія мігрувала від одного поштового шлюза до іншого. План проєкту мав звичні пункти:
вирівнювання SPF/DKIM, налаштування TLS, конектори. Хтось спитав про ліміти отримувачів. Відповідь була зневажливою:
«У нас ніколи не було проблем, тож дефолти підходять.»

За два тижні HR намагався надіслати нагадування про реєстрацію пільг до списку співробітників.
Воно повернулося з «забагато отримувачів». Команда підняла ліміт отримувачів на submission.

Помилка залишилася. Бо точка застосування була не submission; це була політика розширення списків шлюза.
Новий шлюз рахував розширені отримувачі. Старий рахував лише конвертні отримувачі. Та сама поведінка користувача — різна семантика.

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

Міні-історія 2: Оптимізація, що відкотилася

Платформна команда хотіла зменшити навантаження на сервіс сповіщень. Він надсилав багато схожих алертів до великих on-call груп.
Хтось запропонував: «Замість одного листа на людину, надсилай один лист групі. Менше повідомлень, швидше.»
На білборді це виглядало елегантно.

У продакшні це перетворилося на повільно розвиту аварію. Сервіс сповіщень почав емитити листи з 300–800 отримувачами.
Submission їх приймав. Потім MTA розгортав доставки і передавав їх на сканування контенту й DKIM-підпис.
CPU виріс, затримки збільшились, черга пошти стала злюкою, і почалися відхилення «забагато отримувачів», коли команда спробувала підвищити пропускну здатність, нарощуючи паралельність.

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

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

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

Фінансова компанія мала сувору політику: окремі SMTP submission кінцеві точки для людей, застосунків і масових систем.
Всім це не подобалось під час онбордингу. «Чому я не можу просто використовувати нормальний поштовий сервер?» — щотижневі нарікання.
Безпека це любила. SRE це терпіло. І так залишилось.

Одного понеділка скомпрометували обліковий запис сервісу (фішинг, передбачувано буденне).
Зловмисник намагався відправити спам на тисячі отримувачів з одного повідомлення з компрометованого хоста.
Спроба потрапила спочатку на людський submission — невірні облікові; потім на endpoint для застосунків.

Endpoint для застосунків дозволяв лише низький кап отримувачів на повідомлення і мав суворі ліміти отримувачів за хвилину.
Логи мали окремий індекс для відправки з базовими показниками по відправниках. Алерт спрацював за кілька хвилин:
«service-account-x recipients/minute перевищив поріг.» Тротл запобіг масштабній шкоді, і репутація IP залишилась неушкодженою.

Очистка була стандартною: відкликати облікові, перевипустити токени, додати MFA де можливо і переглянути правила egress-файрволу.
Найкраще: HR і on-call ротація цього навіть не помітили. Нудний поділ шляхів тримав вибух у маленькій коробці.

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

1) Симптом: «Забагато отримувачів» при внутрішніх DL-розсилках, хоча в листі видно одну адресу

Корінна причина: Система, що застосовує обмеження, рахує розширені отримувачі після розширення списку розсилки.

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

2) Симптом: Підняття `smtpd_recipient_limit` не допомогло

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

Виправлення: Визначте точку застосування через логи та SMTP-відповіді. Перевірте пер-сервісні override (master.cf), сервіси політики та віддалені відповіді.

3) Симптом: Легітимні масові відправлення іноді працюють, потім ламаються під навантаженням

Корінна причина: Тиск на чергу і таймаути. Повільне фільтрування контенту, проблеми DNS або віддалене тротлінгування роблять транзакції довшими і тригерять захист по швидкості/отримувачах.

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

4) Симптом: Розсилка однієї команди викликає масові відскоки і шкоду репутації

Корінна причина: Використання корпоративного SMTP submission як маркетинг/масового каналу; немає відписки, погана гігієна списку, відсутній пейсінг по домену.

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

5) Симптом: «Забагато отримувачів» від однієї внутрішньої IP з помилками автентифікації

Корінна причина: Скомпрометований хост або некоректно налаштований застосунок, що б’є по порту 25; можливий credential stuffing або шкідливе ПЗ.

Виправлення: Локалізувати: блокувати на файрволі, вмикати пер-клієнтські ліміти, розслідувати кінцеву точку, перевипустити облікові дані і вимагати submission з аутентифікацією на 587 для застосунків.

6) Симптом: Зовнішні провайдери приймають деяких отримувачів, відхиляють інших посеред транзакції

Корінна причина: Ліміти віддалених отримувачів на підключення або агресивні антиспам-правила, що тригеряться великою кількістю RCPT.

Виправлення: Зменште отримувачів на повідомлення і/або відкривайте нові з’єднання на чанки. Використовуйте пейсінг по доменах і поважайте 4xx-відмови.

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

Покроково: як обробити інцидент «забагато отримувачів» у продакшні

Зберіть докази: текст відскоку, SMTP-код, часовий інтервал, відправник і приклади отримувачів.
Знайдіть рядок в логах: співставте Message-ID або queue ID; ідентифікуйте сервер і сервіс, що застосував правило (25 vs 587).
Класифікуйте: підозра на зловживання vs легітимна масова vs випадковий CC-шторм.
Ізолюйте, якщо підозріло: тротлінг per client/sender; блокувати offending IP; відкликати облікові дані за потреби.
Перевірте здоров’я черги: якщо backlog росте, розслідуйте пропускну здатність перед зміною лімітів.
Визначте точку застосування: submission policy, MTA, розширення списків, шлюз, віддалений приймач.
Виберіть правильне виправлення:
- Легітимна масова: розбиття, повідомлення по одному отримувачу, спеціальний масовий шлях.
- Внутрішня трансляція: модерований список і авторизована група відправників.
- Зловживання: забезпечити автентифікацію відправки, ліміти, алерти аномалій, реакція на кінцеву точку.
Впровадьте безпечний виняток: лише якщо необхідно; обмежте його конкретним сервісним акаунтом і submission-слухачем.
Додайте спостережуваність: дашборди для отримувачів/хвилину по відправнику, топ-надсилачів, причин відмов, глибини черги.
Післяінцидентне прибирання: документуйте визначення (RCPT vs expansion), опублікуйте політику масової відправки і навчіть команди її використовувати.

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

Документуйте ліміти отримувачів для кожного шляху: inbound 25, submission 587, relay для застосунків, bulk relay.
Зробіть ліміти рівневими (люди vs застосунки vs масові), з окремими обліковими й логами.
Визначте «кількість отримувачів» у вашому середовищі: конверт RCPT, заголовкові отримувачі, розширені отримувачі.
Визначте управління великими списками: власник, призначення, авторизація відправника, правила модерування, максимальний розмір.
Впровадьте внутрішній сервіс масової відправки для погоджених трансляцій з аудиторськими логами й контролем швидкості.
Встановіть ліміти швидкості на повідомлення/хвилину і отримувачів/хвилину; налаштуйте алерти на аномалії.
Операціоналізуйте гігієну списків: обробка відскоків, видалення неактивних адрес, ревізія членств груп.
Проводьте ігрові дні: симулюйте компрометацію облікового запису, який відправляє на 1 000 отримувачів; перевірте тротли й алерти.

ЧаПи

1) Чи завжди «забагато отримувачів» означає зловживання?

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

2) Чи просто підняти ліміт отримувачів?

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

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

Бо розширення перетворює одну адресу на багато доставок. Деякі системи застосовують обмеження після розширення. Це часто правильна поведінка: вона відображає реальне навантаження й ризик.

4) Який найбезпечніший спосіб надіслати на 10 000 зовнішніх отримувачів?

Один отримувач на повідомлення, розподілений по доменах отримувачів, з використанням масової системи з обробкою фідбеку (відскоків/скарг). Корпоративні submission MTA не призначені для кампаній.

5) Чому я бачу 452 (4xx) замість 550 (5xx)?

4xx — тимчасова помилка: сервер каже «не зараз» (навантаження, тротлінг, ліміти швидкості). 5xx — політика або остаточна відмова. Операційно 4xx часто вказує на зворотний тиск або контроль швидкості, а не на жорстке правило.

6) Як уникнути ламання легітимних внутрішніх трансляцій?

Забезпечте санкціонований механізм трансляцій: модеровані великі списки, конкретні авторизовані відправники і окремий submission endpoint для внутрішніх комунікацій. Тримайте загальні ліміти для користувачів консервативними.

7) Мій постачальник апів каже: «нам потрібно 1 000 отримувачів на повідомлення». Що робити?

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

8) На які метрики варто налаштувати алерти, щоб вловити це рано?

Топ-надсилачі за отримувачами/хвилину, рівень відмов за кодами причини, швидкість росту глибини черги, відкладені доставки за доменом призначення і помилки автентифікації на submission endpoint.

9) Чи можуть ліміти отримувачів впливати на зберігання?

Так. Великий фан-аут збільшує записи в черзі й активність в спулі. Якщо ваша черга на повільному сховищі, ви побачите затримки й відкладення, що маскуються під політичні відмови. Тримайте spool на надійних, низьколатентних дисках і моніторте I/O wait.

10) Як пояснити це нетехнічним стейкхолдерам?

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

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

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

Наступні кроки, які реально змінять ситуацію:

Запишіть ваші ліміти по сервісам і визначте, що означає «отримувач» у вашому середовищі.
Розділіть submission за рівнями довіри (люди, застосунки, масові) з окремими обліковими та логами.
Впровадьте ліміти отримувачів за швидкістю і налаштуйте алерти на аномальних відправників до пошкодження репутації.
Виправте патерни масової відправки (один отримувач на повідомлення або chunking) замість підняття глобальних капів.
Управляйте великими внутрішніми списками з власниками, модеруванням і погодженим процесом трансляції.

Схожі статті

Електронна пошта: зовнішня репутація впала — що припинити робити негайно (і як виправити)