Обмеження SMTP: доведіть, що це провайдер, і адаптуйтеся правильно

November 21, 2025 • February 3, 2026 • Читання: 7 хв • Views: 13

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

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

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

Як насправді виглядає обмеження SMTP (у production-лозі)

Обмеження SMTP — це спосіб провайдера сказати вам: «Не тепер». Зазвичай воно приходить як тимчасові відмови (4xx),
іноді з уточненими статус-кодами (наприклад 4.7.0), іноді з текстом, який читається так, ніби його писав юрист.
Ваш MTA робить те, що MTA роблять: ставить у чергу й повторює. Якщо ви не контролюєте форму повторів, ви не контролюєте інцидент.

Класичні сигнали:

421 під час встановлення з’єднання або після привітання: «Service not available», часто з «try again later».
451/452 під час транзакції: «Temporary local problem» або «insufficient system storage» (іноді правда, іноді ні).
4.7.x уточнені статуси: «message deferred», «rate limited», «temporary throttling», «too many connections».
Відкладання з’єднань: «lost connection», «timeout», «host said: 421 …».
Вибухи по одних одержувачах: лише частина доменів призначення гальмує, інші приймають нормально.

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

Цікаві факти та історичний контекст (пошта завжди була такою)

SMTP старший за більшість ваших інструментів. Він з початку 1980-х, створений для кооперативних мереж, а не для антиспамової економіки.
4xx-відмови — це фіча, а не баг. «Try again later» задумувалося, щоб згладжувати відмови. Тепер це також інструмент політики.
Уточнені статус-коди (родовід RFC 3463) з’явилися, бо прості 4xx/5xx були надто багатозначними для сучасних операцій з поштою.
Greylisting популяризував ідею навмисної тимчасової відмови. Деякі отримувачі давали 4xx при першому контакті, щоб відлякати спам-ботів, які не роблять повторів.
Великі провайдери змістили фокус із репутації IP на поведінку. Обсяги, рівні скарг, автентифікація й залучення тепер впливають на обмеження.
Політики по доменах посилилися в міру зростання зловживань. Обмеження з’єднань на відправний IP стало нормою після того, як ботнети навчилися паралелізуватися.
Розділення масової та транзакційної пошти стало операційною практикою. Не для краси — бо їхнє змішування робить обидві гіршими під час обмежень.
DNS і таймаути — частина симптомів «обмеження». Коли провайдер перевантажений, часто сповільнюються TLS-рукостискання й затримки банера перед явними 4xx.

Один цитат, який варто приліпити до монітора:

«Надія — не стратегія.» — Джин Кранс

Швидкий план діагностики (перші/другі/треті перевірки)

Мета проста: знайти вузьке місце менше ніж за 15 хвилин. Не «зрозуміти все».
Просто визначити, чи це ваш хост, політика MTA, мережа або провайдер одержувача.

Перше: глобально чи по доменах?

Якщо сповільнюються всі призначення, підозрюйте локальні обмеження ресурсів, проблеми з DNS або спільний upstream (relay/smarthost).
Якщо затримка лише для одного провайдера/домена (наприклад outlook.com або один корпоративний MX), підозрюйте обмеження отримувача або політику/репутацію.

Друге: «не можна підключитися» чи «не можна доставити після підключення»?

Затримки підключення/привітання (таймаути, 421 під час підключення): ймовірно ліміти з’єднань, tarpitting або віддалене перевантаження.
Відмови на RCPT/DATA (451/452/4.7.x після MAIL FROM/RCPT TO/DATA): політика/лімітування, репутація, тригери вмісту або проблеми на рівні отримувача.

Третє: чи ваша форма повторів погіршує ситуацію?

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

Коротке правило: стабілізуйте перед оптимізацією

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

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

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

Як виглядає доказ

Відповіді віддалого SMTP містять явну мову або коди обмеження (421/451/4.7.x) після успішного встановлення TCP/TLS.
Кластеризація по доменах: один провайдер відкладає, інші приймають у нормальному режимі, з тієї ж хост-машини й вікна часу.
Стабільні локальні ресурси: CPU, RAM, диск, мережа в порядку, поки черга росте — це вказує не на локальне насичення.
Підписи ліміту з’єднань: «too many connections», часті скидання під час привітання або затримані банери лише для певних MX-хостів.
Кореляція зі змінами в патерні відправлення: реліз вийшов, маркетингова розсилка, сплеск скидів паролів або інцидент, що спричинив повтори.

