Miért landolt a spamben az az email, amit magadnak továbbítottál

Állíts be automatikus továbbítást a régi fiókodról az újra, és egy része az emailnek csendesen eltűnik a spamben — nem azért, mert a szolgáltatód hibás, hanem azért, mert a továbbítás átírja, hogy ki küldi az üzenetet, de nem írja át a kriptográfiai bizonyítékot. Az SPF rossz szervert ellenőriz, a DMARC ítélet bukásra vált, és egy törvényes email, amit magadnak küldtél, karanténba kerül. A megoldásnak van egy neve: ARC, amit az RFC 8617 definiált vissza 2019-ben.

Miért teszi a továbbítás az SPF-et bukni?

Mert az SPF az utolsó szervert ellenőrzi, amely továbbította az üzenetet, és a továbbítás megváltoztatja ezt a szervert. Az SPF — Sender Policy Framework — egy DNS rekord, amely felsorolja, mely IP-címek jogosultak emailt küldeni egy domain számára. Amikor a bank.com visszaigazolást küld neked, a fogadó szerver ellenőrzi: ez az IP-ből érkezett, amely a bank.com engedélyezett? Igen. Megvan.

Most továbbítsd ezt a visszaigazolást a Gmailodból az új címedre. A Google szervereit továbbítják. A végső fogadó szerver futtatja az SPF ellenőrzést és azt kérdezi: a Google jogosult emailt küldeni a bank.com számára? Nem, nem jogosult. Az SPF bukik. A Google saját Workspace dokumentációja ezt világosan kimondja — a továbbított üzenetek buknak az SPF-en, mert a továbbító szerver nincs az eredeti domain SPF rekordjában. Semmi nem volt meghamisított. Az ellenőrzés csak a rossz ugrást nézi.

Szóval miért küld ez a spambe?

DMARC. Az SPF bukása egyedül egykor túlélhető volt; a DMARC ítéletre fordította. A DMARC összekapcsolja az SPF-et és a DKIM-et, és azt mondja a fogadóknak, mit csináljanak, ha mindkettő bukik: semmi, karanténa, vagy elutasítás. 2024-re a nagyobb feladók számára nincs választás — a Google és a Yahoo megkövetelték a DMARC-ot bárki számára, aki több mint 5000 üzenetet küld naponta a felhasználóiknak.

A DKIM, a másik oszlop, az üzenetbe sütött aláírás. Elméletben túlél a továbbítást, mert az tartalom aláírja, nem az útvonalat. A gyakorlatban bármi, ami érinti az üzenetet, eltöri. Egy levelezési lista, amely hozzáfűz egy „ön feliratkozott, leiratkozás itt" láblécet, egy szerver, amely átírja a tárgy sort, még egy sort burkolódó módban történő változása — az aláírás már nem egyezik, és a DKIM is bukik. Most mindkét oszlop lent van, a DMARC bukást mond, és saját visszaigazolásod a szemét mappában van.

Mi az ARC és valóban kijavítja ezt?

Az ARC — Authenticated Received Chain, RFC 8617 — lehetővé teszi egy becsületes továbbítónak, hogy kezességet vállaljon, hogy az email megfelelt az azonosításnak, mielőtt ezzel a kezével érte volna. A továbbító szerver lepecsételi az üzenetet egy zárt rekord megadásával, amely azt mondja, „amikor hozzám érkezett, az SPF és a DKIM érvényes voltak — hallj az én szómra az utért, amelyet nem tudsz ellenőrizni." A végső fogadó, ha megbízik ebben a továbbítóban, felülbírálhatja a DMARC bukást és kézbesítheti.

A csapda az „ha megbízik" részben van. Az ARC nem jelszó; ez egy reputációs rendszer. A fogadó mérlegel, hogy az ARC pecsét adó jól ismert, jó viselkedésű operátor-e. A Google mind az ARC fejléceket bélyegzi, mind pedig tiszteletben tartja őket azoknak a feladóktól, akikben megbízik, ezért továbbítás Gmail-ből Gmailre általában túlél, míg az útvonalat keresztül néhány ókori egyetemi relé nem.

Ha saját maga futtatod a továbbítást, két konkrét lépés segít. Használj Server-Side Redirect / SRS-stílusú átírást, ha a hosztodon elérhető, amely átírja az boríték feladót, így az SPF ellenőrzés az te továbbítód ellen történik az eredeti domain helyett. És részesítsd előnyben a továbbítást olyan szolgáltatók között, amelyek mindketten támogatják az ARC-et. Ha konszolidálsz fiókokat, és azt szeretnéd, hogy a cél egyszerűen kezelje az azonosítás kaoszt helyetted, pontosan erre az épsítésre készült egy AI email platform.

Mikor kellene abbahagynod a szolgáltatódat gyanúsítgatni?

Amikor a minta „csak továbbított mail bukik", a szolgáltató helyesen végzi a munkáját — a protokoll a probléma. Íme a jelzés: nyisd meg a hiányzó üzenet fejlécét és keress egy Authentication-Results sort. Ha az spf=fail mellett egy olyan feladó IP-t látsz, amely egy továbbítóhoz tartozik az eredeti feladó helyett, az SPF a rossz ugrást ellenőrzi. Ha dkim=fail megjelenik egy olyan mailen, amely egy listán vagy egy üzeneteket szerkesztő relén átment, ez egy elrontott aláírás, nem hamisítás.

A kellemetlen igazság az, hogy az email hitelesítés rátoldva lett, rétegről rétegre, két évtized alatt egy olyan rendszerre, amely soha nem feltételezett, hogy bárki hazudni fog. Az SPF 2006-ban jött, a DKIM 2007-ben, a DMARC 2015-ben, az ARC 2019-ben — mindegyik megjavította az lyukat, amit az előző nyitott. A továbbítás az a varrás, ahol mind a négy egymáshoz súrlódik, és a te beérkezési mappád az, ahol érzed a súrlódást.

@@END@@