TLS-RPT для електронної пошти: отримайте видимість збоїв TLS (і виправте їх)

Що таке TLS‑RPT насправді (і чим він не є)

TLS‑RPT (Transport Layer Security Reporting) — це стандарт, який дозволяє відправникам електронної пошти повідомляти власнику домену, коли у них виникли проблеми з доставкою пошти до цього домену через TLS.
Ключова фраза — «коли у них виникли проблеми»: це звітування про збої, а не самостійна функція безпеки.

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

Чим це не є

• Не примус до шифрування. TLS‑RPT не змушує нікого використовувати TLS. Це роблять MTA‑STS (політика) або DANE (через DNSSEC).
• Не захист контенту повідомлення. Йдеться про SMTP‑хоп транспорту, а не про наскрізне шифрування типу S/MIME чи PGP.
• Не миттєво. Більшість звітів доставляються пакетно. Ви отримуєте сигнал, але не миттєвий тривожний виклик.

Думайте про TLS‑RPT як про димові датчики: вони не запобігають пожежам, але підказують, де дим.

Чому це має значення (навіть якщо у вас «вже є TLS»)

«Ми використовуємо STARTTLS» — це еквівалент у світі електронної пошти фрази «у нас є бекапи». Чудово. А тепер покажіть мені тест відновлення.
STARTTLS за замовчуванням є опортуністичним: якщо TLS не встановився, багато відправників перейдуть на незашифрований режим, якщо політика не вимагає інакше.
Без телеметрії вас можуть понижувати в захищеності і ви цього не помітите. Або ви можете зламати вхідну доставку для підмножини відправників і дізнатися про це лише коли хтось не отримає листа про продовження контракту.

TLS‑RPT дає вам:

• Видимість реальних збоїв по всій екосистемі: проблеми з сертифікатами, невідповідність імен, версії протоколів, шифри, дивні SMTP‑банери, тайм‑аути мережі та невідповідності політик.
• Докази для відлагодження з третіми сторонами: «Ваші звіти показують, що ви не проходите валідацію проти mx2; ось тип помилки і часовий проміжок.»
• Раннє попередження коли хтось щось змінює: новий балансувальник навантаження, новий ланцюжок сертифікатів, зламаний проміжний, зміна DNS, правило брандмауера.
• Виявлення атак на зниження рівня захисту або перехоплення: якщо багато відправників раптово почнуть повідомляти про збої, які раніше не були, щось може перебувати на шляху.

Жарт №1: Електронна пошта — це найстаріша розподілена система, якою керує багато компаній. Вона старіє як вино — якщо іноді вино не загоряється.

Факти та невелика історія, що важливі в продакшні

Короткі, конкретні контекстні пункти, які змінюють підхід до експлуатації цього механізму:

1. SMTP з’явився задовго до повсюдного шифрування. STARTTLS було пристосовано пізніше, тому «опортуністичний TLS» став культурною нормою за замовчуванням.
2. TLS‑RPT стандартизовано у 2018 році (RFC 8460), головним чином щоб зробити MTA‑STS оперативно життєздатним в масштабі Інтернету.
3. MTA‑STS з’явився через реальність пониження STARTTLS: атакувачі могли видаляти оголошення про STARTTLS або викликати помилки, щоб змусити перехід на незашифрований режим.
4. DANE існував раніше (записи TLSA з DNSSEC), але прийняття непостійне через різний рівень впровадження DNSSEC і операційний комфорт у організацій.
5. Великі поштові провайдери сприяли прийняттю форматів звітів, бо їм потрібні були сигнали без ручного створення тікетів при великих обсягах.
6. Звіти стосуються спроб доставки, а не ваших MTA‑логів. Це означає, що вони фіксують збої, які навіть не дісталися до вашої інфраструктури (наприклад, блокування в мережі або помилки TLS до SMTP DATA).
7. Звіти агреговані: ви побачите підсумки та типи збоїв, а не деталі на рівні кожного повідомлення. Це саме перевага, а не недолік.
8. Звіти можуть виявляти дрейф екосистеми: старі версії TLS і застарілі шифри все ще з’являються в хвості, особливо в пристроях і старих MTA.

