ARC для електронної пошти: коротко й корисно — коли це допомагає при пересиланні

ARC в одному абзаці (що робить і чого не робить)

ARC — це спосіб для проміжного обробника пошти (форвардера, розсилки, шлюзу) зафіксувати результати автентифікації, які він побачив при отриманні повідомлення, а потім криптографічно запечатати цей запис, щоб нижчі отримувачі могли вирішити, чи довіряти йому. На практиці: це допомагає приймачу дозволити пошту, яка провалила SPF або DKIM після пересилання, дозволяючи побачити перевірний запис «на форвардері це повідомлення пройшло».

ARC не замінює SPF, DKIM або DMARC. Це ланцюжок доказів. Він не робить підроблене повідомлення автентичним; він лише дає надійну слідову інформацію, коли автентифікація була зруйнована нормальним поведінковим маршрутом (наприклад, форвардер змінює envelope sender або розсилки змінюють тіло).

Чому пересилання ламає SPF/DKIM/DMARC (і чому це нормально)

SPF провалюється, бо підключається форвардер

SPF перевіряє, чи IP-адреса, що підключається, має право відправляти пошту від домену envelope-from (MAIL FROM / Return-Path). Коли провайдер Aліси надсилає форвардеру, SPF може пройти. Коли форвардер потім надсилає вашому поштовому провайдеру, SPF тепер оцінює IP форвардера для домену Aліси. Якщо домен Aліси явно не авторизує того форвардера (що малоймовірно), SPF провалюється.

Це не помилка. SPF робить саме те, для чого був задуманий: пов’язує IP підключення з ідентичністю. Пересилання змінює IP. Кінець гри.

DKIM провалюється, коли проміжні ланки змінюють підписаний вміст

DKIM підписує вибрані заголовки і (часто) тіло. Форвардер, який не чіпає повідомлення, може зберегти DKIM. Розсилка, що додає футер, переформатовує рядки, змінює теги Subject або нормалізує MIME-границі, може анулювати підпис. Деякі системи також перекодують вміст (quoted-printable vs base64) або переставляють заголовки так, що це ламає крихкі варіанти підписування.

DMARC провалюється, бо залежить від SPF/DKIM і вирівнювання

DMARC каже: або SPF, або DKIM має прошти, і та сторона, що пройшла, має вирівнюватися з видимим доменом From: (строге або релаксове вирівнювання залежно від політики). Коли пересилання спричиняє провал SPF, а розсилки — провал DKIM, DMARC провалюється. Якщо відправник встановив політику «reject», отримувачі можуть просто відкинути лист.

Жарт №1: Автентифікація пошти — як система пропусків у музеї: цілком логічно, поки хтось не притримає двері, і раптом ви «неуповноважені» у сувенірному магазині.

Отже, що змінює ARC?

ARC не воскресить SPF на останньому хопі. Він не змусить DKIM пройти після редагування розсилки. Він дає отримувачу запечатану заяву від проміжної ланки: «Коли я отримав, це пройшло SPF/DKIM/DMARC (або ні). Я також бачив ці ідентифікатори». Отримувачі можуть обирати приймати на основі цього ланцюга, коли це розумно і проміжна ланка викликає довіру.

Частини ARC: AAR, AMS, AS (і що дає кожна)

AAR: Authentication-Results (те, що побачив проміжний вузол)

ARC містить заголовок ARC-Authentication-Results (AAR). Він схожий на звичайний заголовок Authentication-Results, який ви бачите у отримувачів, але його вставляє проміжний вузол ARC. Він містить оцінку SPF/DKIM/DMARC на момент обробки повідомлення проміжною ланкою.

Чому це важливо: це дані «що форвардер бачив?». Без печатки це було б просто підробити. Інші частини ARC це виправляють.

AMS: Message Signature (зв’язує повідомлення з цим ARC-набором)

ARC додає заголовок ARC-Message-Signature (AMS). Він підписує вміст повідомлення (заголовки і опційно тіло), як це було на цьому хопі. Це допомагає нижчим отримувачам знати, що AAR відповідає конкретному стану повідомлення, а не якомусь скопійованому твердженню.

