ARC — autentizace e-mailů při přeposílání

Proč přeposílání e-mailů láme autentizaci

SPF ověřuje, zda odesílající server je oprávněný pro doménu v obálce e-mailu. DKIM ověřuje integritu zprávy pomocí digitálního podpisu. DMARC propojuje oba protokoly s adresou v hlavičce From. Tato trojice funguje spolehlivě — dokud e-mail putuje přímo od odesílatele k příjemci.

Problém nastává při přeposílání. Když e-mail projde přes mailing list, firemní přeposílání nebo aliasovou službu:

• SPF selže, protože e-mail doručuje server přeposílatele, který není v SPF záznamu původní domény (více o limitech SPF).
• DKIM selže, pokud přeposílatel zprávu modifikuje — přidá patičku, změní předmět nebo doplní hlavičky.
• DMARC selže, protože ani SPF, ani DKIM neprojde v souladu (alignment) s doménou v hlavičce From.

Výsledek: legitimní e-mail skončí ve spamu nebo je odmítnut, přestože odesílatel má autentizaci správně nastavenou.

Co je ARC

ARC (Authenticated Received Chain) je protokol definovaný v RFC 8617. Umožňuje zprostředkujícím serverům (přeposílatelům, mailing listům) zachovat a podepsat výsledky autentizace z předchozích kroků doručování.

ARC nenahrazuje SPF, DKIM ani DMARC. Doplňuje je o mechanismus, který přijímajícímu serveru říká: „Původní zpráva prošla autentizací. Tady jsou důkazy a můj podpis, že je nezměnil nikdo nedůvěryhodný."