Як TLS‑RPT працює від початку до кінця

Рухомі частини

• Ваш домен: публікує DNS‑запис TLS‑RPT на _smtp._tls.
• Відправники: MTA, що намагаються доставити на ваші MX‑хости. Якщо вони підтримують TLS‑RPT, вони збирають телеметрію про збої.
• Ваш приймач звітів: адреса електронної пошти (або HTTPS‑ендпоїнт), що приймає JSON‑звіти, часто стиснуті і прикріплені.
• Опційна політика примусу: політика MTA‑STS (_mta-sts + HTTPS‑файл політики) або DANE TLSA‑записи. TLS‑RPT стає значно кориснішим, коли щось застосовується суворо.

Життєвий цикл

1. Ви публікуєте _smtp._tls.example.com TXT з записом v=TLSRPTv1, що вказує, куди надсилати звіти.
2. Відправник намагається доставити до example.com, погоджує STARTTLS і перевіряє політики, які він підтримує (MTA‑STS, DANE, локальні правила).
3. Якщо відправник не може встановити TLS, коли це очікувалося, або якщо проходить провал валідації політики (наприклад, невідповідність сертифіката до очікувань MTA‑STS), він фіксує подію.
4. Періодично відправник надсилає вам звіт, що описує кількість успішних/невдалих сесій і причини збоїв, згруповані за призначенням і типами результатів.
5. Ви інґестите їх у щось пошукове (навіть якщо це «поштова скринька плюс скрипт»). Далі вирішуєте: виправити конфіг, DNS, ланцюжок сертифікатів або відкрити тікет у мережевій/безпековій команді.

Чому це — оперативне золото

Збої SMTP часто асиметричні. Ваші логи можуть нічого не показувати, бо з’єднання ніколи не досягало вас або обірвалося до того, як ваш MTA записав корисну інформацію.
TLS‑RPT дає вам перспективу відправника. У розподілених системах це та частина правди, якої вам звично не вистачає.

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

DNS‑записи, які ви опублікуєте (із розумними значеннями за замовчуванням)

Основи TXT‑запису TLS‑RPT

Запис розташовується на _smtp._tls.<domain>. Це TXT‑запис, значення якого починається з v=TLSRPTv1 і містить одну або кілька URI для звітів через rua=.
Зазвичай використовують mailto:, бо це просто і сумісно.

Приклади записів

Мінімальний mailto:

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Кілька одержувачів (корисно під час розгортання):

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com,mailto:mailops@example.net"

HTTPS‑ендпоінт (важче налаштувати правильно, але автоматизується):

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=https://tlsrpt-api.example.com/v1/report"

Накопичений досвід

• Почніть з mailto, якщо немає сильної причини інакше. HTTPS‑ендпоінти вимагають рішень щодо автентифікації, обмеження швидкості, зберігання і безпекового огляду. Mailto потребує поштової скриньки та гігієни.
• Використовуйте виділений псевдонім на кшталт tlsrpt@, що надходить у тікетну систему або моніторовану скриньку, а не в особисту пошту співробітника.
• Не публікуйте TLS‑RPT без базової гігієни TLS. Ви отримаєте звіти, але вони будуть шумом, поки ви не виправите очевидні проблеми (погані ланцюжки, неправильні імена, старі протоколи).

Що містять звіти і як їх читати

Звіти TLS‑RPT — це JSON‑документи, які описують:

• Метадані звіту: назва організації‑репортера, діапазон дат звіту.
• Оцінені політики: наприклад «no‑policy‑found» або «sts» з деталями.
• Результати: кількості успішних і невдалих спроб, а також типи помилок, такі як відмова TLS‑переговору, помилка валідації сертифіката або невідповідність політики.
• Кінцеві точки: MX‑хости призначення та IP‑адреси, до яких відправник намагався підключитися.

На що дивитися перш за все

