DMARC - DMARC

Tento článek je o systému ověřování e -mailů. Propojovací bod telefonie viz demarkační bod .
Nesmí být zaměňována s dMarc Broadcasting .

DMARC ( Domain-based Message Authentication, Reporting and Conformance ) je protokol pro ověřování e - mailů . Je navržen tak, aby poskytl vlastníkům e -mailových domén možnost chránit jejich doménu před neoprávněným použitím, běžně známým jako podvržení e -mailu . Smyslem a hlavním výsledkem provádění DMARC je chránit domény byly použity v pracovní e-mailové kompromisních útoky , phishing e-maily, e-mailových podvodů a jiných kybernetické hrozby aktivit.

Jakmile je položka DMARC DNS publikována, každý přijímající e -mailový server může ověřit příchozí e -mail na základě pokynů publikovaných vlastníkem domény v položce DNS. Pokud e -mail projde ověřením, bude doručen a lze mu věřit. Pokud e -mail neprojde kontrolou, v závislosti na pokynech uložených v záznamu DMARC může být e -mail doručen, umístěn do karantény nebo odmítnut. Například jedna služba pro přeposílání e-mailů doručuje poštu, ale jako „Od: bez odpovědi@<služba pro přesměrování>“.

DMARC rozšiřuje dva stávající mechanismy ověřování e -mailů, Sender Policy Framework (SPF) a DomainKeys Identified Mail (DKIM). Umožňuje správci domény publikovat zásadu ve svých záznamech DNS a určit, jaký mechanismus (DKIM, SPF nebo obojí) se používá při odesílání e -mailů z této domény; jak zkontrolovat From:pole zobrazené koncovým uživatelům; jak by se měl příjemce vypořádat s poruchami - a mechanismus hlášení akcí prováděných podle těchto zásad.

DMARC je definován v publikovaném dokumentu Internet Engineering Task Force RFC 7489 z března 2015 jako „Informační“.

Přehled

Zásady DMARC umožňují doméně odesílatele označit, že jsou jeho e -maily chráněny SPF a/nebo DKIM, a sdělují příjemci, co má dělat, pokud žádná z těchto metod ověřování neprojde - například odmítne zprávu nebo ji umístí do karantény. Zásady mohou také určit, jak může příjemce e -mailu hlásit zpět do domény odesílatele zprávy, které prošly a/nebo selhaly.

Tyto zásady jsou publikovány ve veřejném systému doménových jmen (DNS) jako textové záznamy TXT .

DMARC přímo neřeší, zda je či není e -mail spam nebo jiný podvod. Místo toho může DMARC požadovat, aby zpráva nejen prošla ověřením DKIM nebo SPF, ale také aby prošla zarovnáním . V rámci DMARC může zpráva selhat, i když projde SPF nebo DKIM, ale selže zarovnání.

Nastavení DMARC může zlepšit doručitelnost zpráv od legitimních odesílatelů.

Vyrovnání

DMARC funguje tak, že zkontroluje, zda je doména v poli zprávy From:(nazývaná také „RFC5322.From“) „zarovnána“ s jinými ověřenými názvy domén. Pokud kontrola zarovnání SPF nebo DKIM projde, pak test zarovnání DMARC projde.

Zarovnání může být specifikováno jako přísné nebo uvolněné. Pro přesné zarovnání musí být názvy domén shodné. Pro uvolněné zarovnání se musí shodovat „organizační doména“ nejvyšší úrovně. Organizační doménu zjistíte tak, že zkontrolujete seznam veřejných přípon DNS a přidáte další štítek DNS. Například „abcdexample.com.au“ a „example.com.au“ mají stejnou organizační doménu, protože existuje registrátor, který zákazníkům nabízí jména v „.com.au“. Ačkoli v době specifikace DMARC existovala pracovní skupina IETF na hranicích domény, v současné době lze organizační doménu odvodit pouze ze seznamu veřejných přípon .