AMS — це не «підпис DKIM». Це підпис проміжної ланки над тим, як вона обробила повідомлення, з ARC-специфічною семантикою.

AS: Seal (захищає ланцюжок)

Заголовок ARC-Seal (AS) печатує набір, включно з посиланнями на попередні ARC-набори, формуючи ланцюжок. Кожен хоп, що бере участь, інкрементує лічильник інстанцій i=. Повний ланцюг — це послідовність ARC-наборів: i=1, i=2, i=3… кожен з AAR/AMS/AS.

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

Довіра — це політика, а не математика

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

Одна цитата, яка пасує на стіну поруч із кожним вхідним поштовим пайплайном: «Сподівання — це не стратегія.» — перефразована ідея, часто приписувана Gordon Sullivan (лидерська максима, широко застосовується в експлуатації).

Коли ARC допомагає при пересиланні (а коли це косметика)

ARC допомагає, коли довірена проміжна ланка ламає автентифікацію далі

ARC проявляє свої переваги, коли повідомлення було легітимним при вході в організацію, але пересилання або обробка зламали SPF/DKIM до моменту, коли воно дісталося фінального отримувача. Типові випадки:

• Просте пересилання (користувач пересилає на інший поштовий провайдер).
• Шлюзи безпеки, що сканують і інколи перезаписують повідомлення (URL-оборона, пісочниця вкладень).
• Розсилки, які додають футери або змінюють Subject-теги, ламаючи DKIM.
• Системи квитків, що реінжектять пошту в рамках робочого процесу.
• Багатокористувацькі вхідні реле, де «перший отримувач» — пристрій, а не постачальник поштових скриньок.

ARC не допомагає, коли оригінал ніколи не аутентифікувався

Якщо повідомлення провалює SPF/DKIM/DMARC при першій компетентній оцінці, ARC просто зберігає погану новину. Це корисно для судової експертизи, але не рятує доставляння.

ARC може нашкодити, якщо ви трактуєте його як універсальний обхід

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

ARC доповнює, але не замінює, SRS і правильну практику списків

SRS (Sender Rewriting Scheme) може виправити SPF для форвардерів, переписуючи envelope-from так, щоб SPF вирівнювався з доменом форвардера. Це добре, але не повсюдно впроваджено. Розсилки можуть зберегти DKIM, уникаючи змін тіла або застосовуючи DMARC-дружнє переписування From при необхідності. Це ще й політичні та продуктові рішення. ARC — прагматичний міст, коли ви не можете змусити світ припинити пересилання.

Цікаві факти & історія (коротко, конкретно)

1. ARC з’явився тому, що DMARC спрацював — коли великі відправники почали публікувати «p=reject», форвардери й розсилки відчули удар.
2. Розсилки були ранніми жертвами суворого DMARC: футери та subject-теги рутинно ламають DKIM, а SPF не переживає пересилання.
3. ARC стандартизований як RFC 8617 (2019), що для поштової інфраструктури відносно недавно.
4. Лічильник інстанцій (i=) в ARC-заголовках не є опціональним; саме так отримувачі знають порядок ланцюга.
5. ARC використовує криптографію в стилі DKIM (публічні ключі в DNS, підписи над канонізованими заголовками), що полегшує впровадження в існуючих поштових стеках.
6. ARC не стверджує, що відправник добрий; він стверджує, що проміжна ланка зафіксувала результати автентифікації в конкретний час і запечатала їх.
7. Отримувачі можуть прийняти повідомлення з проваленим DMARC, якщо ARC-ланцюг валідний і проміжна ланка викликає довіру — це політичний вибір, а не протокольна вимога.
8. ARC — один із небагатьох стандартів, що визнає «непорядок» поштових проміжних вузлів, замість того щоб робити вигляд, ніби їх не існує.

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

