Ваша. Розумна. Пошта.
Швидкий, кросплатформний поштовий клієнт, створений фільтрувати зайвий шум, щоб ви могли зосередитися на тому, що справді важливо.
Визначення
💡 ARC (Authenticated Received Chain): протокол автентифікації електронної пошти, який, по суті, відстежує, що відбувається з вашим повідомленням, коли воно проходить через різні сервери. Коли електронні листи пересилаються або змінюються списками розсилки, ARC зберігає початкові результати автентифікації, щоб легітимні повідомлення не позначалися як спам.
Чому ARC важливий
Ось яку проблему він розв’язує: ви надсилаєте електронний лист, який проходить усі перевірки автентифікації (SPF, DKIM, DMARC). Ідеально. Але потім хтось пересилає його через поштовий сервер своєї компанії, або він проходить через список розсилки, який додає нижній колонтитул. Ці зміни можуть порушити початкові підписи автентифікації.
Що відбувається далі? Сервер-отримувач бачить повідомлення, яке нібито надіслане від вас, але більше не проходить автентифікацію. Папка спаму. Або, що ще гірше, його повністю відхиляють.
ARC виправляє це, створюючи ланцюжок довіри. Кожен сервер, який обробляє повідомлення, додає власний підпис ARC, документуючи, що так, цей електронний лист був легітимним, коли надійшов сюди, навіть якщо ми трохи змінили його перед подальшою передачею. Уявіть це як естафету, де кожен бігун підтверджує підписом, що він законно отримав естафетну паличку.
Згідно з рекомендаціями Google для відправників електронної пошти, переслані електронні листи без ARC значно частіше не проходять перевірки автентифікації. Це дуже багато легітимної пошти, яку блокують.
Як працює ARC?
Протокол додає до вашого електронного листа три ключові заголовки, коли він проходить через сервери:
ARC-Authentication-Results фіксує, які перевірки автентифікації були виконані та чи були вони успішними. Це як табель успішності, який документує, що ваш електронний лист мав чинні DKIM і SPF, коли вперше надійшов на цей сервер.
ARC-Message-Signature створює криптографічний підпис вмісту повідомлення на цьому етапі його шляху. Це доводить, що повідомлення не було зловмисно підроблене між етапами передачі (незначні зміни для пересилання — це нормально й очікувано).
ARC-Seal поєднує все разом ще одним підписом, який підтверджує весь ланцюжок. Кожен сервер додає власну печатку, створюючи пов’язану послідовність. Якщо будь-яка ланка в ланцюжку пошкоджена або виглядає підозріло, сервери-отримувачі можуть це помітити.
Що зручно, ланцюжок нумерується. ARC-Seal: i=1, потім i=2, потім i=3. Сервери-отримувачі можуть перевірити, що нічого не бракує і що кожен легітимний проміжний сервер належним чином автентифікував попередній етап.
І на відміну від старіших протоколів, які ламаються, коли змінюється вміст, ARC очікує змін. У цьому весь сенс. Він лише документує, що ці зміни відбулися на довірених серверах, а не через якогось зловмисника, який перехопив вашу пошту.
Налаштування ARC
ARC потребує налаштування як на проміжних серверах (тих, що пересилають або змінюють повідомлення), так і на серверах-отримувачах (тих, що перевіряють ланцюжок ARC). Більшості користувачів не потрібно нічого робити, якщо тільки вони не підтримують власну поштову інфраструктуру.
У Gmail:
Gmail перевіряє підписи ARC під час отримання пересланих повідомлень. Якщо ви пересилаєте пошту до Gmail, проміжний сервер має додавати заголовки ARC. Якщо ви використовуєте Google Workspace і пересилаєте пошту через свої сервери до інших пунктів призначення, налаштуйте свої поштові сервери на додавання заголовків ARC. Google надає детальні рекомендації у своїх настановах для відправників електронної пошти для адміністраторів, які керують сервісами пересилання.
В Outlook:
Exchange Online підтримує перевірку ARC, але адміністраторам потрібно налаштувати довірені ARC sealers. Перейдіть до порталу Microsoft Defender і відкрийте Email & Collaboration > Policies & Rules > Threat policies > Email Authentication Settings > ARC. Додайте домени всіх проміжних сервісів, які обробляють вашу пошту (вони мають збігатися з тегом 'd' у заголовку ARC-Seal). Хороша новина: організації Microsoft 365 автоматично довіряють підписам ARC від інших організацій Microsoft 365, тож із цим уже все гаразд.
У Spark:
Spark покладається на налаштування автентифікації електронної пошти, задані вашим постачальником поштових послуг (Gmail, Outlook, власний сервер IMAP або облікові записи EWS, як-от Microsoft 365). Як поштовий клієнт, Spark не виконує підписування чи перевірку ARC безпосередньо. Це відбувається на рівні сервера ще до того, як повідомлення потрапляють до вашої вхідної пошти.
Для власних поштових серверів:
Якщо ви керуєте власною інфраструктурою, вам потрібно буде додати підтримку ARC до свого SMTP-сервера. OpenARC — найпоширеніша реалізація для Postfix і Sendmail. Вам потрібно буде встановити його, налаштувати для підписування вихідної пошти та перевірки вхідних ланцюжків, а також додати необхідну конфігурацію (подібно до налаштування DKIM, але для ARC не потрібні записи DNS).
У чому складність? ARC допомагає лише тоді, коли його підтримують і проміжні сервери, і кінцевий сервер-отримувач. Якщо пункт призначення не перевіряє ARC, ланцюжок не має значення. Але впровадження швидко зростає. Gmail, Yahoo, Microsoft і більшість великих постачальників тепер перевіряють ланцюжки ARC.
Рекомендації щодо ARC
Спочатку налаштуйте основні протоколи. ARC доповнює SPF, DKIM і DMARC, а не замінює їх. Налаштуйте ці методи автентифікації, перш ніж перейматися ARC. Без належної базової автентифікації ARC не матиме нічого корисного для збереження.
Відстежуйте результати автентифікації. Більшість постачальників послуг електронної пошти пропонують звіти, які показують, як часто ваші повідомлення проходять перевірки автентифікації. Якщо ви бачите високий рівень збоїв для пересланих листів навіть із ARC, значить щось налаштовано неправильно. Перевірте заголовки.
Тримайте свої ключі DKIM у безпеці. ARC базується на підписах DKIM, тому якщо ваші ключі DKIM скомпрометовані, ланцюжку ARC також не можна довіряти. Періодично змінюйте ключі (стандартно — кожні шість–12 місяців).
Тестуйте сценарії пересилання. Надсилайте тестові листи через списки розсилки, сервіси пересилання та різні поштові клієнти, щоб переконатися, що ARC працює правильно. Такі інструменти, як MXToolbox, можуть допомогти перевірити ваше налаштування та заголовки.
Документуйте свої довірені sealers. Якщо ви налаштовуєте перевірку ARC, ведіть список проміжних сервісів, яким ви довіряєте. Переглядайте цей список щокварталу. Сервіси змінюють власника, зазнають компрометації або припиняють роботу. Не довіряйте підписам ARC від сервісів, якими ви більше не користуєтеся.
Прийміть той факт, що це підтримують ще не всі. Деякі менші постачальники електронної пошти ще не впровадили перевірку ARC. Ваші переслані листи все ще можуть позначатися в них як підозрілі. Але всі великі гравці це підтримують, а це охоплює переважну більшість ваших одержувачів.
Пов’язані терміни