Що НЕ вважається доказом

«Ми нічого не змінювали.» (Ймовірно, щось змінилося. Або провайдер щось змінив. Або ваш трафік змінився.)
«Черга велика.» (Черги ростуть з десятків причин.)
«Провайдер завжди глючить.» (Правда по суті, але марна в постмортемі.)

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

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

Нижче завдання передбачають Linux-хост з Postfix. Якщо ви використовуєте Exim, Sendmail або керований релей,
філософія та сама: збирайте тверді докази, потім формуйте трафік, щоб ви не билися з отримувачем.

Завдання 1: Порахуйте відкладені повідомлення й знайдіть топ-доменів

cr0x@server:~$ postqueue -p | awk '
/^[A-F0-9]/ {id=$1}
/@/ && /to=</ {for (i=1;i<=NF;i++) if ($i ~ /to=</) {addr=$i; gsub(/.*to=<|>.*/,"",addr); split(addr,a,"@"); dom=a[2]; print dom}}
/status=deferred/ {deferred=1}
' | sort | uniq -c | sort -nr | head
  913 outlook.com
  402 protection.outlook.com
  177 gmail.com
   61 yahoo.com
   44 example-corp.com

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

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

Завдання 2: Витягніть віддалені відповіді SMTP для відкладених доставок

cr0x@server:~$ sudo grep -E "status=deferred" /var/log/mail.log | tail -n 5
Jan 04 10:12:21 mx1 postfix/smtp[22119]: 3F2C41A2B: to=<user1@outlook.com>, relay=outlook-com.olc.protection.outlook.com[104.47.56.36]:25, delay=182, delays=0.2/0/12/170, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.56.36] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to MAIL FROM command))
Jan 04 10:12:22 mx1 postfix/smtp[22121]: 7B9DF1A31: to=<user2@outlook.com>, relay=outlook-com.olc.protection.outlook.com[104.47.56.38]:25, delay=164, delays=0.1/0/10/154, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.56.38] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to RCPT TO command))
Jan 04 10:12:24 mx1 postfix/smtp[22118]: 9C1C11A40: to=<user3@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0/0.2/0.9, dsn=2.0.0, status=sent (250 2.0.0 OK  1704363144 x7si123456qka.321 - gsmtp)
Jan 04 10:12:25 mx1 postfix/smtp[22125]: 1A7D21A55: to=<user4@example-corp.com>, relay=mx.example-corp.com[203.0.113.10]:25, delay=0.8, delays=0.1/0/0.2/0.5, dsn=2.0.0, status=sent (250 2.0.0 queued as 8F2A9C)
Jan 04 10:12:27 mx1 postfix/smtp[22130]: 5E0B71A66: to=<user5@outlook.com>, relay=outlook-com.olc.protection.outlook.com[104.47.56.37]:25, delay=211, delays=0.2/0/9/201, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.56.37] said: 421 4.7.0 Temporary server error. Please try again later. (in reply to end of DATA command))

Що це означає: Ви маєте успішні доставки до інших доменів, тоді як конкретний провайдер повертає «Server busy» і коди 4.7.x.
Це близько до судової міцності доказів: віддалений пір явно відкладає.

Рішення: Розглядайте це як обмеження провайдера. Зменшіть паралелізм до цього провайдера й збільшіть backoff; не «прискорюйте повтори».

Завдання 3: Перевірте, чи ви насичуєте локальні SMTP-клієнтські процеси

cr0x@server:~$ sudo postconf -n | egrep "default_process_limit|max_use|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_connect_timeout"
default_process_limit = 200
max_use = 100
smtp_destination_concurrency_limit = 50
smtp_destination_rate_delay = 0s
smtp_connect_timeout = 30s

Що це означає: Високий паралелізм і нульова затримка можуть виглядати як потік з’єднань для провайдера.
Ви можете спрацьовувати ліміти по IP або по орендарю.

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

