Обмеження розміру електронних повідомлень: безпечно збільшити їх, не дозволивши зловживань

Що фактично обмежує розмір листа (і чому «просто підвищити» не спрацює)

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

Розмір, який ви бачите, не дорівнює розміру, який йде по мережі

Вкладення зазвичай кодуються base64, що додає близько 33% накладних витрат. Далі — структура MIME, заголовки і іноді повторне кодування шлюзами.
«Обмеження вкладення 25 МБ» часто транслюється в обмеження розміру повідомлення в MTA близько 33–36 МБ. Якщо це не врахувати, ви «піднімете до 30 МБ» і все одно блокуватимете 23 МБ PDF, який на дроті стає 31 МБ.

Де ховаються ліміти

• MUA (клієнт): Outlook, мобільні клієнти та веб-пошта можуть застосовувати UI-обмеження або політику, надану сервером.
• Submission (MSA): аутентифікований SMTP-ендпойнт може мати суворіші ліміти, ніж вхідний MX.
• MTA: правила транспорту в Postfix/Exim/Sendmail/Exchange, плюс обмеження на окремих конекторах.
• SMTP-проксі: балансувальники навантаження, TLS-термінатори, поштові проксі (і «корисні» middlebox) можуть обмежувати розмір тіла запиту або часи очікування.
• Фільтрація: антивіруси, DLP, пісочниці та спам-фільтри можуть відмовлятися від великих payload-ів або тайм-аутитись при їх скануванні.
• Поштове сховище: квоти на поштові скриньки, обмеження на окремі повідомлення й обмеження БД.
• Віддалена сторона: ваш локальний ліміт не має значення, якщо отримувач відхиляє все більше 10–25 МБ.

Цитата для рев’ю змін: Надія — це не стратегія. — Gene Kranz.

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

Факти та історичний контекст, який стане в пригоді на нарадах

Це короткі, конкретні тези, які допоможуть пояснити, чому не можна просто перетворити електронну пошту на Dropbox.

1. MIME вкладення не були в оригінальному дизайні електронної пошти. Раніше пошта була здебільшого plain text; MIME (multipurpose internet mail extensions) з’явився пізніше для стандартизації вкладень і багатого контенту.
2. Base64 кодування надуває дані. Бінарні файли перетворюються в ASCII-безпечний текст для транспорту, це додає близько третини у витратах на розмір у звичних випадках.
3. “SIZE” — це розширення SMTP, а не гарантія. Багато MTA рекламують максимальний розмір у привітанні SMTP, але проміжні вузли все одно можуть відхилити пізніше.
4. 25 МБ стало соціальним стандартом, а не технічним. Багато провайдерів зійшлися на 10–25 МБ, бо це баланс між зручністю і ризиком зловживань; це оперативна зручність у краватці.
5. Великі повідомлення — це ризик доступності. Одне гігантське повідомлення може зайняти сканування, створити довгі SMTP-сесії та підвищити затримку черги; це не лише «більше сховища».
6. Mailstore історично оптимізували під багато малих об’єктів. Багато дрібних листів — нормальне навантаження; великі вкладення змінюють IO-патерни, поведінку компактування та витрати на індекси.
7. Деякі фільтри розпаковують вкладення. «Маленький» zip може роздутися під час сканування; ліміти можуть застосовуватись до розпакованого розміру, а не лише до сирого SMTP-пейлоаду.
8. Таймаути важать більше при збільшенні розміру. 40 МБ повідомлення на повільному каналі клієнта може тримати SMTP-транзакцію відкритою настільки довго, що спрацюють ліміти на з’єднання або idle-timeout зворотного проксі.

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

Рамка прийняття рішення: чи варто взагалі підвищувати ліміти?

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

Коли підвищувати ліміти має сенс

• Бізнес-критичні робочі процеси залежать від пошти. Зовнішні партнери не користуються вашим порталом, і ви не можете вимагати інший канал.
• У вас сильні вхідні контроли. Сучасний спам-фільтр, сканування на шкідливість і обмеження швидкості ввімкнені та моніторяться.
• Система зберігання та черги розрахована на навантаження в найгіршому випадку. «Нормальний день» не рахується; плануйте «день маркетингової розсилки + інцидент + віддалені відмови».
• Ви готові терпіти недоставку для деяких отримувачів. Ви все одно натрапите на віддалені ліміти; користувачі повинні приймати запасні варіанти (посилання, спільні диски, захищена передача файлів).

