Як налаштувати MTA-STS і TLS-RPT для пошти

Як налаштувати MTA-STS і TLS-RPT для безпеки електронної пошти

MTA-STS дає змогу домену-одержувачу повідомити поштові системи-відправники, які поштові сервери мають приймати його повідомлення та що з’єднання з ними повинні використовувати надійний TLS. TLS-RPT додає звітність: відправники, які підтримують цю функцію, можуть надсилати вам інформацію про збої доставки через TLS і проблеми з політикою. Якщо ви з’ясовуєте, як налаштувати MTA-STS і TLS-RPT для безпеки електронної пошти, почніть із конфігурації вхідної пошти, а не із запису DNS; таке налаштування MTA-STS для домену допоможе спершу перевірити MX-хости й TLS.

Ці засоби не замінюють SPF, DKIM чи DMARC. Вони стосуються іншої частини процесу: зашифрованого з’єднання між поштовими серверами. Політика, у якій зазначено застарілий або неправильно налаштований MX-хост, може порушити доставку, тому перш ніж застосовувати її, перевірте всю конфігурацію.

1. Переконайтеся, що поштовий хостинг готовий

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

Перевіряйте конкретні імена, а не лише назву провайдера. У домену можуть бути MX-записи, наприклад mx1.mail.example.com і mx2.mail.example.com, хоча провайдер також використовує інші хости, не зазначені для вашого домену. Політика має охоплювати ті MX-хости, які можуть приймати пошту для домену.

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

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

2. Укажіть адресу для звітів TLS-RPT

Перш ніж публікувати запис DNS, визначте, куди надходитимуть звіти. Щоб зрозуміти, як увімкнути звіти TLS-RPT, спершу виберіть адресу призначення: це може бути поштова скринька, яка приймає звіти, або сервіс звітності TLS, що надає адресу електронної пошти чи HTTPS-адресу. Переконайтеся, що за цією адресою стежать і що ваша поштова система прийматиме туди звіти.

Опублікуйте TXT-запис для _smtp._tls.example.com, замінивши example.com на свій домен. Для адреси електронної пошти використовуйте такий формат значення: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Якщо сервіс звітності надає іншу адресу, вкажіть точний URI, який він пропонує.

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

Зміни DNS можуть з’являтися не одразу, оскільки резолвери кешують записи відповідно до їхнього TTL. Опублікувавши запис, перевірте його через авторитетний DNS-сервер і публічний резолвер та переконайтеся, що обидва повертають потрібне значення TXT. Через помилку в імені запису відправники можуть не побачити адресу призначення.

3. Розмістіть файл політики MTA-STS

Розмістіть політику за адресою https://mta-sts.example.com/.well-known/mta-sts.txt, замінивши example.com на власний домен. Адреса має бути доступною через HTTPS, а сертифікат — дійсним для хоста mta-sts.example.com. Файл у звичайній кореневій теці сайту не відповідатиме цій вимозі.

Політика має бути звичайним текстовим файлом. Для початкового тестування використайте такі поля:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

Замініть приклади MX-імен на фактичні хости, що приймають пошту для вашого домену. Значення max_age — це кількість секунд, протягом яких відправник може кешувати політику; у наведеному прикладі це один день. Коротший початковий період спростить коригування тестової політики, тоді як за довшого періоду відправники зберігатимуть її довше.

Перш ніж вмикати примусове застосування, використовуйте режим testing. У цьому режимі відправники можуть повідомляти про порушення політики, але не зобов’язані відхиляти пошту, яку неможливо доставити з дотриманням заданих вимог TLS. Перевірте URL-адресу з-поза вашої мережі й переконайтеся, що файл відкривається без авторизації, циклічного перенаправлення чи помилки вебзастосунку.

4. Опублікуйте запис виявлення MTA-STS

Відправники знаходять політику через TXT-запис для _mta-sts.example.com. Його значення містить версію та ідентифікатор політики, наприклад: v=STSv1; id=20261104a. Виберіть ідентифікатор, який можна відстежити в журналі змін, замість того щоб повторно використовувати старий.

Змінюйте ідентифікатор щоразу, коли публікуєте оновлений файл політики. Так поштові системи-відправники дізнаються, що потрібно перевірити наявність нової версії, а не покладатися лише на кешовану копію. Ідентифікатор слугує сигналом для виявлення політики, але не замінює сам файл чи його розміщення через HTTPS.

Публікуйте запис лише після того, як файл політики стане доступним за потрібною адресою. Потім перевірте TXT-запис і відкрийте URL із зовнішньої мережі. Запис DNS і файл мають описувати одну й ту саму поточну конфігурацію: новий ідентифікатор, що вказує на відсутній або застарілий файл, усе одно означає некоректне розгортання.

5. Перевірте виявлення політики, її вміст і відповідність MX-хостів

Перевірте кожен рівень окремо. Запитайте TXT-записи _smtp._tls і _mta-sts, відкрийте URL політики через HTTPS і звірте кожен рядок mx: із поточними MX-записами. Така триетапна перевірка виявляє помилки, які не можна знайти лише за допомогою DNS-запиту.

Переконайтеся, що HTTPS-з’єднання використовує довірений сертифікат для хоста MTA-STS, а файл містить очікувані поля. Потім перевірте підтримку TLS і дійсність сертифіката для точного імені кожного MX-хоста. Якщо провайдер використовує кілька MX-хостів для вхідної пошти, перевірте кожен із них окремо, а не припускайте, що конфігурація їхніх сертифікатів однакова.

Зафіксуйте результати: значення DNS, ідентифікатор політики, імена MX-хостів і дату перевірки. Це стане корисною відправною точкою для наступного адміністратора, якщо у звітах згодом з’явиться інформація про збої. Щоб стежити за новими матеріалами про налаштування пошти, додайте RSS-стрічку блогу YourTrend до списку ресурсів команди.

6. Перегляньте звіти, перш ніж застосовувати політику

Залиште політику в режимі тестування, поки збираєте звіти TLS-RPT і перевіряєте звичайну роботу пошти. У звітах можуть бути вказані поштові системи-відправники, у яких виникли проблеми із сертифікатом або узгодженням TLS, а також невідповідність між оголошеними MX-хостами та політикою. Звіт — це привід для перевірки, а не автоматична вказівка змінити запис DNS.

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

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

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

7. Увімкніть примусове застосування, відстежуйте роботу й підтримуйте налаштування

Коли список MX-хостів, сертифікати, політика HTTPS і результати тестування готові, змініть режим політики з testing на enforce. Опублікуйте оновлений файл політики та новий ідентифікатор _mta-sts. Після оновлення перевірте обидва елементи з-поза вашої мережі, а потім продовжуйте переглядати звіти TLS-RPT і журнали доставки пошти.

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

Задокументуйте порядок обслуговування разом із URL політики та записами DNS. Якщо змінюється MX-хост, оновіть політику, перш ніж покладатися на новий хост. Після оновлення сертифіката перевірте, що він охоплює потрібне ім’я хоста й має довірений ланцюжок сертифікації. Якщо під час примусового застосування виникне проблема, повернення до режиму тестування може зменшити вплив політики. Однак не забудьте оновити ідентифікатор політики та перевірити, що новий файл доступний належним чином.

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