Stejně jako SPF a DKIM, DMARC používá koncept vlastníka domény, entity nebo entit, které jsou oprávněny provádět změny v dané doméně DNS.

SPF kontroluje, zda je IP adresa odesílajícího serveru autorizována vlastníkem domény, která je uvedena v MAIL FROMpříkazu SMTP . (E-mailová adresa v MAIL FROM se také nazývá odrazová adresa , obálka-z nebo RFC5321.MailFrom.) Kromě požadavku na kontrolu SPF DMARC kontroluje, zda je RFC5321.MailFrom zarovnán s 5322.From.

DKIM umožňuje kryptograficky podepsat části e -mailové zprávy a podpis musí pokrývat pole Od. V hlavičce pošty DKIM-Signature tagy d=(doména) a s=(volič) určují, kde v DNS má být získán veřejný klíč pro podpis. Platný podpis dokazuje, že podepisující osoba je vlastníkem domény a že pole Od nebylo od použití podpisu upraveno. Na e -mailové zprávě může být několik podpisů DKIM; DMARC vyžaduje jeden platný podpis, kde se doména ve d=značce shoduje s doménou odesílatele uvedenou v poli From:záhlaví.

DNS záznam

DMARC záznamy jsou zveřejněny v DNS s subdomény štítkem _dmarc, například _dmarc.example.com. Srovnejte to s SPF na example.coma DKIM v selector._domainkey.example.com.

Obsah záznamu zdroje TXT se skládá ze name=valueznaček oddělených středníkem, podobně jako SPF a DKIM. Například: 

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:[email protected];"

Zde vje verze, pje zásada (viz níže), spzásada subdomény, pctprocento „špatných“ e -mailů, na které se mají zásady použít, a ruaje URI, na který se mají odesílat agregované zprávy. V tomto příkladu má subjekt ovládající doménu DNS domény example.com v úmyslu monitorovat četnost selhání SPF a/nebo DKIM a neočekává odesílání e -mailů ze subdomén example.com. Subdoména může publikovat svůj vlastní záznam DMARC; příjemci si to musí zkontrolovat, než se vrátí k záznamu o organizační doméně.

Adopce krok za krokem

Protokol poskytuje různé ráčny nebo přechodné stavy, které umožňují správcům pošty postupně přecházet z neimplementace DMARC až do neústupného nastavení. Koncept postupné adopce předpokládá, že cílem DMARC je nejsilnější nastavení, což neplatí pro všechny domény. Bez ohledu na záměr umožňují tyto mechanismy větší flexibilitu.

Politika

V první řadě existují tři zásady:

  • žádný není zásadou vstupní úrovně. Přijímače nevyžadují žádné zvláštní zacházení, ale umožňují doméně přijímat zprávy o zpětné vazbě.
  • karanténa žádá příjemce, aby se zprávami, které neprojdou kontrolou DMARC, nakládali s podezřením. Různé přijímače mají různé způsoby implementace, například označují zprávy nebo je doručují do složky nevyžádané pošty.
  • odmítnout žádá příjemce, aby zcela odmítli zprávy, které neprojdou kontrolou DMARC.

Zveřejněnou zásadu lze zmírnit tím, že ji použijete pouze na určité procento zpráv, které neprojdou kontrolou DMARC. Příjemci jsou vyzváni, aby vybrali dané procento zpráv jednoduchým algoritmem Bernoulliho vzorkování . Zbytek zpráv by měl projít nižší politikou; to znamená none if p=quarantine, karanténa if p=reject. Pokud není zadáno, pct má ve výchozím nastavení 100% zpráv. Případ p=quarantine; pct=0;se používá k vynucení správců seznamů adresátů k přepsání pole Od: protože někteří tak nečiní kdy p=none.

Nakonec zásady subdomén sp=a nově přidané zásady bez domény umožňují vyladit zásady pro konkrétní subdomény.

Zprávy