Найшвидший спосіб налагодити проблеми з ARC — припинити думати в термінах «ARC добре/погано» і натомість відповісти на три питання: (1) Чи аутентифікувалося повідомлення десь? (2) Чи щось зламало це пізніше? (3) Чи ланцюг перевіряється і чи походить він від проміжної ланки, якій ви довіряєте?

По-перше: визначте рішення фінального отримувача

• Знайдіть фінальний хоп і його заголовок Authentication-Results.
• Зафіксуйте результати SPF/DKIM/DMARC і будь-яку оцінку ARC (деякі отримувачі додають arc=pass/fail).
• Рішення: якщо отримувач уже каже DMARC пройшов, ARC, ймовірно, не має значення для доставляння; він може бути корисний для аудиту.

По-друге: огляньте структуру ARC-ланцюга

• Порахуйте ARC-набори за i=.
• Переконайтеся, що для кожної інстанції є AAR + AMS + AS.
• Рішення: відсутні або розкидані інстанції зазвичай означають зламану реалізацію або повідомлення змінювали посеред ланцюга.

По-третє: перевірте криптографію й DNS-ключі

• Підтвердьте, що печатка ARC та AMS валідуються проти DNS-ключів домену(ів) підписувача.
• Рішення: якщо валідація не вдається, на ARC не можна покладатися. Виправте підписувача, DNS або обробку повідомлення, що змінила заголовки.

По-четверте: визначте, де зламалась автентифікація

• Порівняйте DKIM-підписи: яка з них провалилася, який домен підписав і чи тіло було змінено.
• Перевірте SPF: який хоп спричинив невідповідність IP підключення.
• Рішення: якщо проміжна ланка є винуватцем, вирішіть, чи зберігати DKIM, використати SRS або покладатися на ARC плюс довіру отримувача.

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

Команди нижче припускають, що у вас є доступ до поштового шлюзу або хоста для налагодження, який може читати збережені повідомлення (наприклад, з карантину, сирцевого архіву системи квитків або копії MTA spool). Приклади використовують загальні Linux-утиліти плюс OpenDKIM там, де це доречно. Підлаштуйте шляхи й назви сервісів під ваше середовище.

Завдання 1: Витягніть сире повідомлення й ізолюйте ARC-заголовки

cr0x@server:~$ sed -n '1,/^$/p' message.eml | egrep '^(ARC-|Authentication-Results:|Received:|From:|Return-Path:|DKIM-Signature:|Message-ID:)'
Return-Path: <billing@example.com>
Received: from mx.sender.example (203.0.113.10) by forwarder.corp.example ...
ARC-Authentication-Results: i=1; forwarder.corp.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=corp.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=corp.example; s=arc1; cv=none; ...
Authentication-Results: mx.receiver.example; dkim=fail header.d=example.com; spf=fail smtp.mailfrom=billing@example.com; dmarc=fail header.from=example.com
From: "Billing" <billing@example.com>
Message-ID: <...>

Що це означає: У вас є ARC-набір i=1, створений corp.example, що стверджує, ніби повідомлення пройшло на форвардері. Отримувач бачить помилки зараз.

Рішення: Перейдіть до валідації ARC; якщо ланцюг валідується і ви довіряєте corp.example, можете розглядати повідомлення як наслідок пересилання.

Завдання 2: Порахуйте інстанції ARC і перевірте повноту

cr0x@server:~$ grep -E '^ARC-(Authentication-Results|Message-Signature|Seal):' -n message.eml | sed -E 's/.* i=([0-9]+).*/i=\1/' | sort | uniq -c
      3 i=1

Що це означає: Три ARC-заголовки для i=1 означають повний ARC-набір (AAR+AMS+AS) для цієї інстанції.

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

Завдання 3: Перевірте печатку ARC та AMS за допомогою OpenDKIM (якщо доступно)

cr0x@server:~$ opendkim-testmsg -A -d corp.example -s arc1 < message.eml
opendkim-testmsg: ARC-Seal pass (i=1)
opendkim-testmsg: ARC-Message-Signature pass (i=1)