1. Виявлення стрибків: чи збільшилися збої порівняно з попереднім днем?
2. Концентрація: чи це один MX‑хост, одна IP, один регіон, один відправник?
3. Клас помилок: помилки рукостискання/протоколу проти проблем PKI проти політики.
4. Послідовність: чи погоджуються кілька репортерів? Один відправник, що не проходить — може бути його баг. Багато, що не проходять — зазвичай справа у вас (або в мережі між вами).

Інтерпретація поширених тем помилок

• Невідповідність імені в сертифікаті: ваше MX‑ім’я не співпадає з сертифікатом або на одному вузлі подається неправильний сертифікат.
• Невідомий CA / недовірений ланцюг: відсутні проміжні сертифікати або випадково подано корпоративний ланцюг.
• Повідомлення про версії TLS: деякі відправники не використовуватимуть застарілі версії TLS; інші не зможуть працювати лише з новими конфігураціями.
• Невідповідності політик: MTA‑STS вимагає «enforce», але ваш сервер не відповідає вимогам.
• Збої з’єднань: брандмауер, маршрутизація, сірі збої або неправдиві перевірки стану балансувальника.

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

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

Коли ви бачите збої TLS‑RPT, утримайтеся від спокуси почати міняти набори шифрів, ніби ви трясете торговий автомат.
Спочатку класифікуйте. Потім виправляйте.

Перше: визначте радіус ураження

• Чи це один MX‑адресат чи всі?
• Чи це один відправник чи багато?
• Чи це одна IP‑адреса за балансувальником?
• Чи почалося це після деплою, ротації сертифікатів, зміни DNS або зміни брандмауера?

Друге: класифікуйте помилку

• Помилки рукостискання: версія протоколу, невідповідність шифрів, видалення STARTTLS, тайм‑аути.
• PKI‑помилки: ланцюг, прострочення, невідповідність імені, поведінка при відкликанні.
• Помилки політики: невідповідність MTA‑STS, DANE‑невідповідність, «нема політики», коли ви очікували.
• Мережеві помилки: доступність TCP/25, асиметрична маршрутизація, NAT‑hairpin, втручання IDS.

Третє: відтворіть зовні

• Протестуйте STARTTLS за допомогою openssl s_client проти кожного MX‑хоста і кожної IP‑адреси.
• Перевірте розв’язання DNS і порядок MX з кількох резолверів.
• Перевірте, який сертифікат подається на кожному вузлі (балансувальники часто мають часткові релізи).
• Якщо задіяно MTA‑STS, підтвердіть доступність файлу політики і його коректність.

Четверте: вирішіть, що змінювати

• Якщо не вдається відтворити зовні, підозрюйте відправника — їхню політику або відмінності в валідації.
• Якщо це тільки одна IP, виведіть її з пулу і виправте конфігураційний дрейф.
• Якщо проблема з ланцюгом, виправте поданий ланцюг до ротації leaf‑сертифіката (ротація без проміжних не виправить проблему).
• Якщо це тайм‑аути, перевірте параметри брандмауера та таймери handshake у балансувальника.

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

Це ті завдання, які я реально виконую, коли TLS‑RPT починає пищати. Кожне містить: команду, що означає вивід, і рішення, яке треба прийняти.
Припускайте інструменти Linux і типовий Postfix‑світ; адаптуйте за потреби.

Завдання 1: Підтвердити, що запис TLS‑RPT існує і саме такий, як ви думаєте

cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

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

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

Завдання 2: Перевірити MX‑записи і знайти split‑horizon або застарілі зміни

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

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

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

Завдання 3: Розв’язати кожен MX у всі A/AAAA записи (дрейф multi‑IP частий)

cr0x@server:~$ dig +short A mx1.example.com
203.0.113.10
203.0.113.11

Що це означає: У вас є кілька фронтендів під одним MX‑іменем.

Рішення: Тестуйте TLS проти кожної IP. Один поганий вузол може отруїти вашу репутацію і доставку.

Завдання 4: Перевірити доступність TCP/25 з вашої точки

cr0x@server:~$ nc -vz mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!

Що це означає: Базова підключеність існує з цього ракурсу.

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