DMARC je schopen vytvářet dva samostatné typy zpráv. Souhrnné zprávy se odesílají na adresu uvedenou níže rua. Forenzní zprávy jsou zasílány e -mailem na adresu následující za ruftagem. Tyto poštovní adresy je třeba zadat ve formátu URI mailto (např. Mailto: [email protected]). Několik adres pro hlášení je platných a musí být v plném formátu URI oddělené čárkou.

Cílové e -mailové adresy mohou patřit externím doménám. V takovém případě musí cílová doména nastavit záznam DMARC, aby řekla, že souhlasí s jejich přijetím, jinak by bylo možné využít hlášení k zesílení nevyžádané pošty . Řekněme například, že receiver.exampleobdrží e -mailovou zprávu From: [email protected]a chce ji nahlásit. Pokud najde ruf=mailto:[email protected], vyhledá potvrzující záznam DNS v oboru názvů spravovaném cílem, například takto: 

sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"

Souhrnné zprávy

Souhrnné zprávy se odesílají jako soubory XML , obvykle jednou denně. Předmětem zmiňuje „Domain Report“, který označuje název domény DNS, o kterém byla generována zpráva a „zpracovatel“, což je subjekt, který vydává zprávu. Užitečné zatížení je v příloze s dlouhým názvem souboru, který se skládá z prvků oddělených třeskymi, jako je přijímač vydávající zprávy, počáteční a koncové epochy vykazovaného období jako časová razítka ve stylu Unixu, volitelný jedinečný identifikátor a rozšíření, které závisí na možná komprese (bývala .zip).

Například: example.com!example.org!1475712000!1475798400.xml.gz.

Obsah XML se skládá z hlavičky, která obsahuje zásady, na nichž je sestava založena, a metadata sestavy, za kterými následuje řada záznamů. Záznamy lze vložit do databáze jako relaci a prohlížet v tabulkové podobě. Schéma XML je definováno v dodatku C specifikací a příkladem nezpracovaného záznamu je dmarc.org. Zde se držíme relačního příkladu, který lépe vyjadřuje povahu dat. Záznamy DMARC lze také přímo transformovat do HTML použitím šablony stylů XSL .

DMARC řádky agregovaného záznamu zobrazené v tabulkové formě
Zdroj IP Počet Dispozice SPF DKIM Záhlaví od Doména SPF (výsledek) Doména DKIM (výsledek)  
192.0.2.1 12 žádný ✓  Pass ✓  Pass example.org example.org ( ✓  Pass ) example.org ( ✓  Pass )  
192.0.2.1 1 žádný ✓  Pass Ail  Selhání example.org example.org ( ✓  Pass ) example.org ( ✗  Selhání )  
192.0.2.28 42 žádný Ail  Selhání ✓  Pass example.org example.org ( ✗  Selhání ) example.org ( ✓  Pass ) forwarder.example ( ✓  Pass )
192.0.2.82 21 žádný Ail  Selhání Ail  Selhání example.org Disclist.example ( ✓  Pass ) example.org ( ✗  Selhání ) Disclist.example ( ✓  Pass )
...

Řádky jsou seskupeny podle zdrojové IP a výsledků ověřování, přičemž předávají pouze počet každé skupiny. Sloupce výsledků zcela vlevo, označené SPF a DKIM, ukazují výsledky podle DMARC, buď vyhovující, nebo neúspěšné, s přihlédnutím k zarovnání. Ty nejsprávnější, s podobnými štítky, zobrazují název domény, která tvrdí, že se účastní odesílání zprávy, a (v závorkách) stav autentizace tohoto nároku podle původního protokolu, SPF nebo DKIM, bez ohledu na zarovnání identifikátoru. Na pravé straně se SPF může objevit maximálně dvakrát, jednou pro Return-Path:test a jednou pro HELOtest; DKIM se může objevit jednou pro každý podpis přítomný ve zprávě. V příkladu první řádek představuje hlavní tok pošty z example.org a druhý řádek je závada na DKIM, například porušení podpisu v důsledku drobné změny v přenosu. Třetí a čtvrtý řádek ukazují typické režimy selhání předávacího serveru a seznamu adresátů. Ověření DMARC se nezdařilo pouze pro poslední řádek; mohlo by to ovlivnit dispozice zprávy, kdyby example.org určil přísné zásady.