Що це означає: Повідомлення відповідає тому, що підписувач ARC запечатав, і DNS-ключі для arc1 під corp.example валідуються.

Рішення: Якщо це падає, ARC не можна використовувати для обґрунтування прийняття пошти. Виправте DNS-ключі, канонізацію, перезапис заголовків або конфігурацію ARC-підписувача.

Завдання 4: Отримайте публічний ключ ARC з DNS і перевірте його

cr0x@server:~$ dig +short TXT arc1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."

Що це означає: ARC використовує публікацію в DNS в стилі DKIM. Якщо запис відсутній, неправильний або обрізаний, валідація не вдасться.

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

Завдання 5: Перевірте DMARC-політику оригінального домену

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=r"

Що це означає: Строге вирівнювання DKIM (adkim=s) плюс reject означає, що невеликі відхилення автентифікації суворо караються.

Рішення: Якщо ви керуєте форвардером для своїх користувачів, плануйте впровадження ARC і/або SRS; інакше ви й далі втрачати повідомлення.

Завдання 6: Огляньте SPF-політику і зрозумійте, чому пересилання провалюється

cr0x@server:~$ dig +short TXT example.com | head -n 2
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

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

Рішення: Не «виправляйте» це, додаючи IP вашого форвардера в SPF чужого домену (ви не можете). Використовуйте SRS або ARC, або зберігайте DKIM.

Завдання 7: Перевірте, чи DKIM зламався через зміну повідомлення (невідповідність гешу тіла)

cr0x@server:~$ opendkim-testmsg -v < message.eml | sed -n '1,20p'
opendkim-testmsg: dkim=fail (body hash did not verify)
opendkim-testmsg: key retrieved from DNS

Що це означає: Ключ підпису існує, але тіло змінене після підписування.

Рішення: Визначте модифікатор (футер списку, шлюз, що переписує URL, фільтр контенту). Або припиніть модифікувати, підпишіть заново (власним DKIM/ARC), або покладіться на ARC там, де отримувачі довіряють вам.

Завдання 8: Підтвердьте, чи ваш шлюз переписує вміст (поширений винуватець)

cr0x@server:~$ grep -iE 'X-(IronPort|Proofpoint|Mimecast|Barracuda|Symantec|MS-Exchange|Spam|Virus|Scanned)' -n message.eml | head
142:X-Proofpoint-Virus-Version: vendor=baseguard engine=...
143:X-Proofpoint-ORIG-GUID: ...

Що це означає: Залучено безпекове ПЗ, часто воно переписує URL або додає банери — обидва можуть ламати DKIM.

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

Завдання 9: Переконайтеся, що ваш MTA не видаляє ARC-заголовки

cr0x@server:~$ postconf -n | egrep '^(header_checks|smtp_header_checks|cleanup_service_name|receive_override_options)'
header_checks =
smtp_header_checks =
cleanup_service_name = cleanup
receive_override_options =

Що це означає: Явних перевірок заголовків не показано. Якщо у вас є фільтри заголовків, вони можуть видаляти ARC-* «з міркувань безпеки».

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

Завдання 10: Шукайте правила заголовків, що видаляють ARC

cr0x@server:~$ sudo egrep -Rin 'ARC-|Authentication-Results|REMOVE|IGNORE' /etc/postfix | head -n 20
/etc/postfix/header_checks:12:/^ARC-/ IGNORE

Що це означає: Хтось вирішив, що ARC-заголовки «недовірені» і налаштував Postfix на їх видалення.

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

Завдання 11: Перевірте підключення мілітера OpenDKIM/OpenARC (класична виробнича помилка)

cr0x@server:~$ sudo journalctl -u postfix -u opendkim -u openarc --since "1 hour ago" | egrep -i 'milter|openarc|opendkim|connect|timeout|error' | tail -n 20
postfix/cleanup[22102]: warning: connect to Milter service unix:/run/openarc/milter.sock: No such file or directory
postfix/cleanup[22102]: warning: milter unix:/run/openarc/milter.sock: can't read