Завдання 5: Поговорити SMTP і підтвердити, що STARTTLS анонсовано

cr0x@server:~$ printf "EHLO test.example\r\nQUIT\r\n" | nc -w 3 mx1.example.com 25
220 mx1.example.com ESMTP
250-mx1.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
221 Bye

Що це означає: Сервер пропонує STARTTLS, тож опортуністичний TLS можливий.

Рішення: Якщо STARTTLS несподівано відсутній, перевірте конфіг MTA, налаштування TLS‑оффлоаду та будь‑які SMTP‑проксі спереду.

Завдання 6: Виконати STARTTLS‑handshake і перевірити поданий сертифікат

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 

CONNECTED(00000003)
depth=2 C=US, O=Example Root CA, CN=Example Root CA G2
verify return:1
depth=1 C=US, O=Example Issuing CA, CN=Example Issuing CA R3
verify return:1
depth=0 CN=mx1.example.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
---
250 2.0.0 Ready to start TLS

Що це означає: TLS узгоджується, ланцюг верифікується, SNI працює, і ваш ендпоінт подає очікуваний сертифікат.

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

Завдання 7: Перевірити дати дійсності сертифіката (щоб уникнути «сюрпризного» простою)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 2>/dev/null | openssl x509 -noout -dates -subject
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT
subject=CN = mx1.example.com

Що це означає: Сертифікат зараз дійсний і має чітку дату закінчення.

Рішення: Якщо термін добігає кінця, плануйте ротацію заздалегідь. TLS‑RPT розповість про збої постфактум; краще запобігти.

Завдання 8: Підтвердити повний сертифікатний ланцюг, що подається (відсутній проміжний — класика)

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++} {print > ("cert" i ".pem")}'

cr0x@server:~$ for f in cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer < "$f"; done
== cert1.pem ==
subject=CN = mx1.example.com
issuer=C=US, O=Example Issuing CA, CN=Example Issuing CA R3
== cert2.pem ==
subject=C=US, O=Example Issuing CA, CN=Example Issuing CA R3
issuer=C=US, O=Example Root CA, CN=Example Root CA G2

Що це означає: Ви подаєте принаймні leaf + intermediate. Добре.

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

Завдання 9: Перевірити, які шифри/протоколи підтримує ваш SMTP‑ендпоінт (і чи ви відсікаєте застарілих відправників)

