Список розсилки необоротно ламає і DKIM, і SPF — і жодне налаштування у відправника це не лікує. Розбираємо, як ARC (RFC 8617) засвідчує авторизацію на вході в посередника, і піднімаємо підписання на rspamd та OpenARC.
Користувач [email protected] пише в розсилку [email protected]. У домені origin.com стоїть p=reject, DKIM налаштований бездоганно, SPF зелений. Лист відправляється, проходить через список — і падає в Gmail з таким вироком:
Authentication-Results: mx.google.com;
dkim=fail reason="body hash did not verify" header.d=origin.com;
spf=pass [email protected];
dmarc=fail (p=REJECT) header.from=origin.comdmarc=fail при p=reject означає спам-теку в кращому випадку і
550 5.7.1origin.comТут три незалежні поломки, і важливо не зливати їх в одну.
DKIM. Mailman чи rspamd на боці списку дописує в тіло футер To unsubscribe… і майже завжди переписує тему в [list] оригінальна тема. DKIM-підпис покриває тіло через bh= (body hash) і заголовок Subject через h=. Змінилося тіло — не збігається bh. Змінився Subject — не збігається хеш заголовків. Результат: dkim=fail reason="body hash did not verify". Це не помилка конфігурації, це математика: підписаний був інший лист.
SPF. Список пересилає повідомлення зі своїх власних MX і переписує envelope MAIL FROM на [email protected] (класичний VERP для обробки bounce'ів). SPF тепер перевіряє домен lists.example, і той чесно pass — але це SPF чужого домену. Alignment із доменом у полі From: (origin.com) зникає.
DMARC. Політика DMARC вимагає, щоб пройшов хоча б один механізм — SPF або DKIM — і щоб він був у alignment із доменом у видимому From:. Після проходження через список DKIM у fail, а SPF хоч і pass, але aligned на lists.example, а не на origin.com. Обидва шляхи до dmarc=pass перекриті одночасно.
Підсумок жорсткий: p=reject, який ви поставили, щоб захистити свій бренд від фішингу, вбиває вашого ж легітимного користувача, щойно той напише в будь-яку розсилку. Це не баг DMARC — це його дизайн. І саме тому знадобився окремий механізм для проміжних вузлів.
ARC (Authenticated Received Chain, RFC 8617, статус Experimental з 2019 року) додає на кожному проміжному вузлі рівно три поля, згруповані номером інстансу i=N (від 1 до 50):
Authentication-Results, зафіксована в момент прийому.cv= (chain validation): none, pass або fail.Логіка тут така. AMS дозволяє тілу мінятися на наступних хопах, бо кожен вузол підписує свою власну версію листа — не претендуючи на незмінність оригіналу. А AS зшиває ланцюг так, що ланки не можна ні вирізати, ні переставити місцями: кожна печатка криптографічно охоплює все, що лежить під нею.
Ось як виглядає повний набір для першого хопу (i=1). Оскільки до списку ланцюга ще не існувало, печатка несе cv=none — «я перша ланка»:
ARC-Seal: i=1; a=rsa-sha256; d=lists.example; s=arc2026;
t=1751630400; cv=none; b=Base64Seal...
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example; s=arc2026;
t=1751630400; c=relaxed/relaxed;
h=from:to:subject:date:message-id;
bh=Base64BodyHash...; b=Base64Sig...
ARC-Authentication-Results: i=1; lists.example;
spf=pass [email protected];
dkim=pass header.d=origin.com; dmarc=passЗверніть увагу на AAR: він фіксує dkim=pass header.d=origin.com та dmarc=pass — стан до того, як список додав футер. Це і є свідчення, яке ми несемо далі. Ключові теги решти полів:
d= — домен-запечатувач (sealer). На ньому тримається вся довіра.s= — селектор, за яким шукається публічний ключ у DNS.a= — алгоритм: rsa-sha256 (ключ рекомендовано 2048-bit) або ed25519-sha256 у новіших реалізаціях.c=relaxed/relaxed — канонікалізація заголовків/тіла. Практично завжди relaxed/relaxed.bh=, h=, t= — body hash, список підписаних заголовків, timestamp.Семантика cv= проста, але критична: none = я перша ланка ланцюга; pass = усі попередні ланки валідні; fail = ланцюг уже зламаний, і жодної віри йому далі нема. На другому хопі (наприклад, ще один релей) буде i=2; cv=pass.
Алгоритм на приймальному боці:
i=N) як звичайний DKIM-підпис — сходиться bh, валідний b.i=1 до i=N за їхніми публічними ключами.cv=fail — увесь ланцюг вважається fail.А тепер найважливіше й найчастіше нерозуміле. Навіть при arc=pass одержувач не зобов'язаний пропустити лист. ARC дає лише підставу зробити local policy override DMARC — і тільки якщо одержувач довіряє домену запечатувача (d= в ARC-Seal). Gmail і Microsoft вирішують за репутацією sealer-домену, накопиченою роками. Ваш власний Postfix жодної такої репутації не має і мусить явно вирішити, кому вірити. У фіналі успішний лист виглядає так:
Authentication-Results: mx.google.com; ...
arc=pass (i=1 spf=pass spf.domain=origin.com
dkim=pass dkim.d=origin.com dmarc=pass)Читається це як: «Я, Gmail, довіряю lists.example; він засвідчив, що на його вході SPF/DKIM/DMARC для origin.com були pass; тому я не застосовую p=reject».
Якщо ви і є той посередник, що пересилає й модифікує листи (список розсилки, форвардер, шлюз) — ось практична частина. ARC-ключ живе в тому самому DNS-namespace _domainkey, що й DKIM; окремого простору імен для ARC не існує. Генеруємо ключ:
rspamadm dkim_keygen -s arc2026 -d lists.example \
-k /var/lib/rspamd/dkim/lists.example.arc.key -b 2048Публікуємо публічну частину як TXT (утиліта виводить готовий рядок):
arc2026._domainkey.lists.example. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."Конфіг /etc/rspamd/local.d/arc.conf:
sign_local = true;
sign_authenticated = true;
selector = "arc2026";
path = "/var/lib/rspamd/dkim/$domain.arc.key";
use_domain = "envelope";
allow_hdrfrom_mismatch = true;Два параметри тут неочевидні й вирішальні. use_domain = "envelope" змушує rspamd брати домен зі зміненого MAIL FROM ([email protected]), тому $domain розкриється в lists.example і підтягне саме наш ключ — а не в origin.com із поля From:, до якого ключа в нас нема. А allow_hdrfrom_mismatch = true дозволяє підписати лист попри те, що From: ([email protected]) не збігається з доменом підпису — у розсилці вони й повинні різнитися. Головне правило: ARC підписуємо на виході релея, після того як усі модифікації тіла вже застосовані (футер, тег у Subject). Verify натомість робимо на вході. Якщо підписати AMS до додавання футера, наступний хоп отримає cv=fail.
Для чистого Postfix без rspamd є OpenARC. Конфіг /etc/openarc/openarc.conf:
Mode Sv
Domain lists.example
Selector arc2026
KeyFile /etc/openarc/keys/arc2026.private
Canonicalization relaxed/relaxed
Socket inet:8894@localhostMode Sv — і Sign, і Verify. Підключення в main.cf Postfix, з критично важливим порядком мілтерів:
smtpd_milters = inet:localhost:8891, inet:localhost:8894
non_smtpd_milters = inet:localhost:8891, inet:localhost:8894Спершу :8891 (OpenDKIM підписує від імені origin.com, якщо ви ще й origin), потім :8894 (OpenARC запечатує вже готовий лист). Якщо переставити місцями, ARC запечатає версію без DKIM-підпису — і ланцюг стане безглуздим. Врахуйте: OpenARC досі має ярлик experimental і вимагає уваги до того, щоб жоден мілтер не чіпав лист після того, як OpenARC поставив AMS.
Найпоширеніші причини cv=fail на наступному хопі:
t= перевіряється, тримайте NTP синхронним.simple замість relaxed канонікалізації на вузлі, що додає чи переносить пробіли у футері.Діагностика починається з raw-джерела листа. Витягніть усі ARC-поля й звірте d=/s=/i= кожного інстансу:
grep -iE '^ARC-(Seal|Message-Signature|Authentication-Results):' message.eml
dig +short TXT arc2026._domainkey.lists.exampleЯкщо dig не повертає ключ — публічний запис не з'явився або має помилку, і будь-яка валідація впаде ще до перевірки підпису.
cv=fail на наступному хопі.relaxed/relaxed канонікалізація на всіх вузлах.t= ламає валідацію.selector._domainkey TXT і перевірте dig'ом до вмикання sign_local.arc=pass.ARC доречний рівно там, де ви — оператор релея чи списку розсилки, який фізично переписує чужі листи. Там він рятує DMARC-alignment, на який відправник вплинути не може. Якщо ж ви керуєте лише власним доменом і нічого не пересилаєте — вам ARC підписувати нічого; достатньо, щоб ваш вхідний MX умів його перевіряти й довіряв правильним sealer-доменам.