Що це означає: Postfix не може поговорити з сервісом підписування/валідації ARC. Ваша пошта проходитиме без обробки ARC або, що гірше, з частковими заголовками.

Рішення: Відновіть сервіс мілтера й перезапустіть. Потім протестуйте на відомому сценарії пересилання та підтвердіть появу ARC-наборів.

Завдання 12: Підтвердіть, що підписувач ARC дійсно увімкнений і підписує вихідну/переслану пошту

cr0x@server:~$ sudo grep -RinE 'OpenARC|milter_default_action|milter_protocol' /etc/postfix/main.cf
/etc/postfix/main.cf:27:smtpd_milters=unix:/run/opendkim/milter.sock, unix:/run/openarc/milter.sock
/etc/postfix/main.cf:28:non_smtpd_milters=unix:/run/opendkim/milter.sock, unix:/run/openarc/milter.sock
/etc/postfix/main.cf:29:milter_default_action=accept
/etc/postfix/main.cf:30:milter_protocol=6

Що це означає: Мілтери підключені як для SMTP-прийому, так і для локально згенерованих потоків, і режим відмови — accept (пошта йде, навіть якщо мілтер впав).

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

Завдання 13: Перевірте конфігурацію OpenARC на предмет домену/селектора

cr0x@server:~$ sudo egrep -n '^(Domain|Selector|KeyFile|Socket|AuthservID)' /etc/openarc.conf
AuthservID mailgw1.corp.example
Domain corp.example
Selector arc1
KeyFile /etc/openarc/keys/corp.example/arc1.private
Socket local:/run/openarc/milter.sock

Що це означає: Ваш ARC-підписувач заявляє ідентичність corp.example з селектором arc1.

Рішення: Переконайтеся, що в DNS є відповідний публічний ключ. Також гарантуйте, що ідентичність підписувача — це межа, якою ви керуєте (домен шлюзу, а не випадковий піддомен, який ви забуваєте оновлювати).

Завдання 14: Переконайтесь, що переслана пошта йде через очікуваний хост (щоб ARC застосовувався)

cr0x@server:~$ grep -n '^Received:' -m 6 message.eml
12:Received: from mx.sender.example (203.0.113.10) by forwarder.corp.example ...
18:Received: from forwarder.corp.example (198.51.100.25) by mx.receiver.example ...

Що це означає: Форвардер є тим, хто повторно відправляє. Саме це сценарій пересилання, що ламає SPF і спричиняє проблеми з DMARC.

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

Завдання 15: Перевірте на наявність кількох заголовків Authentication-Results і інтерпретуйте їх

cr0x@server:~$ grep -n '^Authentication-Results:' message.eml
25:Authentication-Results: forwarder.corp.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com
61:Authentication-Results: mx.receiver.example; dkim=fail header.d=example.com; spf=fail smtp.mailfrom=billing@example.com; dmarc=fail header.from=example.com

Що це означає: Форвардер бачив успіх; фінальний отримувач бачив провал. Це канонічний випадок застосування ARC.

Рішення: Якщо ваш форвардер підтримує ARC, краще додати ARC, ніж вигадувати локальні білелісти. Білелісти в’януть; ARC дає трасовані докази.

Завдання 16: Доведіть, чи футер розсилки ламає DKIM

cr0x@server:~$ awk 'BEGIN{p=0} /^$/{p=1} {if(p) print}' message.eml | tail -n 20
--
You received this message because you are subscribed to Corp List.
To unsubscribe, visit: ...

Що це означає: Додано футер, що часто ламає геш тіла DKIM.

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

Три корпоративні міні-історії з практики

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

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

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

Заголовки пошти розказали справжню історію. Оригінальний відправник використовував DMARC зі стрикою політикою. Коли клієнт пересилав від Provider A до Provider B, SPF провалювався у Provider B (бо IP форвардера не авторизовано), а DKIM провалювався, бо форвардер нормалізував MIME-границі. DMARC пішов у провал, і Provider B виконував політику «reject».