cr0x@server:~$ nmap --script ssl-enum-ciphers -p 25 mx1.example.com
Starting Nmap 7.94 ( https://nmap.org ) at 2026-01-03 10:11 UTC
Nmap scan report for mx1.example.com (203.0.113.10)
PORT   STATE SERVICE
25/tcp open  smtp
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLSv1.3:
|     ciphers:
|       TLS_AES_256_GCM_SHA384 - A
|_  least strength: A

Що це означає: Ви підтримуєте сучасний TLS. Добра безпекова позиція.

Рішення: Якщо бізнес вимагає сумісності зі старими системами, подумайте, чи спричинить відмова від TLSv1.0/1.1 реальні проблеми доставки. Використайте TLS‑RPT, щоб виміряти перед послабленням.

Завдання 10: У Postfix підтвердити, що runtime‑налаштування TLS збігаються з очікуваними

cr0x@server:~$ postconf -n | egrep '(^smtpd_tls_|^smtp_tls_|^smtpd_tls_security_level|^smtp_tls_security_level)'
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_loglevel = 1

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

Рішення: Якщо smtpd_tls_cert_file вказує на невірний файл на одному хості, ви отримаєте TLS‑RPT‑збої, сконцентровані на цій IP. Виправляйте дрейф; не сперечайтеся з математикою.

Завдання 11: Переглянути поштові логи на предмет помилок TLS‑handshake на сервері

cr0x@server:~$ sudo grep -E 'TLS|STARTTLS|SSL_accept|handshake' /var/log/maillog | tail -n 10
Jan 03 10:01:44 mx1 postfix/smtpd[22131]: Anonymous TLS connection established from mail-oi1-f180.google.com[209.85.167.180]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
Jan 03 10:02:09 mx1 postfix/smtpd[22155]: warning: TLS library problem: error:0A000126:SSL routines::unexpected eof while reading

Що це означає: У вас є принаймні одна аномалія рукостискання. «Unexpected EOF» часто вказує на middlebox‑и або клієнти, що примусово обрізають з’єднання.

Рішення: Якщо TLS‑RPT показує багато збоїв від кількох відправників і ви бачите сервер‑сторонні handshake‑помилки, перевірте мережеві пристрої (брандмауери/IDS) і обмеження швидкості.

Завдання 12: Підтвердити, який файл сертифіката реально використовує ваш TLS‑термінатор (стиль Nginx/HAProxy)

cr0x@server:~$ sudo haproxy -c -f /etc/haproxy/haproxy.cfg
Configuration file is valid

Що це означає: Принаймні конфіг парситься. Це мінімальна перевірка, а не гарантія.

Рішення: Якщо TLS‑RPT вказує на невідповідність сертифіката, перевірте шляхи crt для кожного frontend і поведінку перезавантаження. Часткові перезавантаження створюють хаос «деякі клієнти падають».

Завдання 13: Перевірити наявність DNS для MTA‑STS (якщо ви заявляєте про примус TLS)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260103T001"

Що це означає: Ви опублікували ідентифікатор версії політики MTA‑STS.

Рішення: Якщо TLS‑RPT каже «no policy found», але ви очікуєте примусу, ваш DNS‑запис відсутній, помилковий або не видимий публічно.

Завдання 14: Перевірити, що файл політики MTA‑STS доступний і коректний

cr0x@server:~$ curl -sS -D- https://mta-sts.example.com/.well-known/mta-sts.txt | sed -n '1,25p'
HTTP/2 200
content-type: text/plain
content-length: 128

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

Що це означає: Політика доступна по HTTPS і вказує ваші MX‑хости.

Рішення: Якщо це повертає 404, дивні редиректи або перелічує неправильні MX‑імена, виправте негайно. Інакше відправники, що застосовують MTA‑STS, будуть вважати вас «потрібно TLS, але не виконується».

Завдання 15: Перевірити позицію DNSSEC/DANE (якщо ви це використовуєте) і уникати напівконфігурацій

cr0x@server:~$ dig +short TLSA _25._tcp.mx1.example.com
3 1 1 aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899

Що це означає: Існує запис TLSA для SMTP на порті 25 до mx1.

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

Завдання 16: Розпакувати і переглянути вкладений JSON‑звіт TLS‑RPT, який ви отримали

cr0x@server:~$ ls -1
tlsrpt-report-2026-01-02.json.gz

cr0x@server:~$ gzip -dc tlsrpt-report-2026-01-02.json.gz | head -n 30
{
  "organization-name": "Example Sender",
  "date-range": {
    "start-datetime": "2026-01-02T00:00:00Z",
    "end-datetime": "2026-01-03T00:00:00Z"
  },
  "report-id": "abc123",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce"
        ],
        "mx-host": [
          "mx1.example.com",
          "mx2.example.com"
        ]
      },
      "summary": {
        "total-successful-session-count": 984,
        "total-failure-session-count": 27
      }
    }
  ]
}

Що це означає: Звіт підтверджує, що була оцінена STS‑політика і пораховані успіхи проти збоїв.

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

Три корпоративні міні‑історії з польових робіт

1) Інцидент через неправильне припущення: «Балансувальник навантаження скрізь показує один і той же сертифікат»

Середня SaaS‑компанія мала два MX‑хости за регіональним балансувальником. Команда мала процес ротації сертифікатів для вебу і вважала, що пошта — «те саме».
У їхній ментальній моделі SMTP був просто TCP‑сервісом з TLS і сертифікатом. Ротувати бандл сертифікатів централізовано, перезавантажити балансувальник — і все.

Потім почали надходити TLS‑RPT‑звіти: кілька великих відправників повідомляли «certificate validation failure» для одного MX‑хоста, але не для іншого.
Операційник подивився на первинний регіон, протестував STARTTLS зі свого ноутбука, і все працювало. Він закрив тікет як «флік від відправника».