Protokol má experimentální status (RFC 8617 je kategorie „Experimental"), ale v praxi ho podporují a používají všichni velcí poskytovatelé e-mailových služeb.

Jak ARC funguje

Každý zprostředkující server, kterým e-mail prochází, přidá do zprávy sadu tří hlaviček s pořadovým číslem (instance number). První zprostředkovatel přidá sadu i=1, druhý i=2 atd. Vzniká tak řetězec — chain — který dokumentuje celou cestu zprávy.

Tři ARC hlavičky

Průběh zpracování

1. Odesílatel pošle e-mail s platným SPF, DKIM a DMARC.
2. E-mail dorazí na zprostředkující server (mailing list, forwarder).
3. Zprostředkovatel ověří autentizaci příchozí zprávy.
4. Zapíše výsledky do ARC-Authentication-Results (i=1).
5. Provede úpravy zprávy (přidá patičku, změní předmět).
6. Podepíše upravenou zprávu vlastním klíčem — vytvoří ARC-Message-Signature (i=1).
7. Zapečetí celý ARC řetězec pomocí ARC-Seal (i=1) včetně tagu cv=none (první článek řetězce, nic k validaci) a odešle dál.
8. Cílový server obdrží zprávu se selhaným SPF/DKIM, ale s platným ARC řetězcem.
9. Pokud cílový server důvěřuje pečetiteli (ARC sealer), může e-mail přijmout na základě ARC.

Příklad ARC hlaviček

Zjednodušený příklad zprávy přeposlané přes mailing list:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=list.example.org;
    s=arc-selector; b=<podpis>
ARC-Message-Signature: i=1; a=rsa-sha256; d=list.example.org;
    s=arc-selector; h=from:to:subject:date; bh=<hash těla>;
    b=<podpis>
ARC-Authentication-Results: i=1; list.example.org;
    spf=pass smtp.mailfrom=firma.cz;
    dkim=pass header.d=firma.cz;
    dmarc=pass header.from=firma.cz

Tag cv= (chain validation) v ARC-Seal indikuje stav řetězce:

ARC a DMARC — jak spolu pracují

DMARC specifikace (RFC 9871, dříve RFC 7489) neobsahuje explicitní zmínku o ARC, ale definuje koncept „local policy override" — přijímající server může na základě vlastních pravidel upravit zacházení se zprávou, i když DMARC kontrola selže.

V praxi to funguje takto:

1. E-mail přijde se selhaným DMARC (kvůli přeposílání).
2. Přijímající server nalezne platný ARC řetězec.
3. Server ověří, zda pečetiteli (ARC sealer) důvěřuje.
4. Pokud ano, použije DMARC override a e-mail přijme, přestože DMARC samotný selhal.

Toto chování se v DMARC reportech projeví jako výsledek pass s příznakem override (typ local_policy nebo trusted_forwarder).

Kdo ARC podporuje

Na straně přeposílatele (ARC sealer)

Tyto služby přidávají ARC hlavičky při přeposílání:

• Google (Gmail, Google Workspace) — plná podpora, ARC hlavičky přidává automaticky
• Microsoft (Outlook.com, Exchange Online) — plná podpora
• Yahoo — podpora
• Mailman 3 — vestavěná podpora (konfigurace v sekci [ARC] souboru mailman.cfg)
• Sympa — podpora od verze 6.2.38

Na straně příjemce (ARC verifier)

Tyto služby vyhodnocují ARC řetězec při příjmu:

• Google — vyhodnocuje ARC a bere ho v úvahu při DMARC rozhodování
• Microsoft — podporuje konfiguraci důvěryhodných ARC pečetitelů v Microsoft 365
• Yahoo — vyhodnocuje ARC
• Fastmail — podpora

Microsoft 365 umožňuje administrátorům explicitně přidat důvěryhodné ARC pečetitele v nastavení e-mailové autentizace. Pokud provozujete vlastní přeposílací službu, která posílá e-maily do Microsoft 365, přidejte svou doménu do seznamu důvěryhodných ARC sealerů.

Jak ARC nasadit na vlastním serveru

ARC je primárně záležitost zprostředkujících serverů — přeposílatelů a mailing listů. Pokud provozujete:

Mailing list (Mailman, Sympa)

Aktualizujte software na verzi s podporou ARC. Vygenerujte klíčový pár a publikujte veřejný klíč jako DNS TXT záznam stejně jako u DKIM:

arc-selector._domainkey.list.firma.cz IN TXT "v=DKIM1; k=rsa; p=<veřejný klíč>"

ARC používá stejný formát DNS záznamů jako DKIM — sdílí infrastrukturu klíčů.

Přeposílací službu (Postfix, Exim)

Pro Postfix existuje integrace přes OpenARC — milter (mail filter), který přidává ARC hlavičky:

apt install openarc

Konfigurace v /etc/openarc.conf:

Mode                sv
Canonicalization    relaxed/relaxed
Domain              firma.cz
Selector            arc-selector
KeyFile             /etc/openarc/arc-selector.key
AuthservID          firma.cz

Režim sv (sign and verify) znamená, že server bude ARC hlavičky přidávat při přeposílání i ověřovat při příjmu.

Firemní přeposílání (aliasy)

Pokud vaše doména přeposílá e-maily pomocí aliasů (např. info@firma.cz → osobní schránka), přeposílající server by měl přidávat ARC hlavičky. U běžného přeposílání přes SRS (Sender Rewriting Scheme) ARC doplňuje SRS — SRS řeší SPF, ARC zachovává celý autentizační kontext.

Omezení ARC

Důvěra pečetiteli

ARC funguje na principu důvěry. Přijímající server musí rozhodnout, kterým ARC pečetitelům důvěřuje. Neexistuje centrální seznam důvěryhodných pečetitelů — každý přijímající server si spravuje vlastní. V praxi velcí poskytovatelé (Google, Microsoft) důvěřují navzájem svým ARC podpisům.

Experimentální status

RFC 8617 má status „Experimental", ne „Standards Track". To znamená, že specifikace se může v budoucnu měnit. V praxi je ale ARC široce nasazený a změna je nepravděpodobná.

ARC neřeší všechno

ARC pomáhá pouze u legitimního přeposílání. Pokud útočník kompromituje přeposílací server a přidá vlastní ARC hlavičky, příjemce může podvrženou zprávu přijmout, pokud kompromitovanému serveru důvěřuje. ARC nenahrazuje důkladné nastavení SPF, DKIM a DMARC.

ARC jako součást e-mailové autentizace

ARC řeší reálný problém — přeposílání e-mailů je běžná praxe a bez ARC způsobuje legitimním zprávám problémy s doručením. Pokud vaše domény přeposílají e-maily nebo provozujete mailing listy, ARC je relevantní protokol, který stojí za nasazení. Základy e-mailové autentizace shrnuje kompletní průvodce SPF, DKIM a DMARC.

Pro domény, které e-maily jen odesílají a přijímají (nepřeposílají), ARC nevyžaduje žádnou akci — funguje na straně zprostředkovatelů a příjemců.

Ověřte si, zda máte správně nastavené základní autentizační protokoly. Zkontrolujte zabezpečení vaší domény a zjistěte stav SPF, DKIM i DMARC.