Хибне припущення було не технічним, а організаційним: вони вірили, що доставляння — «задача з найкращими зусиллями». У результаті рахунки не доставлялись, сповіщення затримувались, а фінансові команди шукали обхідні шляхи в таблицях. Згодом вони запровадили ARC-підписування на межі пересилання й налаштували шлюз так, щоб зберігати DKIM де можливо. Тікети не зникли одразу, але відмови стали пояснювані й виправні. Це перемога в продакшні.

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

Команда безпеки підприємства впровадила систему URL-оборони, яка переписувала кожне посилання у вхідній пошті. Вони були горді. Графіки CPU були хороші, звіти про кліки блищали, і фішинг-симуляції покращилися.

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

Шлюз безпеки стояв перед провайдером пошти і переписував повідомлення перед доставкою. Це ламало DKIM для багатьох відправників. Сам по собі зламаний DKIM інколи можна пережити — SPF може пройти. Але пересилання й субмаршрути означали, що SPF теж не стабільний. DMARC-провали накопичилися. Партнери з «p=reject» відкидалися на стороні отримувача.

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

Виправлення було нудне й принизливе: припинити видаляти ARC, додати ARC-підписування після переписування і вирівняти архітектуру так, щоб останній модифікатор також підписував. Безпека залишила переписування. Бізнес отримав контракти. Операції мали менше нічних ескалацій і більше роботи вдень.

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

Велика B2B фірма мала пару вхідних шлюзів в active/active. Нічого фантастичного: Postfix, OpenDKIM, OpenARC, чітке розділення між «edge accept» і «internal delivery». Вони також мали політику: кожен зразок з карантину зберігається з повними заголовками 30 днів, а будь-яка зміна обробки заголовків потребує peer review від людини, яка вже обпікалась раніше.

Під час міграції вендора вони переключили правило пересилання, так що певні скриньки доставлялися через внутрішню систему квитків. Почали зникати зовнішні листи від одного банку. Політика DMARC у банку була суворою. Система квитків модифікувала тіло, додаючи банер справи. DKIM зламався. SPF провалився, бо система квитків повторно відправляла з оригінальним envelope-from. DMARC провалився і фінальний поштовий провайдер відкинув.

Оскільки вони зберігали сирі повідомлення, вони могли порівняти «до-ticketing» і «після-ticketing» версії. Діф був очевидний: додано банер. Оскільки у них була peer-reviewed обробка заголовків, ARC залишився недоторканим до шлюзу, і вони вже мали OpenARC готовий до підписування. Вони змінили лише одне: шлях виходу системи квитків пройшов через шлюз, який підписував ARC після модифікації.

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

Жарт №2: Єдина річ більш вічна за електронну пошту — це нарада про те, чому електронна пошта вічна.

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

1) «ARC присутній, але отримувачі ігнорують його»

Симптоми: ARC-заголовки є; доставляння все ще не відбувається; отримувач показує DMARC fail і немає згадки про arc=pass.

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

Виправлення: Криптографічно валідуйте ланцюг; переконайтеся, що DNS-ключі існують; забезпечте стабільність підписувача й репутацію; не видаляйте/не модифікуйте ARC-заголовки в польоті.

2) «Ми увімкнули ARC-підписування, але валідація ланцюга падає періодично»

Симптоми: Іноді ARC-Seal валідується, іноді ні; збої корелюють з певними розмірами повідомлень або типами контенту.

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

Виправлення: Підписуйте в останній точці модифікації. Якщо ви мусите змінювати після підпису, потрібно підписати знову (нова інстанція ARC) на новій межі.

3) «Переслана пошта провалює SPF і DMARC; ми думали, ARC це виправить»

Симптоми: SPF fail, DMARC fail у фінального отримувача; ARC-ланцюг відсутній або не довіряють.

Корінь: Немає ARC-підписування на форвардері або форвардер не бере участі; плюс SPF провал очікуваний без SRS.