Наступного дня кількість збоїв подвоїлась. Шаблон був дивний: деякі відправники проходили, деякі — ні, і це не корелювалося з часом доби.
TLS‑RPT дав відповідь прямо: збої були прив’язані до однієї IP‑адреси, а не до імені MX. Балансувальник мав застарілий бекенд, який все ще подавав старий ланцюг без проміжного.

Хибне припущення було тонким: вони вірили «балансувальник термінує TLS, тож бекенди не мають значення». Насправді для SMTP у них був TLS‑pass‑through, щоб зберегти клієнтські IP.
Балансувальник був просунутим маршрутизатором, а не TLS‑ендпоінтом. Один бекенд мав застарілий fullchain.pem.

Виправлення було нудним: уніфікувати деплой сертифікатів, забезпечити конфігураційне управління на поштових вузлах і додати зовнішню перевірку STARTTLS по IP.
TLS‑RPT не просто повідомив про помилку; він дав підказку про топологію, якої не було в серверних логах, бо більшість невдалих з’єднань навіть не доходили до вузла, який вони відслідковували.

2) Оптимізація, що відбилася боком: «Відключити TLSv1.2, щоб зменшити навантаження на CPU»

ІТ‑група підприємства вирішила «модернізувати» межу пошти. Вони помітили зростання використання TLSv1.3 і хотіли спростити конфігурації, зменшити розкид списків шифрів і узгодити з внутрішніми стандартами.
Хтось запропонував: повністю вимкнути TLSv1.2 на вхідному SMTP. Менше переговорів, менше складності, менше поверхні атак.

На папері це виглядало чисто. У лабораторії сучасні MTA швидко погоджували TLSv1.3. Графіки CPU стали трохи кращими. Команда безпеки дала згоду.
Зміни пішли в продакшн у п’ятницю після обіду — бо як же інакше.

В понеділок вранці кілька бізнес‑партнерів не змогли відправити їм листи. Не всі. Досить, щоб викликати незадоволення керівництва.
Їхні серверні логи показували менше вхідних підключень, але без однозначного винуватця. МТА, які не могли домовитися, просто не доставляли повідомлення.

TLS‑RPT‑звіт прийшов наступного дня з послідовним класом збоїв: negotiation failures, сгруповані за набором партнерських організацій і старих MTA.
Ці партнери не були «ненадійними» у зловмисному сенсі; вони стояли за пристроями, які ще не підтримували TLSv1.3.

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

3) Нудна, але правильна практика, що врятувала день: «Тестувати STARTTLS на кожній IP щодня»

Фінансова компанія ставила пошту як регульований сервіс. Не гламурно, але послідовно. Вони мали MTA‑STS у режимі enforce і поштову скриньку TLS‑RPT, підключену до простого парсера.
Парсер не робив машинного навчання. Він рахував збої і сигналізував при перевищенні порогу.

Однієї ночі команда брандмауера вивела оновлення правил. Воно було не спрямоване на пошту. Воно стосувалося «невідомих вхідних сервісів».
TCP/25 залишився відкритим, але новий профіль інспекції почав термінувати з’єднання, які узгоджували TLSv1.3 з певними розширеннями.

Їхні щоденні зовнішні перевірки відразу це виявили: STARTTLS працював на одній IP, а на іншій — ні, і збігалося це з межами кластера брандмауера.
TLS‑RPT‑звіт наступного дня підтвердив це від кількох відправників: handshake failures були сконцентровані в тому ж діапазоні IP.

Оскільки вони мали нудну, але коректну практику — синтетичні перевірки по IP плюс сигнали TLS‑RPT — у них з’явився чистий наратив інциденту і швидкий запит на відкат.
Команда брандмауера відкотила профіль, пошта пішла, і нікому не довелося гадати, чи це «проблема Google».

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

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

1) Звіти показують «certificate validation failure» тільки для одного MX‑хоста