Dispozice odráží politiku publikovaný ve skutečnosti aplikovat na zprávy, nikdo , karanténa , nebo odmítnout . Spolu s tím, není to uvedeno v tabulce, DMARC poskytuje přepsání zásad. Některé důvody, proč může příjemce uplatňovat jinou zásadu než požadovanou, jsou již ve specifikaci uvedeny:

přeposláno
při zachování stejné adresy pro odražení obvykle neporuší DKIM,
odebrány vzorky
protože odesílatel se může rozhodnout použít zásady pouze na procento zpráv,
důvěryhodný dopravce
zpráva přišla z místně známého zdroje
poštovní seznam
příjemce heuristicky určil, že zpráva přišla ze seznamu adresátů,
místní politika
příjemci mohou samozřejmě uplatňovat zásady, které se jim líbí, je skvělé dát vědět odesílatelům,
jiný
pokud nic z výše uvedeného neplatí, pole komentáře umožňuje říci více.

Forenzní zprávy

Forenzní zprávy, také známé jako Zprávy o selhání, jsou generovány v reálném čase a skládají se z upravených kopií jednotlivých e -mailů, u nichž selhal SPF, DKIM nebo obojí na základě hodnoty, která je uvedena ve foznačce. Jejich formát, rozšíření formátu hlášení zneužití , se podobá běžným odrazům v tom, že obsahují buď „message/rfc822“ nebo „text/rfc822-headers“.

Forenzní zprávy také obsahují následující:

- Zdroj odesílání IP adresy

- Z e -mailové adresy

- E -mailová adresa příjemce

- Předmět e -mailu

- Výsledky ověřování SPF a DKIM

- Přijatý čas

- Záhlaví e -mailových zpráv, která zahrnují odesílajícího hostitele, ID e -mailové zprávy, podpis DKIM a další vlastní informace v záhlaví.

Kompatibilita

Vyvážecí soupravy

Existuje několik různých typů přeposílání e -mailů , z nichž některé mohou narušit SPF.

Seznam e-mailových adres

Seznamy adres jsou častou příčinou oprávněného porušení podpisu DKIM domény původního autora, například přidáním předpony do záhlaví předmětu. Je možná řada zástupných řešení a softwarové balíčky seznamu adresátů pracují na řešeních.

Vypněte všechny úpravy zpráv

Toto řešení zachovává standardní pracovní postup seznamu adresátů a je přijato několika velkými operátory seznamu adresátů, ale vylučuje přidání seznamu zápatí a předpon předmětu. To vyžaduje pečlivou konfiguraci softwaru pro zasílání e -mailů, aby se zajistilo, že podepsaná záhlaví nebudou přeskupována ani upravována. Nesprávně nakonfigurovaný poštovní server může ve svém DKIM zadat ID-seznamu zpráv odeslaných do seznamu adresátů a poté je provozovatel seznamu nucen jej odmítnout nebo provést přepis od:.

From: přepisování

Jedno z nejpopulárnějších a nejméně rušivých řešení spočívá v přepsání From:pole záhlaví. Do Reply-To:pole pak lze přidat původní adresu autora . Přepisování se může pohybovat od pouhého připojení .INVALIDk názvu domény, až po přidělení dočasného ID uživatele tam, kde je použit neprůhledný ID, čímž se zachová soukromá „skutečná“ e -mailová adresa uživatele ze seznamu. Zobrazovaný název lze navíc změnit tak, aby zobrazoval autora i seznam (nebo operátor seznamu). Tyto příklady by měly za následek jeden z následujících: 