Завдання 4: Заміряйте активні SMTP-з’єднання до провайдера

cr0x@server:~$ sudo ss -tnp | awk '$4 ~ /:25$/ || $4 ~ /:587$/ {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  62 104.47.56.36
  59 104.47.56.38
  57 104.47.56.37
  12 142.250.102.26
   4 203.0.113.10

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

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

Завдання 5: Перевірте затримки привітання (tarpitting) під час SMTP-handshake

cr0x@server:~$ time bash -c 'echo | nc -w 10 outlook-com.olc.protection.outlook.com 25'
220 DM6PR10CA0001.outlook.office365.com Microsoft ESMTP MAIL Service ready at Thu, 4 Jan 2026 10:13:12 +0000

real	0m6.412s
user	0m0.002s
sys	0m0.002s

Що це означає: 6-секундний банер — це не «нормальна інтернет-латентність». Це або навантаження, або tarpitting, або навмисне гасіння швидкості.
Якщо ця затримка лише для одного провайдера, ви маєте віддалене формування трафіку.

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

Завдання 6: Перевірте швидкість і правильність DNS-резольвінгу для цільового MX

cr0x@server:~$ dig +tries=1 +time=2 MX outlook.com
;; ANSWER SECTION:
outlook.com.		1800	IN	MX	5 outlook-com.olc.protection.outlook.com.

;; Query time: 21 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Jan  4 10:13:20 UTC 2026
;; MSG SIZE  rcvd: 98

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

Рішення: Якщо DNS повільний — виправляйте резолвери першочергово. Не налаштовуйте Postfix навколо падіння DNS.

Завдання 7: Перевірте стан локального хоста (диск та I/O), щоб не звинувачувати провайдера даремно

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  200G   48G  143G  26% /

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          3.20    0.00    1.10    0.30    0.00   95.40

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
nvme0n1          12.0    21.0   540.0  1120.0    0.02   0.7    2.1

Що це означає: Достатньо місця; немає I/O-затору. Зростання черги не через повільний або заповнений спул.

Рішення: Продовжуйте шукати вгору по ланцюжку. Якщо диск повний або I/O завантажений — виправте це спочатку; пошта чутлива до fsync-поведінки.

Завдання 8: Перевірте, чи менеджер черги не перевантажений

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C41A2B      5120 Thu Jan  4 09:58:11  noreply@service.example
                                         user1@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.56.36] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to MAIL FROM command))

7B9DF1A31      4891 Thu Jan  4 10:01:03  noreply@service.example
                                         user2@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.56.38] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to RCPT TO command))

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

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

Завдання 9: Переконайтеся, що ви не застрягли за smarthost або релейним вузлом

cr0x@server:~$ sudo postconf -n | egrep "^relayhost|^smtp_sasl_auth_enable|^smtp_tls_security_level"
relayhost =
smtp_sasl_auth_enable = no
smtp_tls_security_level = dane

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

Рішення: Якщо ви використовуєте relayhost, перемістіть діагностику до межі реле: їхні відповіді, ваші ліміти автентифікації, їхні квоти.

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

cr0x@server:~$ sudo postconf -e "debug_peer_list = outlook-com.olc.protection.outlook.com"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo grep -E "outlook-com\.olc\.protection\.outlook\.com|postfix/smtp" /var/log/mail.log | tail -n 20
Jan 04 10:14:10 mx1 postfix/smtp[22301]: connect to outlook-com.olc.protection.outlook.com[104.47.56.36]:25: Connected
Jan 04 10:14:16 mx1 postfix/smtp[22301]: << 220 DM6PR10CA0001.outlook.office365.com Microsoft ESMTP MAIL Service ready
Jan 04 10:14:16 mx1 postfix/smtp[22301]: >> EHLO mx1.service.example
Jan 04 10:14:17 mx1 postfix/smtp[22301]: << 250-DM6PR10CA0001.outlook.office365.com Hello [198.51.100.10]
Jan 04 10:14:17 mx1 postfix/smtp[22301]: >> MAIL FROM:<noreply@service.example>
Jan 04 10:14:17 mx1 postfix/smtp[22301]: << 451 4.7.500 Server busy. Please try again later. (S3150)