Виправлення: Запровадьте SRS для виживання SPF і/або ARC-підписування на форвардері. Якщо ви не контролюєте форвардер, зберігайте DKIM і уникайте модифікацій; інакше прийміть, що не зможете змусити віддалених отримувачів прийняти.

4) «Пости розсилки зникають з деяких корпоративних доменів»

Симптоми: Пости від доменів з DMARC reject ніколи не доходять; інші доходять.

Корінь: Список змінює повідомлення, ламаючи DKIM; SPF провалюється при ремейлі списком; DMARC відкидає.

Виправлення: Або припиніть змінювати тіло (без футерів), або використайте переписування From для DMARC, або впровадьте ARC, щоб отримувачі бачили, що список обробив попередньо аутентифіковане повідомлення.

5) «Ми видаляли ARC-заголовки, бо вони ‘user supplied’»

Симптоми: ARC-ланцюги ніколи не валідуються далі; партнери скаржаться на доставляння пересилань.

Корінь: Політика санітизації заголовків видаляє ARC-* разом з іншими заголовками; це ламає цілісність ланцюга.

Виправлення: Не видаляйте ARC, якщо ви на ньому покладаєтесь. Натомість підписуйте нову ARC-інстанцію на вашій межі. Якщо мусите видаляти, робіть це перед створенням власного ARC-набору й приймайте, що докази від upstream відкинуті.

6) «Домен підписувача ARC не відповідає нашій організаційній межі»

Симптоми: ARC валідується, але отримувачі все одно не довіряють; або ваш власний фільтр не може створити правила довіри.

Корінь: ARC підписується випадковим піддоменом, доменом вендора або нестабільною хост-іменем, яке не несе постійної репутації.

Виправлення: Підписуйте доменом, яким ви керуєте і зберігатимете довгостроково (наприклад, corp.example). Переконайтесь, що селектор і ротація ключів управляються як будь-яка інша критична ідентичність.

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

Контрольний список A: Вирішіть, чи вам справді потрібен ARC

1. Ви керуєте пересиланням (алиаси користувачів, правила маршрутизації, реінжекція в систему квитків, listserv)? Якщо ні, ARC здебільшого спостережливий.
2. Чи ви регулярно модифікуєте повідомлення в дорозі (банери, переписування URL, штампи DLP)? Якщо так, ви в території ARC.
3. Чи ви бачите відмови через DMARC від великих відправників? Якщо так, ARC може бути найменш поганим важелем.
4. Чи можете ви замість цього зберегти DKIM, не модифікуючи вміст? Якщо так, зробіть це першочергово. ARC для випадків, коли не можна.
5. Чи можете ви впровадити SRS для форвардерів? Якщо так, зробіть це; це зменшить проблеми SPF і доповнює ARC.

Контрольний список B: Впровадження ARC на контрольованій межі (розумний шлях)

1. Виберіть хост(и) межі: останнє місце, де повідомлення модифікується перед виходом з вашого контролю.
2. Опублікуйте стабільні DNS-ключі: створіть селектор arc1 (або подібний), опублікуйте TXT-запис і перевірте отримання з кількох резолверів.
3. Увімкніть ARC-підписування: підключіть OpenARC (або обрану реалізацію) як milter на межовому MTA.
4. Не видаляйте upstream ARC, якщо лише у вас немає чіткої політики; якщо ж видаляєте, завжди створюйте власну ARC-інстанцію після цього.
5. Моніторте відмови валідації: ставте до ARC такі ж вимоги, як до DKIM — ротація ключів, DNS-збої й зміни канонізації є операційними ризиками.
6. Тестуйте реальні потоки: пересилання між провайдерами, пости розсилок, реінжекцію в систему квитків і сценарії «переписування безпеки вкл/викл».

Контрольний список C: Операційна готовність (SRE-принципи для пошти)