From: John Doe <[email protected]>
From: John Doe <[email protected]>
From: John Doe via MailingList <[email protected]>
and
Reply-To: John Doe <[email protected]>

Poslední řádek Reply-To:,, musí být navržen tak, aby vyhovoval funkcím odpovědi autorovi, v případě, že je funkce odpovědi na seznam pokryta předchozí změnou v poli From:záhlaví. Tím se obrátí původní význam těchto polí.

Změna autora není obecně spravedlivá a může narušit očekávaný vztah mezi významem a vzhledem tohoto data. Také to narušuje jeho automatické používání. Existují komunity, které ke koordinaci své práce používají seznamy adres, a nasazují nástroje, které pomocí From:pole připisují autorství přílohám.

Další řešení

Zabalení zprávy funguje dobře pro ty, kteří používají e -mailového klienta, který rozumí zabaleným zprávám. Neudělat žádnou změnu je možná nejzjevnější řešení, kromě toho, že se v některých zemích zdají být právně splatné a že rutinní ztráta autentizace SPF může způsobit, že celková autentizace bude křehčí.

Pole odesílatele

Provedením změn v From:poli záhlaví pro předání zarovnání DKIM může dojít k vyřazení zprávy z souladu s oddílem 3.6.2 RFC 5322: "Pole 'Od:' uvádí autora (y) zprávy, tj. Poštovní schránky osoby nebo systémů odpovědných za napsání zprávy. “ Schránka odkazuje na e -mailovou adresu autora. Sender:Záhlaví je k dispozici naznačují, že e-mail byl odeslán jménem jiné strany, ale pouze kontroluje DMARC politika Od doménu a ignoruje doménu odesílatele.

ADSP i DMARC odmítají použití pole Odesílatel na netechnické bázi, že mnoho uživatelských agentů to příjemci nezobrazuje.

Dějiny

Návrh specifikace DMARC je zachován od 30. ledna 2012.

V říjnu 2013 byl vydán GNU Mailman 2.1.16 s možnostmi zpracování plakátů z domény se zásadami DMARC p=reject. Změna se pokusila předvídat problémy s interoperabilitou očekávané v případě, že na domény s lidskými uživateli byly použity restriktivní zásady (na rozdíl od čistě transakčních poštovních domén).

V dubnu 2014 změnila společnost Yahoo své zásady DMARC na p=reject, což v několika e -mailových seznamech způsobilo nevhodné chování. O několik dní později také AOL změnila své zásady DMARC na p=reject. Tyto pohyby vedly ke značnému narušení provozu a tito poskytovatelé poštovních schránek byli obviněni z vynucování nákladů na vlastní selhání zabezpečení třetím stranám. Od roku 2020 obsahuje FAQ v oficiální wiki DMARC několik návrhů na seznamy adres, aby bylo možné zpracovávat zprávy z domény s přísnými zásadami DMARC, z nichž nejrozšířenější je seznam adresátů měnící záhlaví „Od“ na adresu ve svém vlastní doména.

V srpnu 2014 byla vytvořena pracovní skupina IETF s cílem řešit problémy DMARC, počínaje obavami z interoperability a případně pokračovat s revidovanou standardní specifikací a dokumentací. Mezitím stávající specifikace DMARC dosáhla redakčního stavu, na kterém se dohodli a implementovali mnozí. Byl publikován v březnu 2015 na streamu Nezávislého podání v kategorii „Informační“ (nestandardní) jako RFC 7489.

V březnu 2017 zveřejnila Federální obchodní komise studii o používání DMARC v podnicích. Ze 569 podniků studie zjistila, že asi třetina implementovala jakoukoli konfiguraci DMARC, méně než 10% použilo DMARC k pokynu serverům odmítnout neověřené zprávy a většina implementovala SPF.

Přispěvatelé

Mezi přispěvatele specifikace DMARC patří:

Viz také

Poznámky

Reference

externí odkazy