Що це означає: TCP-підключення вдалося. Банер прийшов. EHLO пройшов. Провайдер відклав на MAIL FROM.
Це не ваш фаєрвол. Це не ваш DNS. Це отримувач, який каже «пригальмуйте».

Рішення: Запровадьте pacing по домену та довший backoff; збережіть докази (логи) для ескалації провайдеру.

Завдання 11: Перевірте автентифікацію від імені вашого домену (SPF/DKIM/DMARC)

cr0x@server:~$ dig +short TXT service.example
"v=spf1 ip4:198.51.100.10 -all"
"google-site-verification=..."

cr0x@server:~$ dig +short TXT selector1._domainkey.service.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

cr0x@server:~$ dig +short TXT _dmarc.service.example
"v=DMARC1; p=quarantine; rua=mailto:dmarc@service.example"

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

Рішення: Якщо автентифікація відсутня/зламана — виправте це перед тим, як домовлятися про «ліміти». Ви не зможете налаштувати шлях назовні від недовіри.

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

cr0x@server:~$ sudo postcat -q 3F2C41A2B | egrep -i "^(message_size|recipient_count|sender|original_recipient|message_arrival_time)"
message_size:            5120
recipient_count:         15
sender:                  noreply@service.example
message_arrival_time:    Thu Jan  4 09:58:11 2026

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

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

Завдання 13: Перевірте, чи TLS-узгодження не гальмує або не падає (часто помилково сприймають як обмеження)

cr0x@server:~$ openssl s_client -starttls smtp -connect outlook-com.olc.protection.outlook.com:25 -servername outlook-com.olc.protection.outlook.com -brief </dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=*.protection.outlook.com
Verification: OK

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

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

Завдання 14: Переконайтеся, що ваш фаєрвол/NAT не відкидає вихідні з’єднання під навантаженням

cr0x@server:~$ sudo conntrack -S | head
entries  32768
searched 154832
found    98211
new      2211
invalid  0
ignore   0
delete   2179
delete_list 2179

Що це означає: Якщо invalid високе, або таблиця conntrack близька до ліміту, ви побачите випадкові SMTP-таймаути й скидання,
які виглядають як обмеження. Провайдер отримає подяку; ваш NAT-бокс тихо палає.

Рішення: Якщо conntrack насичений, зменшіть кількість вихідних з’єднань (нижчий паралелізм, більший reuse) і збільшіть ємність conntrack там, де потрібно.

Чиста адаптація: ліміти, backoff, паралелізм і гігієна черги

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

Принцип 1: Розділяйте класи пошти (транзакційна має пріоритет)

Якщо ви змішуєте скиди паролів із розсилками в одній черзі — ви заслуговуєте на відмову, яку отримаєте.
Транзакційна пошта має користувача, який чекає. Масова пошта має календар маркетингу.
У очах вашого інцидент-менеджера вони не рівні.

Розділіть на рівні застосунку (окремі стріми) або на рівні MTA (окремі транспорти), але зробіть це.
У Postfix це зазвичай означає виділені маршрути в transport_maps і різні налаштування паралелізму.

Принцип 2: Ліміти по домену кращі за глобальні

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

Принцип 3: Backoff має бути експоненційно-наближеним, з jitter, і достатньо довгим

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

Конкретні шаблони налаштування Postfix

Ви можете зробити це чисто, не перетворюючи ваш MTA на ручну скрипку.
Почніть з обмеження паралелізму по домену і невеликої затримки між відправленнями.

cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 10"
cr0x@server:~$ sudo postconf -e "smtp_destination_rate_delay = 1s"
cr0x@server:~$ sudo postconf -e "default_destination_concurrency_limit = 20"
cr0x@server:~$ sudo systemctl reload postfix

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

Рішення: Якщо провайдер явно повертає «too many connections» або «server busy», це ваш перший важіль.

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

cr0x@server:~$ sudo tee -a /etc/postfix/master.cf >/dev/null <<'EOF'
slowoutlook unix  -       -       n       -       -       smtp
  -o smtp_destination_concurrency_limit=2
  -o smtp_destination_rate_delay=3s
  -o smtp_connect_timeout=20s