Коли підвищення лімітів — пастка

• Ви намагаєтесь компенсувати поламаний файл-шерінг. Виправте систему спільного доступу до файлів. Пошта не повинна бути запасним планом для інструментів співпраці.
• Ви не контролюєте репутацію виходу. Більші повідомлення можуть збільшити число повторних спроб, час у черзі та вплив на спам-скор; доставлюваність може поводитися дивно.
• Ваш стек фільтрації вже працює на межі. Якщо ваша AV-пісочниця майже заповнена, більші payload-и перетворять «майже насичено» на «вниз».

Встановіть два ліміти, а не один

Оператори, що виживають, встановлюють окремі ліміти для:

• Входу з інтернету (суворіше; вищий ризик зловживань).
• Аутентифікованого виходу/подання (трохи вищий; все одно під контролем лімітів і політик користувача).

Потім вони створюють виключення для конкретних відправників/одержувачів або доменів, а не загальну «всім тепер по 100 МБ».

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

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

Перше: визначте, де відбувається відмова (і дістаньте SMTP-код)

• Попросіть bounce / NDR текст або заголовки повідомлення. Ви шукаєте коди типу 552, 554, 451 плюс рядки «message too big».
• Перевірте логи MTA для транзакції: відхилили на етапі SMTP DATA або прийняли, а потім відбувся bounce?
• Якщо відправник внутрішній, відтворіть ситуацію за допомогою swaks або контрольного тесту з відомого хоста.

Друге: вирішіть, чи це рекламований ліміт, проксі чи таймаут фільтра

• Миттєвий 552 під час DATA: налаштований максимальний розмір у приймаючому MTA/проксі.
• Прийнято, а потім через час bounce: відмова downstream-фільтра/поштового сховища або результат контент-сканування.
• Довга затримка, а потім таймаут: проксі idle timeout, завал сканера контенту або повільний диск.

Третє: перевірте стан черги та тиск на диск

• Шукайте ріст черги, відкладені повідомлення та хвилі повторних спроб.
• Підтвердіть наявність місця на диску і inode; великі повідомлення можуть створювати багато тимчасових файлів.
• Перевірте IO wait; обробка великих повідомлень часто — це питання пропускної здатності/латентності диска.

Якщо ви не можете відповісти на «де це падає?» за п’ять хвилин, у вас не проблема розміру листа; у вас проблема спостережуваності.

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

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

Завдання 1: Підтвердіть максимальний розмір повідомлення в Postfix

cr0x@server:~$ postconf message_size_limit
message_size_limit = 10485760

Що означає вивід: Postfix відхилятиме повідомлення більші за 10,485,760 байт (~10 МБ) на етапі SMTP DATA.

Рішення: Якщо ви підвищуєте для «25 МБ вкладень», подумайте про встановлення message_size_limit близько ~35–40 МБ, щоб врахувати base64/MIME накладні витрати, і спочатку перевірте downstream-ліміти.

Завдання 2: Перевірте обмеження розміру поштової скриньки в Dovecot (поширено для IMAP бекендів)

cr0x@server:~$ doveconf -n | egrep 'mail_max_size|quota'
mail_max_size = 0
plugin {
  quota = maildir:User quota
}

Що означає вивід: mail_max_size = 0 часто означає «немає обмеження на повідомлення на боці Dovecot», але квоти все одно застосовуються через плагін quota.

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

Завдання 3: Визначте ефективний розмір, який оголошується через SMTP (розширення SIZE)

cr0x@server:~$ swaks --server mx1.example.net --ehlo test.example --quit-after EHLO
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<  220 mx1.example.net ESMTP Postfix
 > EHLO test.example
<  250-mx1.example.net
<  250-SIZE 10485760
<  250-PIPELINING
<  250-STARTTLS
<  250 HELP
=== Connection closed with remote host.

Що означає вивід: Сервер оголошує ліміт 10 МБ через розширення SMTP.

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

Завдання 4: Перевірте, що Nginx (або інший проксі) не обрізає SMTP/HTTP шляхи завантаження

cr0x@server:~$ nginx -T 2>/dev/null | egrep 'client_max_body_size|proxy_read_timeout|proxy_send_timeout'
client_max_body_size 10m;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