Симптом: Збої сконцентровані на mx2 або одній IP‑адресі за ним.

Корінь: Дрейф деплойменту сертифікатів, неправильна SNI‑мапа або один вузол подає неповний ланцюг.

Виправлення: Тестуйте кожну A/AAAA ціль через openssl s_client, потім уніфікуйте шляхи сертифікатів і поведінку перезавантаження на вузлах.

2) Звіти показують «no policy found», але ви вважаєте, що MTA‑STS увімкнено

Симптом: Репортери кажуть, що не знайшли STS; ви очікували оцінку «sts».

Корінь: Відсутній TXT‑запис _mta-sts, невірний субдомен або DNS не видимий публічно через split‑horizon.

Виправлення: Перевірте dig TXT _mta-sts.example.com з публічного резолвера і переконайтесь, що запис відповідає домену, який використовують відправники.

3) Звіти показують «policy validation failure» після нешкідливої зміни DNS

Симптом: Режим STS enforce починає падати одразу після зміни MX.

Корінь: Файл політики MTA‑STS все ще містить старі MX‑імена, або ви змінили пріоритет/hostname MX без оновлення політики.

Виправлення: Оновіть політику (рядки mx:), збільшіть id політики в _mta-sts і переконайтесь, що HTTPS‑файл доступний.

4) Раптовий сплеск «TLS negotiation failure» серед багатьох відправників

Симптом: Багато репортерів, багато збоїв, почалося в одному вікні часу.

Корінь: Зміни брандмауера/IDS, бага балансувальника або ви відключили TLSv1.2 і відсікли старих відправників.

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

5) Ви не отримуєте жодних звітів

Симптом: Скринька TLS‑RPT порожня тижнями.

Корінь: Немає запису TLS‑RPT, запис має помилку, скринька відхиляє великі вкладення або ви очікуєте, що всі відправники світу це підтримують.

Виправлення: Підтвердьте DNS‑запис, переконайтесь, що скринька приймає формат/розмір звітів, і перевірте, чи принаймні один великий відправник є у вашому вхідному трафіку.

6) Звіти приходять, але це марний «шум»

Симптом: Багато типів збоїв з малими кількостями; ви не можете вирішити, що важливе.

Корінь: Ви дивитесь на сирі звіти без агрегації, базових ліній або групування по призначеннях.

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

7) Увімкнення MTA‑STS у режимі enforce спричиняє відкладення доставки

Симптом: Деякі відправники відкладатимуть/відхилятимуть через політику, що вимагає TLS, і не можуть її підтвердити.

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

Виправлення: Спочатку працюйте в mode: testing, виправте збої за допомогою TLS‑RPT, а потім переключайтесь на enforce, коли стабільно.

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

Фаза 1: Запустити потік звітів (1–2 дні)

1. Створіть виділену поштову скриньку: tlsrpt@yourdomain. Направте її у моніторовану чергу (тікетна система або спільна скринька).
2. Опублікуйте TXT TLS‑RPT: _smtp._tls.yourdomain з v=TLSRPTv1; rua=mailto:....
3. Підтвердьте DNS з поза вашої мережі (кілька резолверів, не лише внутрішній).
4. Переконайтесь, що скринька приймає вкладення і не відкидає автоматизовані листи мовчки.

Фаза 2: Встановити базову лінію (перший тиждень)

1. Збирайте звіти протягом 7 днів без змін конфігурації. Ви будуєте базу, а не переможете в конкурсі краси.
2. Агрегуйте за іменем призначення MX, IP призначення і типом збоїв.
3. Визначте топ‑1–3 категорії збоїв. Ігноруйте довгий хвіст, поки не виправите верх.
4. Запускайте зовнішні перевірки STARTTLS проти кожної MX IP щоденно.

Фаза 3: Виправляти системно (безперервно)