EOF
cr0x@server:~$ sudo tee /etc/postfix/transport >/dev/null <<'EOF'
outlook.com slowoutlook:
protection.outlook.com slowoutlook:
EOF
cr0x@server:~$ sudo postmap /etc/postfix/transport
cr0x@server:~$ sudo postconf -e "transport_maps = hash:/etc/postfix/transport"
cr0x@server:~$ sudo systemctl reload postfix

Що це означає: Лише пошта до цих доменів використовує уповільнений транспорт; інші домени зберігають нормальну пропускну здатність.

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

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

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

cr0x@server:~$ sudo postconf -n | egrep "minimal_backoff_time|maximal_backoff_time|maximal_queue_lifetime"
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
maximal_queue_lifetime = 5d

Що це означає: Ваш MTA не буде бити кожну хвилину; між спробами він відступає до приблизно години максимум.
Якщо minimal backoff занадто малий, ви можете самі себе підсилити обмеження.

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

Гігієна черги: захистіть систему від самої черги

Зростаюча черга — це не лише «повідомлення чекають». Це використання диску, навантаження inode і CPU на сканування черг.
Ваша мета — зберегти MTA відзивним навіть під затримкою.

Тримайте /var/spool/postfix на швидкому сховищі і моніторте використання inode.
Уникайте величезних одноразових сплесків у черзі, контролюючи швидкість відправлення на рівні застосунку.
Краще мати менше одночасних SMTP-клієнтів до одного провайдера, ніж постійно відкривати нові з’єднання.

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

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

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

Середня SaaS-компанія керувала власним Postfix для транзакційної пошти. Вони додали новий регіон і почали відправляти з нового блоку IP.
Рол-аут пройшов добре тиждень, потім скиди пароля почали приходити із запізненням 30–90 хвилин для користувачів одного великого провайдера.
on-call інженер побачив велику чергу і припустив, що хост Postfix слабкий. Вони подвоїли CPU і додали пам’ять.

Черга продовжувала рости. Вони знову апгрейднули інстанс. І знову ріст. Налаштували ліміти дескрипторів файлів, потім перезапустили Postfix під час піку,
що тимчасово нічого не покращило і назавжди підірвало довіру команди. Тим часом доставлення до Gmail залишалося майже миттєвим,
що мало бути підказкою, але її ігнорували через «велика черга».

Насправді проблема була в логах: повторювані 451 4.7.500 Server busy на MAIL FROM, лише для MX-хостів того провайдера.
Вони спрацьовували на лімітах з’єднань, бо застосунок нещодавно перейшов від відправлення одного листа на подію до батчингу
і запуску кількох паралельних воркерів на клієнта. Більше подій — більше одночасних SMTP-клієнтів.

Коли вони обмежили паралелізм по домену до 2 і додали rate delay, backlog спав за кілька годин.
Постмортем мав жорстку ремарку: «Ми масштабували не те, бо не сегментували за доменом призначення».
Урок не «купіть більші сервери». Урок: доведіть, де вузьке місце, перш ніж торкатися заліза.

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

Велике підприємство хотіло зменшити наклад SMTP. Хтось запропонував «максимізацію повторного використання з’єднань» і «вищий паралелізм»
для кращої пропускної здатності до зовнішніх отримувачів. На папері виглядало чудово: менше TLS-handshake на повідомлення, більше паралельної доставки,
коротші черги. Зміни впровадили поступово. Метрики покращились. Всім аплодували.

Потім маркетингова кампанія зіткнулась з не пов’язаним інцидентом, що спричинив сплеск трафіку скидів паролів.
MTA зробив саме те, для чого його налаштували: відкрив і утримував багато одночасних сесій до кількох великих провайдерів.
Ці провайдери сприйняли поведінку як агресивну і почали tarpitting при привітанні
й відкладати на RCPT і DATA з 4.7.x кодами.