Що означає вивід: Якщо цей Nginx фронтує веб-пошту або API для подання, то він обмежує запити 10 МБ і має короткі таймаути.

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

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

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9D2F21C03A*    84231 Mon Jan  4 10:12:41  alerts@example.net
                                         user@example.com
                                         (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
-- 1 Kbytes in 1 Request.

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

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

Завдання 6: Підсумуйте чергу Postfix за статусом (active vs deferred)

cr0x@server:~$ postqueue -p | egrep -c '^[A-F0-9]'
42

Що означає вивід: Є 42 записи в черзі (приблизний рахунок за рядками з ID черги).

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

Завдання 7: Слідкуйте за логами на предмет відхилень за розміром

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | egrep 'message size|too large|552' | tail -n 5
Jan 04 10:14:22 mx1 postfix/smtpd[23144]: NOQUEUE: reject: RCPT from mail.remote.tld[203.0.113.55]: 552 5.3.4 Message size exceeds fixed maximum message size; from=<sender@remote.tld> to=<user@example.com> proto=ESMTP helo=<mail.remote.tld>

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

Рішення: Підніміть відповідний приймаючий ліміт (і переконайтесь, що ви не пропустили більш суворий параметр для певного сервісу, наприклад submission vs inbound).

Завдання 8: Підтвердіть місце на диску та доступність inode (великі листи навантажують обидва)

cr0x@server:~$ df -h /var/spool/postfix /var/mail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       200G  176G   15G  93% /
/dev/sdb1       500G  120G  355G  26% /var/mail

Що означає вивід: Spool знаходиться на / і використано 93%. Це майбутня відмова черги.

Рішення: Перемістіть spool на окрему файлову систему або розширте ємність перед підвищенням ліміту; великі повідомлення значно збільшують тимчасове використання спул-історії.

Завдання 9: Перевірте IO-навантаження під час прийому повідомлень

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (mx1) 	01/04/2026 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.21    0.00    4.12   32.55    0.00   53.12

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
sda              3.00     64.00     0.00   0.00    2.10    21.33  220.00  18432.00    12.00   5.17   45.30    83.78   9.96  98.00

Що означає вивід: Високий %iowait і майже 100% завантаження диска свідчать про IO-bound стан сервера. Обробка великих повідомлень це лише посилить.

Рішення: Перед підвищенням ліміту виправте IO (швидше сховище, окремий spool, тонке налаштування конкуренції сканування). Інакше «інколи повільний» сервер перетвориться на «здебільшого недоступний».

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

cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_client_restrictions|smtpd_tls_security_level|smtpd_sasl_auth_enable'
smtpd_client_restrictions = permit_mynetworks, reject_unknown_client_hostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_tls_security_level = may
smtpd_sasl_auth_enable = yes

Що означає вивід: Релей дозволений лише для mynetworks (добре), а автентифіковані користувачі пропускаються. TLS — опційний (may), можливо це прийнятно залежно від політики.

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

Завдання 11: Знайдіть прогалини в обмеженнях швидкості (з’єднання та паралелізм повідомлень)

cr0x@server:~$ postconf -n | egrep 'smtpd_client_connection_count_limit|smtpd_client_message_rate_limit|smtpd_client_recipient_rate_limit'
smtpd_client_connection_count_limit = 50
smtpd_client_message_rate_limit = 0
smtpd_client_recipient_rate_limit = 0

Що означає вивід: Ліміт на кількість з’єднань є, а ліміти по повідомленнях і одержувачам вимкнені (0). Якщо ви підвищите розміри, зловмисники зможуть дорого коштувати системі.

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

Завдання 12: Виміряйте найбільші повідомлення, які ви вже обробляєте (перевірка реальності)

cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -n 5
38912044 /var/spool/postfix/deferred/9/9D2F21C03A
22100412 /var/spool/postfix/deferred/1/1A7B0D11F2
18000210 /var/spool/postfix/deferred/C/C2D11E9AA0
15011401 /var/spool/postfix/deferred/4/45B2A9B1C3
12000877 /var/spool/postfix/deferred/7/7CC9F1022B

Що означає вивід: У вас вже є ~39 МБ елементи у відкладених. Або ваш вхідний ліміт вищий, ніж ви думаєте, або ці повідомлення зросли пізніше через внутрішню обробку.

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

Завдання 13: Перевірте end-to-end доставку до відомого зовнішнього провайдера (неприємна правда)

cr0x@server:~$ swaks --server submission.example.net --port 587 --auth LOGIN --auth-user user@example.com --auth-password 'REDACTED' --tls --to external-test@remote.tld --from user@example.com --attach /tmp/25mb.bin
=== Trying submission.example.net:587...
=== Connected to submission.example.net.
<  220 submission.example.net ESMTP Postfix
 > EHLO mx1.example.net
<  250-submission.example.net
<  250-SIZE 41943040
<  250-STARTTLS
<  250-AUTH PLAIN LOGIN
<  250 HELP
...
<  250 2.0.0 Ok: queued as 3F1A2B9C0D

Що означає вивід: Submission оголошує ~40 МБ, і повідомлення було прийняте і покладене в чергу. Це лише половина історії.

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

Завдання 14: Слідкуйте за тим ID черги, поки повідомлення не буде доставлене або не відскочить

cr0x@server:~$ sudo journalctl -u postfix --since "10 min ago" | egrep '3F1A2B9C0D' | tail -n 8
Jan 04 10:20:18 mx1 postfix/qmgr[1022]: 3F1A2B9C0D: from=<user@example.com>, size=35781234, nrcpt=1 (queue active)
Jan 04 10:20:49 mx1 postfix/smtp[24110]: 3F1A2B9C0D: to=<external-test@remote.tld>, relay=mx.remote.tld[203.0.113.10]:25, delay=31, delays=0.2/0.1/10/21, dsn=5.2.3, status=bounced (host mx.remote.tld[203.0.113.10] said: 552 5.2.3 Message size exceeds fixed maximum message size (in reply to end of DATA command))

Що означає вивід: Ваша система прийняла і спробувала доставити ~35.8 МБ повідомлення, але віддалений домен відхилив його з 552 в кінці DATA.

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

Завдання 15: Підтвердіть продуктивність фільтра контенту та беклог (приклад grep для Amavis-подібних логів)

cr0x@server:~$ sudo journalctl --since "30 min ago" | egrep 'amavis|clamd|timeout|too large' | tail -n 8
Jan 04 10:18:03 mx1 amavis[1888]: TIMING [abc123]: smb=0.012 (0.012+0.000) out=0.004 (0.004+0.000) m=1.234 (1.221+0.013)
Jan 04 10:18:04 mx1 amavis[1888]: (1888-12) WARN: timed out while scanning, quarantined
Jan 04 10:18:05 mx1 postfix/smtp[24002]: warning: conversation with content-filter.example.net[192.0.2.25] timed out while sending message body

Що означає вивід: Сканування тайм-аутиться, і Postfix втрачає час під час передачі повідомлення фільтру. Більші повідомлення викликатимуть більше таких випадків.

Рішення: Налаштуйте таймаути і конкуренцію фільтрів, масштабуйтесь на рівні фільтрів або тримайте ліміти консервативними. Ваш вузький місце — сканування, а не SMTP.

Завдання 16: Перевірте TLS та таймаути сесій, що важливі для великих payload-ів

cr0x@server:~$ postconf -n | egrep 'smtp_data_xfer_timeout|smtpd_timeout|smtpd_data_restrictions'
smtp_data_xfer_timeout = 180s
smtpd_timeout = 60s
smtpd_data_restrictions = reject_unauth_pipelining

Що означає вивід: Таймаут передачі даних для outbound — 180s; таймаут inbound сесії — 60s. Великі завантаження з повільних клієнтів можуть обриватись.

Рішення: Збільшуйте таймаути обережно на шляху submission (аутентифіковані користувачі), але тримайте inbound MX жорсткішим, щоб зменшити ризик зловживань та витіснення ресурсів.

Контролі від зловживань при збільшенні лімітів

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

Розділіть зони довіри: вхідний MX проти аутентифікованого submission

Не застосовуйте однакову політику до анонімних інтернет-відправників і автентифікованих співробітників. Це не одна й та сама модель загрози.
Чисте налаштування:

• Вхідний MX: нижчий ліміт, жорсткі таймаути, агресивне обмеження швидкості, раннє відхилення.
• Submission (587/465): вищий ліміт, обмеження на рівні користувача, сильна автентифікація, моніторинг, прив’язаний до ідентичності.

Обмеження швидкості, які дійсно важливі

Для великих повідомлень обмеження швидкості — це не лише «повідомлень за хвилину». Це також:

• Паралельні з’єднання на IP клієнта (запобігає ордам завантажень).
• Паралельні доставки на домен (запобігає хвилям повторних спроб до проблемного віддаленого).
• Байти за одиницю часу (багато MTA цього не роблять прямо; апроксимують сесіями і лімітами повідомлень).

Ранні відмови: дешеві — прекрасні

Найкраща відмова — та, яку ви робите до того, як прочитаєте 80 МБ на диск і пропустите через три сканери.
Якщо ви знаєте, що партнерський домен приймає лише 10–15 МБ, не приймайте 40 МБ, спрямованих туди, а потім відкидайте. Це операційно неввічливо.
Використовуйте transport maps або політичні служби для застосування обмежень за призначенням, якщо ваш MTA це підтримує.

Контролі, засновані на ідентичності, для виходу

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

• Добові ліміти на рівні користувача (по повідомленнях і одержувачах).
• Контроль типів вкладень (блокувати виконувані файли, ризикові архіви).
• Алерти на аномальні великі відправлення: «Користувач, який ніколи не надсилав вкладення, тільки що відправив 60 листів по 30 МБ кожен.»

Жарт №2: Найшвидший спосіб дізнатися, що ваш ліміт занадто високий — побачити, як спамер використовує ваш SMTP як безкоштовний CDN.

Сховище та продуктивність: великі листи — це проблема диска в костюмі

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

Spool vs mailstore: тримайте їх окремо

Черга/спул Postfix — це тимчасовий робочий набір. Він потребує:

• передбачуваної латентності (низький await),
• запасу місця (headroom для сплесків),
• швидкої поведінки fsync (журнальна файл.система налаштована розумно),
• та ізоляції від компактування mailstore і бекапів.

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

Великі повідомлення змінюють IO-патерн

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

Сканування контенту — прихований податок на CPU/диск

Антивіруси й DLP можуть:

• розпаковувати архіви (збільшуючи обсяг роботи),
• збирати MIME-частини заново,
• застосовувати евристики, що зростають із розміром,
• і тримати повідомлення в тимчасовому сховищі під час сканування.

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

Таймаути — це не лише «мережа»

Великі повідомлення збільшують час у кожній фазі: завантаження, передача фільтру, сканування, чергування, доставлення. Таймаут, що був «безпечним» на 10 МБ, може бути неправильним для 40 МБ.
Але не вирішуйте це, просто зробивши всі таймаути величезними. Так ви дозволите slowloris-подібним сесіям займати сокети цілий день.
Жорсткі таймаути для анонімного вхідного трафіку, більш вільні — для аутентифікованого submission — повторюйте, поки це не стане політикою.

Три корпоративні міні-історії (що насправді відбувається)

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

Середня компанія мала на вигляд чистий стек: вхідні шлюзи, Postfix, фільтрація контенту, поштове сховище. Служба підтримки отримала тікети: «Не можу надіслати 20–30 МБ файли клієнтам».
Поштовий адміністратор підвищив message_size_limit на вхідних шлюзах і вирішив, що завдання виконане. Всім аплодували.

Через два дні черги на виході почали зростати. Спочатку помірно — поступове збільшення. Потім настала понеділкова ранкова рутина. Користувачі почали надсилати більші вкладення партнерам, шлюз їх приймав, а вихідні доставлення почали відхилятися з 552 від кількох доменів отримувачів.
У черзі опинилася купа великих, недоставлених повідомлень. Кожна спроба повтору додавала лог-шум, більше обертів диска і ще більше плутанини.

Хибне припущення було просте: «Якщо ми приймаємо більше, воно буде доставлено». Інтернет не підписує ваш внутрішній політичний документ.
Багато доменів отримувачів примушують обмеження 10–25 МБ і не йдуть на компроміс. Ваш MTA дізнається про це лише після читання повного DATA-пейлоаду й спроби доставки.

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

Справжній урок: ви не просто піднімаєте ліміт; ви змінюєте форму трафіку. А форма трафіку змінює ваші режими відмови.

Міні-історія 2: Оптимізація, що зіграла злий жарт

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

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

Оптимізація базувалась на хибній передумові: «розмір корелює з безпекою». Атакувальники можуть дозволити собі байти. Ви не можете дозволити собі сліпу довіру.
Великі вкладення краще приховують payload-и і виснажують системи; вони не «ймовірно безпечні».

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

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

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

Вони провели навантажувальні тести: десять паралельних відправлень по 35 МБ, потім двадцять, потім змішане навантаження з нормальної пошти і великих повідомлень.
Спостерігали диск IO, латентність фільтрів, розміри черги і продуктивність запису в поштове сховище. Вони не гадали. Вони міряли.

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

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

Практика, що їх врятувала, була не модним інструментом, а end-to-end тестуванням з реалістичними вузькими місцями.

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

Покроковий план безпечного підвищення лімітів

1. Уточніть бізнес-вимогу в байтах, а не в емоціях. «25 МБ вкладень» — не технічне значення. Визначте цільовий розмір вкладення і порахуйте мережевий розмір з накладними витратами (плануйте ~1.35x для base64/MIME).
2. Змоделюйте реальний поштовий шлях. Намалюйте ланцюг: клієнт → submission → шлюзи → фільтри → mailstore → outbound. Включіть проксі, DLP, архівування, журналювання та бекапи.
3. Знайдіть поточні обмеження на кожному шарі. Налаштування MTA, проксі, фільтрів, ліміти поштових скриньок, квоти, обмеження конекторів.
4. Виберіть окремі ліміти за зонами довіри. Вхідний MX — нижчий; автентифікований submission може бути вищим з контролями на рівні користувача.
5. Перевірте поведінку сканування і тимчасового зберігання. Знайте, де великі повідомлення тимчасово зберігаються під час сканування і що заповнюється першим (диск, inode, RAM, tmpfs).
6. Складіть план ємності для спулу. Розмір черги в найгіршому випадку: врахуйте віддалені відмови, коли повідомлення відкладаються на години. Великі повідомлення роблять «години» дорогими.
7. Впровадьте обмеження швидкості і контролі ідентичності перед підвищенням. Не відкривайте більшу поверхню атаки без засобів контролю.
8. Піднімайте ліміти поступово. Приклад: 10 МБ → 20 МБ → 35–40 МБ по мережі. Спостерігайте після кожного кроку.
9. Тестуйте енд-ту-енд з реальними клієнтами та SMTP-інструментами. Перевірте і submission, і inbound. Перевірте доставку до поширених зовнішніх доменів.
10. Оновіть інструкції для користувачів. Зробіть шлях «що робити, якщо повідомлення відхилено» чітким: обмін посиланнями, поради зі стиснення, захищений трансфер.
11. Додайте дашборди і алерти, специфічні для навантаження великими листами. Черга, відкладені за розміром, таймаути фільтрів, IO wait, використання тимчасових файлових систем.
12. Після зміни проведіть рев’ю. Шукайте зміни: збільшення середнього розміру повідомлення, турбулентність черги, зростання кількості повторних спроб, підвищення латентності сканування.

Go/no-go контрольний список для вікна змін

• Файлова система для spool має щонайменше 30–40% вільного місця і здорову IO-латентність під навантаженням.
• Рівень фільтрів контенту має резерв потужності; під час тестового навантаження в логах немає таймаутів.
• Submission і вхідні прослуховувачі мають чітко різні політики.
• Обмеження швидкості встановлені і протестовані (включно з поведінкою при хибних спрацюваннях).
• Моніторинг присутній для росту черги, кількостей відкладених і трендів використання диска.
• План відкату написаний і швидкий (один реверт конфига + reload).
• Комунікація для користувачів готова: «Деякі зовнішні отримувачі все ще можуть відхиляти повідомлення понад X МБ; використовуйте Y замість цього.»

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

1) Симптом: Користувачі досі не можуть надсилати великі вкладення після підвищення Postfix

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