1. Спершу виправте ланцюжок сертифікатів і невідповідності імен. Це високий вплив і детермінований результат.
2. Потім вирівняйте політику: переконайтеся, що MTA‑STS відповідає актуальній інвентаризації MX і що HTTPS‑ендпоінт стабільний.
3. Тонко налаштовуйте протоколи/шифри. Використовуйте TLS‑RPT, щоб виміряти вплив на сумісність до і після змін.
4. Коли стабільно, розгляньте MTA‑STS у режимі mode: enforce, якщо ваша модель загроз і бізнес це виправдовує.

Фаза 4: Зробіть це операційним (щоб пережило зміну персоналу)

1. Створіть on‑call рукопис з «Швидким планом діагностики» вище.
2. Додайте оповіщення: дельта‑рівень збоїв по MX/IP та «з’явився новий тип помилки».
3. Відстежуйте закінчення терміну дії сертифікатів для поштових ендпоінтів так само, як для вебу.
4. Переглядайте TLS‑RPT тижнево на зустрічах зміни: мета — ловити регресії, а не милуватися графіками.

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

1) Чи потрібен MTA‑STS, щоб використовувати TLS‑RPT?

Ні. TLS‑RPT працює самостійно. Але він цінніший, якщо ви також публікуєте політику примусу (MTA‑STS або DANE), бо збої стають дієвими і мають значення для безпеки.

2) Чи скаже TLS‑RPT, якщо повідомлення доставлено в незашифрованому вигляді?

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

3) Чому я бачу збої лише від одного відправника?

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

4) Чи безпечно отримувати TLS‑RPT‑звіти по email?

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

5) Чи слід мені використовувати HTTPS‑ендпоінт замість mailto?

Якщо у вас вже є надійна інфраструктура інґесту і ви хочете автоматизацію — HTTPS може бути відмінним варіантом. Якщо ні — mailto практичніший. Не будуйте крихку вебхукову систему для рідко перевіряного механізму.

6) Як швидко я почну отримувати звіти після публікації DNS‑запису?

Зазвичай протягом дня‑двох, залежно від каденції відправників і TTL DNS. Це не реальна телеметрія; це планові звіти.

7) Чи допомагає TLS‑RPT виявити атаки на зниження рівня захисту?

Може допомогти. Якщо у вас є MTA‑STS в режимі enforce (або DANE) і раптово з’являються масштабні TLS‑помилки, така картина може вказувати на втручання. Це не доказ, але сильний сигнал.

8) Яка найпоширеніша коренева причина помилок TLS‑RPT?

Проблеми з сертифікатами — особливо неповні ланцюжки і невідповідності на одному вузлі за іменем MX. Дрейф інфраструктури перемагає завжди.

9) Чи може TLS‑RPT зламати мою поштову доставку?

Ні. Публікація запису TLS‑RPT лише просить надсилати звіти. Рішення про примус приймають MTA‑STS або DANE, а не TLS‑RPT.

10) Як пріоритезувати виправлення, коли звіти показують багато типів збоїв?

Сортуйте за впливом: спочатку виправляйте збої, що впливають на багатьох відправників або на одного великого відправника, потім — помилки, прив’язані до одного MX/IP (швидкі перемоги), потім — налаштування політик, і врешті — загартування протоколів.

Висновок: наступні кроки, що дійсно знижують ризик

TLS‑RPT — один із тих рідкісних стандартів для пошти, що видається створеним людьми, які отримували виклики о 2‑й годині ночі.
Він не захистить SMTP магічно, але припинить ваше сліпе керування.

1. Опублікуйте _smtp._tls з виділеною скринькою tlsrpt@.
2. Протягом тижня агрегуйте звіти по MX/IP/типу помилки і встановіть базову лінію.
3. Спершу виправляйте детерміновані проблеми: ланцюг, невідповідність імен, дрейф по вузлах.
4. Якщо ви використовуєте MTA‑STS, перевірте HTTPS‑шлях політики і синхронізуйте його зі змінами MX.
5. Автоматизуйте дві речі: синтетичні перевірки STARTTLS по IP і оповіщення про дельти збоїв у TLS‑RPT.

Вам не потрібен ідеал. Потрібні зворотні петлі. TLS‑RPT дає вам одну зовні — той світ, через який фактично має проходити ваша пошта.