1. Логуйте й зберігайте сирі заголовки для зразків (карантин або журналювання) достатньо довго для налагодження багатоденних збоїв.
2. Додайте канарку: щоденне переслане повідомлення з DMARC «reject» домену у вашій лабораторії, щоб виявляти поломки рано.
3. Налаштуйте оповіщення про простої мілтера (OpenARC socket відсутній, timeouts або зростання помилок).
4. Задокументуйте правило «останній модифікатор підписує». Підтримуйте це в оглядах змін.
5. Тримайте runbook: які системи модифікують пошту, хто підписує DKIM, хто підписує ARC і де відбуваються зміни маршрутизації.

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

1) Чи робить ARC DMARC пройденим?

Ні. DMARC оцінюється на основі результатів SPF/DKIM і вирівнювання у отримувача. ARC дає отримувачу перевірні докази, що автентифікація пройшла раніше, і деякі отримувачі можуть прийняти попри DMARC fail.

2) Якщо я додам ARC, чи можу не турбуватись про SRS?

Не варто. SRS вирішує проблему виживання SPF при пересиланні; ARC допомагає пояснити й інколи пом’якшити наслідки. Вони вирішують різні аспекти проблеми пересилання. У багатьох середовищах поєднання обох дає найстабільніший результат.

3) Чи має кожен MTA підписувати ARC?

Ні. Підписуйте ARC на значущих межах: форвардерах, розсилках, шлюзах безпеки, точках реінжекції в систему квитків. Випадкові внутрішні реле, що підписують ARC, лише додають шум у ланцюжку й операційну складність.

4) Чи можуть атаkувальники підробити ARC-заголовки?

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

5) Що найчастіше ламає валідацію ARC?

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

6) Ми керуємо розсилкою. Який найкращий підхід?

Спочатку спробуйте не модифікувати тіло і зберегти DKIM. Якщо модифікація обов’язкова, впровадьте ARC-підписування, щоб отримувачі бачили, що список обробив попередньо аутентифіковане повідомлення. Також розгляньте DMARC-дружні практики для списків (наприклад, переписування From), але це політичне рішення з наслідками для спільноти.

7) Як дізнатись, чи отримувачі довіряють мій ARC?

Універсальної гарантії немає. Деякі отримувачі покажуть результати оцінки ARC у заголовках; інші — ні. Практичний метод — контрольоване тестування: надсилайте/пересилайте повідомлення через вашу систему до популярних поштових провайдерів і аналізуйте патерни прийняття.

8) Чи актуальний ARC, якщо ми вже маємо DKIM на вихідних листах?

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

9) У чому різниця між Authentication-Results і ARC-Authentication-Results?

Authentication-Results — це заява отримувача про те, що він оцінив. ARC-Authentication-Results — це заява проміжного вузла, запечатана ARC, щоб нижчі отримувачі могли перевірити, що її не підроблено.

10) Чи може ARC допомогти із внутрішнім захистом від фішингу?

Так, як телеметрія. ARC може повідомити, чи повідомлення, ймовірно, аутентифікувалося на межі перед тим, як його трансформували всередині. Але не трактуйте ARC як обхід для фішингу; розглядайте його як доказ, що впливає на оцінку ризику.

Висновок: наступні кроки, які можна зробити цього тижня

ARC — не панацея. Це ланцюжок відповідальності для результатів автентифікації. Звучить бюрократично, і саме тому це працює: електронна пошта — це бюрократія з SMTP-портами.

1. Виберіть один проблемний потік пересилання (квитки, список, пересилання користувача). Збережіть сире повідомлення з повними заголовками.
2. Визначте, що зламалось: SPF через пересилання? DKIM через модифікацію? DMARC через вирівнювання?
3. Знайдіть останнього модифікатора і зробіть цей хост підписувачем ARC. Не підписуйте раніше й сподівайтеся, що нічого не зміниться.
4. Припиніть видаляти ARC-заголовки, якщо ви не замінюєте їх власним ARC-набором на контрольованій межі.
5. Налаштуйте канарку й оповіщення для здоров’я мілтера та відмов валідації ARC, перш ніж бізнес дізнається першим.

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