Виправлення: Перевірте прослуховувач аутентифікованого submission (587/465) окремо, підтвердіть оголошення SIZE через swaks, і перевірте будь-який webmail/proxy client_max_body_size або еквівалент.

2) Симптом: Пошта приймається, але відскакує через кілька годин

Корінь проблеми: Віддалені домени відкидають великі повідомлення (552) і ваш сервер повторює спроби до bounce; або downstream-фільтр/поштове сховище відкидає після прийняття.

Виправлення: Слідкуйте за ID черги. Якщо віддалені відхилення, встановіть обмеження/поради в залежності від призначення. Якщо внутрішні компоненти відхиляють, узгодьте капи між фільтрами і сховищем, щоб відхилення відбувалось рано, на SMTP.

3) Симптом: Розмір черги вибухає після підвищення ліміту

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

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

4) Симптом: В логах з’являються випадкові «timeout» під час великих відправлень

Корінь проблеми: Проксі idle timeouts, backlog у фільтрі контенту або насичення IO диска, що уповільнює обробку.

Виправлення: Збільшіть таймаути тільки на шляхах submission, масштабуйтесь у фільтрах і усуньте IO-вузькі місця. Не просто збільшуйте таймаути глобально; це приверне ресурсоємні сесії.

5) Симптом: Диск заповнюється, хоча середній обсяг пошти майже не змінився

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

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