«Оптимізація» створила неприємне зворотне коло. Довгі банери означали, що з’єднання тримаються довше.
Тримані з’єднання означали менше вільних слотів. Менше слотів — довше повідомлення в черзі.
Черга знову повторювала спроби. Повторні спроби відкривали ще більше з’єднань. І так далі.
Черга стала нелінійною. Не через повільний сервер, а через те, що віддалений бік її пригальмував, а MTA не адаптувався.

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

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

Організація зі суворим change management проганяла вихідну пошту через виділений релейний рівень.
Реле-хости не були потужні. Вони не були модними. Але були інструментовані:
лічильники відкладень по домену, дашборди глибини черги та вибіркове логування були стандартом білду.
Для кожного класу доменів документували ліміт паралелізму і раціональне обґрунтування.

Одного дня великий провайдер почав повертати тимчасові відмови і повільні банери. Черга почала рости.
On-call скористувався рукописом: підтвердити кластеризацію по домену, підтвердити відмови 4.7.x, підтвердити стабільність локальних ресурсів.
Дашборд показав, що лише цей провайдер має зростання відкладень; інші домени в нормі.

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

Ніяких героїчних дій. Ніяких випадкових змін параметрів. Ніяких панічних перезапусків. Нудна практика була проста:
передвизначайте поведінку при обмеженні по призначенню і додавайте спостережуваність до MTA.
Саме так ви почнете спати.

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

Ось режими відмов, що постійно повторюються через любов людей до простих історій.
SMTP не любить простих історій.

1) Симптом: «Пошта затримується для всіх» (але лише один провайдер фактично відкладає)

Корінь: Ви застосовуєте глобальний throttle або менеджер черги витрачає більшість циклів на один відкладений домен.

Виправлення: Впровадьте транспорти по домену або ліміти паралелізму по домену. Тримайте швидкі домени швидкими.

2) Симптом: Багато таймаутів і помилок «lost connection»

Корінь: Або віддалений tarpitting/затримки банера, або локальна conntrack/NAT-екзотика під навантаженням з’єднань.

Виправлення: Заміряйте час привітання, перевірте статистику conntrack і зменшіть паралелізм з’єднань. Віддавайте перевагу стійкішим, меншим сесіям.

3) Симптом: Ви бачите 451/4.7.x і хтось радить «retry faster»

Корінь: Неправильне розуміння відмов. Швидші повтори можуть збільшити обмеження і затягнути відновлення.

Виправлення: Backoff з jitter. Зменшення паралелізму по домену. Стабілізуйте спочатку; потім відкачайте чергу.

4) Симптом: Тільки великі повідомлення затримуються або відкладаються

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

Виправлення: Підтвердіть віддалені відповіді (вони часто згадують розмір), зменшіть розміри вкладень і розгляньте альтернативи для важкого вмісту.

5) Симптом: Gmail у порядку, Microsoft повільний (або навпаки)

Корінь: Різні політики провайдерів, різні моделі репутації, різні ліміти з’єднань.

Виправлення: Налаштовуйте під кожного провайдера. Не узагальнюйте поведінку одного домену на «SMTP» в цілому.

6) Симптом: Черга росте після релізу, але в логах видно «server busy» від провайдера

Корінь: Реліз змінив патерн відправлення (сплески, паралелізм, батчинг) більше, ніж сирий обсяг.

Виправлення: Додайте upstream rate limiting в застосунку; згладьте сплески. MTA-контролі — другий рівень захисту.

7) Симптом: Провайдери відкладають на MAIL FROM і ви підозрюєте баг у MTA

Корінь: Рішення політики на боці отримувача базується на ідентичності відправника/репутації IP; MAIL FROM зручний ранній choke point.

Виправлення: Покращте автентифікацію (SPF/DKIM/DMARC), зменшіть сплески і, якщо потрібно, поступово прогрівайте IP-адреси замість «вписатися по максимуму в перший день».

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

Покроково: діагностика і стабілізація під час однієї on-call зміни

