Proč e-mail, který jste si poslali sami sobě, skončil v nevyžádané poště — redakční ilustrace

read receipts

Proč e-mail, který jste si poslali sami sobě, skončil v nevyžádané poště

Nic špatného jste neudělali. Viník je SPF. Tady je mechanika, kterou vám nikdo u vašeho poskytovatele nevysvětlí.

·3 min čtení

Nastavíte si automatické přesměrování ze starého účtu na nový, a část těchto zpráv tiše zmizí v nevyžádané poště — ne proto, že by váš poskytovatel měl chybu, ale proto, že přesměrování přepíše, kdo zprávu odesílá, bez přepsání kryptografického důkazu. SPF zkontroluje špatný server, verdikt DMARC se změní na selhání, a legální e-mail, který jste si sami poslali, se umístí do karantény. Řešení má jméno: ARC, definované v RFC 8617 z roku 2019.

Proč přesměrování způsobí, že e-mail selže SPF?

Protože SPF zkontroluje poslední server, který zprávu přeposlal, a přesměrování změní tento server. SPF — Sender Policy Framework — je DNS záznam, který uvádí, které IP adresy jsou oprávněny odesílat poštu pro doménu. Když vám bank.com pošle účtenku, přijímající server se ptá: přišlo to z IP adresy, kterou bank.com autorizoval? Ano. Projde.

Teď tu účtenku přepošlite z Gmailu na svou novou adresu. Googléovy servery ji posílají dále. Konečný přijímající server provede kontrolu SPF a ptá se: je Google oprávněn odesílat pro bank.com? Ne, není. SPF selže. Samotná dokumentace Google Workspace to jasně vysvětluje — přeposlané zprávy selžou SPF, protože server pro přesměrování není v SPF záznamu původní domény. Nic se nespofovalo. Kontrola se jen dívá na špatný skok.

Tak proč to skončí v nevyžádané poště?

DMARC. Selhání SPF by samo o sobě bylo řešitelné; DMARC z toho udělal verdikt. DMARC spojuje SPF a DKIM dohromady a říká přijímajícím serverům, co dělat, když oba selžou: nic, karanténa nebo zamítnutí. V roce 2024 nemali velcí odesílatelé na výběr — Google a Yahoo začali vyžadovat DMARC od všech, kdo posílají více než 5 000 zpráv denně jejich uživatelům.

DKIM, druhý pilíř, je podpis vložený do zprávy. Teoreticky by měl přežít přesměrování, protože podepisuje obsah, ne trasu. V praxi je cokoliv, co se zprávy dotkne, zničí. Mailing list, který připojí zápatí „jste přihlášeni, odhlaste se zde", server, který přepíše řádek předmětu, nebo dokonce změna v tom, jak se řádek zalomuje — podpis už se neshoduje a DKIM také selže. Oba pilíře padly, DMARC řekne selhání, a vaše vlastní účtenka je ve složce spam.

Co je ARC a skutečně to řeší?

ARC — Authenticated Received Chain, RFC 8617 — umožňuje čestému přesměrovávači garantovat, že pošta prošla autentizací předtím, než se jí dotkl. Server pro přesměrování označí zprávu zapečetěným záznamem, který říká „když mě tato zpráva dosáhla, SPF a DKIM byly platné — věřte mi na slovo pro cestu, kterou nemůžete ověřit." Konečný přijímající server, pokud tomuto přesměrovávači věří, může přepsat selhání DMARC a doručit zprávu.

Úlovek je ve slovech „pokud věří." ARC není heslo; je to reputační systém. Přijímající server váží, zda je tvůrce ARC pečetě známý, dobře se chující operátor. Google jak přidává ARC hlavičky, tak je ctí od odesílatelů, kterým věří, a proto se přesměrování z Gmailu na Gmail obvykle podaří, zatímco přesměrování přes nějaký starý vysokoškolský přepínač ne.

Pokud přesměrování provozujete sami, pomohou dva konkrétní kroky. Pokud váš hostitel nabízí Server-Side Redirect / přepis ve stylu SRS, který přepíše odesílatele obálky tak, aby SPF kontroloval vašeho přesměrovávače místo původní domény. A dávejte přednost přesměrování mezi poskytovateli, kteří oba podporují ARC. Pokud konsolidujete účty a chcete, aby cíl za vás vyřešil autentizační zmatek, přesně to je ten druh instalatérství, pro který je AI e-mailová platforma stavěná, aby absorbovala.

Kdy bych měl přestat vinit svého poskytovatele?

Když je vzorec „selžou jen přeposlané zprávy," poskytovatel dělá svou práci správně — problém je v protokolu. Tady je indicie: otevřete hlavičky chybějící zprávy a hledejte řádek Authentication-Results. Pokud vidíte spf=fail vedle odesílací IP adresy, která patří přesměrovávači spíše než původnímu odesílateli, to je SPF kontrolující špatný skok. Pokud se dkim=fail objeví na poště, která prošla seznamem nebo přepínačem, který upravuje zprávy, to je znetvořený podpis, ne padělání.

Nepříjemnou pravdou je, že autentizace e-mailu byla dvě desetiletí připevňována vrstvu za vrstvou k systému, který nikdy nepředpokládal, že by se někdo mohl lhát. SPF přišel v roce 2006, DKIM v roce 2007, DMARC v roce 2015, ARC v roce 2019 — každý opravoval díru, kterou ten předchozí otevřel. Přesměrování je místo, kde se všechny čtyři tírají o sebe, a vaše doručená pošta je místo, kde cítíte tření.

daily messages that trigger Google & Yahoo's DMARC requirement (2024)

Zdroje

  1. IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
  2. Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
  3. Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold

← Všechny články