6) Симптом: Деякі користувачі можуть надсилати великі листи, інші — ні

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

Виправлення: Перелічіть усі прослуховувачі та конектори; уніфікуйте політику. Документуйте винятки явно, замість того, щоб виявляти їх за скаргами користувачів.

7) Симптом: Команда безпеки повідомляє про збільшення виявлених загроз після підвищення лімітів

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

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

8) Симптом: IMAP/webmail після зміни почувається повільно

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

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

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

1) Якщо ми встановимо ліміт 100 МБ, чи партнери зможуть отримати 100 МБ?

Не надійно. Багато віддалених доменів відкинуть значно раніше, часто у діапазоні 10–25 МБ. Ваш сервер прийме, поставить у чергу, повторить спроби, а потім відкине.
Якщо вам потрібна гарантована передача, використовуйте механізм файлового обміну і надсилайте посилання.

2) Як перерахувати «ліміт вкладення» в байти MTA?

Плануйте накладні витрати base64/MIME. Приблизне правило: помножте бажаний розмір вкладення на ~1.35, щоб отримати безпечний таргет для message_size_limit, і додайте трохи на заголовки та multipart-структуру.
Тестуйте з реальними типами файлів і клієнтами; деякі клієнти додають інше додаткове збільшення.

3) Чи повинні вхідні та вихідні ліміти бути однаковими?

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