Сегментуйте проблему по домену: визначте топ відкладених доменів з черги.
Прочитайте віддалені відповіді: зберіть 10–20 представницьких рядків відкладень з часовими позначками і віддаленими IP.
Підтвердіть локальний стан: простір на диску, iowait, пам’ять, conntrack, дескриптори файлів.
Заміряйте поведінку рукопотискання: затримка банера і результати STARTTLS для відкладеного провайдера.
Обмежте паралелізм по домену: почніть консервативно (2–5) для проблемного провайдера.
Додайте затримку по домену: секунди мають значення; почніть з 1–3 секунд для проблемного провайдера.
Захистіть транзакційну пошту: розділіть транспорти або черги; надавайте пріоритет скидам/OTP перед масовими розсилками.
Зменшіть upstream-сплески: якщо застосунок може зупинити масову розсилку — зупиніть; якщо може сповільнити — сповільніть.
Слідкуйте за схилом черги: стабілізація означає «черга перестає рости», а не «черга повністю зникла».
Збережіть докази: фрагменти логів, коди відмов, та часові ряди. Вони потрібні для ескалації провайдеру і внутрішньої підзвітності.

Чекліст: пакет доказів для «це провайдер»

Підрахунок топ відкладених доменів (з парсингу черги).
Принаймні 5 рядків логу з dsn=4.7.x або 421/451 з текстом SMTP від провайдера.
Один детальний SMTP-трейс, що показує connect+EHLO успіх і далі відмову (Завдання 10).
Дані часу рукопотискання (затримка банера) для цього провайдера vs принаймні одного іншого.
Сніпети локальних ресурсів, що показують відсутність насичення: диск, iostat, load, conntrack.

Чекліст: чиста адаптація (без створення монстра)

Транспорт по домену для відомих «тяжких» провайдерів.
Консервативні дефолти для smtp_destination_concurrency_limit і smtp_destination_rate_delay.
Розділення масової і транзакційної пошти.
Розумні налаштування backoff; без швидких петель повторів.
Дашборди: глибина черги, частота відкладень по домену, перцентилі затримки доставки.
Кнопка «kill» для масових розсилок на рівні застосунку.

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

1) Чи означають 4xx помилки завжди обмеження?

Ні. 4xx означає «тимчасова відмова», що може включати обмеження, greylisting, технічні роботи або тимчасові маршрутизаційні проблеми.
Обмеження ймовірне, коли 4xx групуються по домену й містять 4.7.x мову на кшталт «rate limited», «server busy» або «too many connections».

2) Як відрізнити обмеження провайдера від власних мережевих проблем?

Якщо TCP-підключення і EHLO успішні, і отримувач відповідає 451/421/4.7.x — це сильно в бік проблеми на стороні провайдера.
Якщо не вдається підключитися, бачите багато таймаутів по багатьом доменам або conntrack насичений — у вас локальна мережна проблема.

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

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

4) Чи варто підвищувати паралелізм Postfix, щоб швидше відкачати чергу?

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

5) Краще відправляти прямо на MX чи через relay-сервіс?

Прямо на MX дає вам контроль і миттєву видимість відповідей отримувача. Релей може дати кращу репутацію IP,
але він також стає додатковою точкою обмеження зі своїми квотами й політиками. Виберіть одне, інструментуйте його й знайте межу.

6) Чи може зламаний SPF/DKIM/DMARC спричиняти обмеження замість bounce?

Так. Деякі провайдери пом’якшують поведінку прийому: більше відкладень, повільніше прийняття або суворіше фільтрування, коли автентифікація відсутня чи неконсистентна.
Ви можете не отримати явної помилки «auth failed»; отримаєте «server busy» і довгий день.

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

Розділіть транзакційну пошту в окремий стрім і транспорт, і агресивно обмежте масовий трафік.
Розгляньте відправлення транзакційної пошти з прогрітої, стабільної ідентичності (окремий домен/піддомен/IP), відмінної від маркетингу.

8) Який найчистіший спосіб адаптуватися без накопичення постійних костилів?

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

9) Коли ескалювати до провайдера?

Ескалюйте, коли маєте пакет доказів: представницькі SMTP-відповіді, часові позначки, IP відправника і докази, що інші домени працюють.
Провайдери краще реагують на структуровані дані, ніж на «наша пошта повільна».

10) Чи можна «довести» обмеження, якщо провайдер просто таймаутить і ніколи не повертає 4xx?

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

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

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

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