4) Який найбільший операційний ризик при підвищенні розміру?

Вибух черги і заповнення сховища під час відмов зовнішньої доставки. Великі відкладені повідомлення швидко споживають місце в spool і підвищують вартість повторних спроб.
Другий за величиною ризик — насичення/таймаути фільтрів.

5) Чому ми бачимо «accepted», а потім bounce пізніше?

Прийняття SMTP означає, що ваш сервер узяв на себе відповідальність за доставку. Це не означає, що одержувач прийме.
Також downstream-компоненти (фільтри, DLP, сховище) можуть відхилити після прийняття, якщо їхні ліміти нижчі.

6) Хіба не можна просто збільшити таймаути, щоб великі відправлення не падали?

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

7) Як запобігти зловживанню, якщо дозволити більші вихідні вкладення?

Використовуйте добові ліміти на користувача і по IP, моніторьте аномалії великих відправлень і застосовуйте політики типів вкладень. Переконайтесь, що автентифікація сильна (MFA де можливо) і що скомпрометований акаунт не може безмежно надсилати великі payload-и.

8) Що слід моніторити після підвищення ліміту?

Глибину черги (active/deferred), розподіл розмірів у черзі, використання диска та inode на spool/temp, IO wait, таймаути фільтрів і показники відскоків на виході (особливо 552/5.2.3).
Також відстежуйте «прийнято, а потім відкинуто» — це дорогі відмови.

9) Краще відхиляти великі повідомлення на етапі SMTP чи приймати і обробляти пізніше?

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

10) Що ми кажемо користувачам, коли отримувач відхиляє великі повідомлення?

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

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

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

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

• Перелічіть ліміти енд-ту-енд: submission, вхідний MX, проксі, фільтри, сховище, квоти.
• Проведіть два контрольованих тести: одне велике повідомлення від внутрішнього клієнта до внутрішньої скриньки; одне — до поширеного зовнішнього домену. Слідкуйте за ID черги до фінального статусу.
• Виправте найімовірніше вузьке місце: запас місця/IO для спулу, таймаути фільтрів або неузгоджені капи.
• Впровадьте запобіжні заходи перед підвищенням: обмеження швидкості, контролі на рівні користувача, моніторинг тиску від великих повідомлень.
• Піднімайте ліміти поетапно і спостерігайте метрики так, ніби дорослий наглядає за дитиною біля відкритих сходів.

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