www.SAMURAJ-cz.com 

25.02.2020 Liliana Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Ověřování emailů pomocí DKIM - DomainKeys Identified Mail

Pátek, 17.01.2020 10:41 | Samuraj - Petr Bouška |
Metody pro ověřování původu poštovních zpráv (Email Authentication) kontrolují poštovní servery, které se účastní odeslání (a možné modifikace) emailu. Cílem je ověřit, že byla zpráva zaslána autorizovaným odesílatelem (serverem). Kontroluje se doména odesílatele, ne přímo emailová adresa. Po SPF je druhá rozšířená technika je DKIM. Ta spočívá v podepisování zpráv privátním klíčem pro doménu. Veřejný klíč pro ověření je publikován v DNS. Podpis se vkládá jako položka hlavičky, takže neovlivňuje běžný provoz.

Tento článek navazuje na předchozí

DKIM vs. SPF

Pokud nastavíme SPF pro doménu, tak příjemce může detekovat, jestli někdo cizí zkusí odeslat email za danou doménu. Tedy kontrolujeme všechny zprávy, kde je adresa odesílatele z dané domény, a buď byla zpráva přijata z autorizovaného serveru nebo ne a je patrně podvržena.

Když používáme DKIM, tak příjemce kontroluje podpis pouze u podepsaných zpráv. Chyba podpisu nastane (v praxi nejčastěji), když se odesílatel rozhodne tuto technologii používat, ale špatně ji nastaví (například mu chybí veřejný klíč v DNS nebo po podepsání zprávy ještě provede modifikaci). Nebo pokud by ji někdo po cestě upravil. DKIM nám tedy nepomůže poznat, že se někdo cizí snaží podvrhnout email za doménu. Museli bychom pro danou doménu povolit pouze podepsané emaily. V praxi je pro nás zajímavá informace, že byl email korektně podepsaný. Ta se ale ke koncovému uživateli jednoduše nedostane. Navíc DKIM může korektně podepsat email úplně jinou doménou, než z jaké je zpráva odeslána.

DKIM a politiky?

Původní DomainKeys RFC 4870 (zastaralé) obsahovalo definici politiky, zda musí být emaily pro doménu podepsány. Mnoho návodů pro DKIM popisuje tuto politiku, i když DKIM norma nic takového neobsahuje. Politika se zapisuje jako _domainkey TXT záznam v DNS odesílající domény (příklad _domainkey.firma.cz). Obsah TXT záznamu může být (podporovány jsou i další značky) o=- všechny zprávy musí být podepsány nebo o=~ mohou být podepsány (výchozí hodnota).

Další možnost je rozšíření DKIM Author Domain Signing Practices (ADSP) popsané v RFC 5617, ale dnes se doporučuje využít DMARC, na který se podíváme příště. ADSP také definuje chování pomocí _adsp._domainkey TXT záznamu v DNS odesílající domény (příklad _adsp._domainkey.firma.cz). Obsah TXT záznamu je značka dkim= a hodnoty unknown (podepisuje některé nebo všechny zprávy), all (všechny zprávy jsou podepsané) a discardable (všechny zprávy jsou podepsané, pokud ne, tak má příjemce zprávu zahodit).

Prinicp DKIM - DomainKeys Identified Mail

Metoda DomainKeys Identified Mail (DKIM) je popsaná jako internetový standard v RFC 6376. V navržených standardech RFC 8301 a RFC 8463 je uvedena aktualizace používaných algoritmů, pro dosažení lepší bezpečnosti (známé zranitelnosti či slabiny). DKIM vzniklo spojením technik Yahoo DomainKeys a Cisco Identified Internet Mail.

DKIM je značně odlišné od SPF, ale také využívá záznam v DNS, kde se spoléhá na to, že záznamy vytváří majitel domény. Podpis standardně vytváří odesílající poštovní server (či brána). Nijak se ovšem neověřuje adresa serveru, který zprávu posílá či přeposílá. Vychází se z toho, že ten, kdo zprávu podepsal (vytvořil), vlastní soukromý klíč, a je tedy oprávněný odeslat email za danou doménu. Pokud je zpráva předávána dále dalšími servery, a nedojde k její modifikaci, tak je vše v pořádku.

Využívá se digitální podpis. Každý email je v hlavičce doplněna o položku, kde se nachází podpis zprávy pomocí privátního klíče. Odpovídající veřejný klíč pro doménu je uložen v DNS záznamu a každý pomocí něj může ověřit podpis zprávy. Podpisy nejsou přímo viditelné pro koncové uživatele a standardně je ověřuje server. Kontrola potvrzuje, že zpráva pochází od autorizovaného zdroje (dané domény), a že nebyla po cestě modifikována.

Podpis se přidává do položky hlavičky DKIM-Signature. Nijak tedy neovlivňuje zprávu a u příjemce (po cestě) není nutná podpora této technologie. Neklade žádné nároky na koncové uživatele, kteří nemusí řešit elektronické podpisy, certifikáty apod. Nepoužívají se certifikáty, takže se neřeší důvěryhodnost pomocí certifikačních autorit. Pro důvěryhodnost klíče se využívá DNS (že záznam může vložit pouze majitel). Pro digitální podpis se používá asymetrická kryptografie, ale princip se značně odlišuje od S/MIME či OpenPGP.

Jak funguje digitální podpis

Asymetrická kryptografie využívá dva klíče (veřejný, který se otevřeně distribuuje, a soukromý, který zná pouze majitel). Klíče se generují podle určitého kryptografického algoritmu (jako RSA či ECC), z privátního klíče můžeme spočíta t veřejný. Nejznámější využití je pro

  • šifrování s veřejným klíčem - kdokoliv může data zašifrovat veřejným klíčem, rozšifrovat se dají pouze soukromým klíčem
  • digitální podpis (autentizace) - k podepsání dat se využívá soukromý klíč, pomocí veřejného může kdokoliv ověřit platnost

Digitální podpis funguje tak, že se pro podepisovaná data spočítá hash (pomocí určité hashovací funkce, jako je SHA256) a ten se zašifruje soukromým klíčem. Výsledná šifrovaná data jsou digitální podpis (podpis obsahuje také časové razítko, kdy k podpisu došlo). Pokud dojde ke změně dat, tak je podpis neplatný.

Při ověření podpisu se pomocí veřejného klíče rozšifruje podpis (hash). Pak se k datům spočítá hash (danou funkcí) a oba hashe se porovnají. Pokud jsou obě hodnoty stejné, tak je podpis platný.

Pozn.: Pokud se data zašifrují privátním klíčem, tak je možno je rozšifrovat pouze veřejným klíčem. A naopak zašifrovaná data veřejným klíčem se rozšifrují pouze soukromým.

DKIM podepisování poštovních zpráv

Pro použití DKIM musíme nejprve vygenerovat pár klíčů (soukromý a veřejný) dle daného algoritmu. DKIM podporuje více algoritmů digitálního podpisu. Podporovaný musí být RSA-SHA256 a je doporučený normou RFC 6376. Pro výpočet hashe se tedy použije SHA-256 a pro zašifrování RSA, kde je třeba volit dostatečnou délku klíče (klíče se také doporučuje pravidelně obměňovat).

RFC 8301 zakazuje použití SHA-1, určuje minimální délku RSA klíče 1024 bitů (dříve 512) a doporučenou 2048 bitů a musí být podporováno 4096 bitů. Praktický problém je, že dlouhý klíč se nevejde do DNS TXT záznamu, který má maximální délku 255 znaků (mělo by jít rozdělit klíč do více částí / řádků). RFC 8463 přidává algoritmus eliptických křivek Edwards-Curve Digital Signature Algorithm (Ed25519) k dříve jedinému RSA. To umožňuje bezpečné využití kratších klíčů. Pro digitální podpis je k dispozici algoritmus Ed25519-SHA256. Kvůli zpětné kompatibilitě je možno přidávat více podpisů k emailům (a v DNS mít více záznamů s různým selektorem).

Pozn.: V praxi se stále majoritně využívá RSA a délka klíče 1024 bitů. Například v poslední verzi dokumentace Cisco Email Security se uvádí, že bezpečná a doporučovaná délka klíče je 768 - 1024 bitů a nepodporuje delší než 2048.

Podepisování provádí zpravidla odesílající poštovní server (nebo brána), který vlastní soukromý klíč pro doménu. Do hlavičky emailu přidává položku (Header Field) DKIM-Signature. Tato položka má být brána jako trasovací (Trace Header Field) a tedy při přenosu zprávy musí být zachována a zůstávat ve stejném pořadí. Hodnota DKIM-Signature je seznam značek (Tag List) oddělených středníkem, tedy jednotlivé položky značka=hodnota (tag=value).

Používané značky (tagy) v DKIM-Signature

(P) znamená, že daná značka se musí v záznamu nacházet (je povinná).

  • v - version (P) - verze specifikace DKIM, zatím 1
  • a - algorithm (P) - algoritmus pro generování podpisu, standardně rsa-sha256 nebo nové ed25519-sha256
  • b - signature data (P) - podpis (hlavičky a dat) v Base64
  • bh - hash of body (P) - hash kanonikalizované (canonicalized) části těla zprávy (může být omezeno značkou l)
  • c - canonicalization - algoritmus kanonikalizace pro hlavičku/tělo, default je simple/simple
  • d - domain (P) - doména zprávy, v této doméně se hledá DKIM záznam
  • h - header fields (P) - seznam položek z hlavičky, oddělených dvojtečkou, které jsou podepsané
  • i - agent or user identifier - identifikátor agenta nebo uživatele, standardně zavináč a doména z d
  • l - length - délka těla zprávy po kanonikalizaci, z kterého se počítá hash, default je celé tělo
  • q - query methods - seznam dotazovacích metod pro získání veřejného klíče, default (a jediná možnost) dns/txt
  • s - selector (P) - selektor pro rozdělení prostoru jmen domény v DNS
  • t - timestamp - časové razítko, kdy byl podpis vytvořen
  • x - expiration - datum, kdy končí platnost podpisu
  • z - copied header fields - může zde být kopie hodnot položek hlavičky, oddělení pomocí |

Příklad položky DKIM-Signature v hlavičce

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=beta;
  t=1578641730; bh=/TD0lk+sB1gnEN1dbkIDJAt59PhptcTvRhtuO1OrpNs=;
  h=Received:From:To:Subject:Date:Message-Id:Mime-Version:X-Mailer:Content-Type;
  b=LfWqIXU+MPBXIgfdHqh5y6TGGK/avFzMX6Lu7mFKNE8sPSCIGV8Vy5iFIyUMqFvyj
  UnWwctBxpDJ8TuaCOHB3dMp0PD9CdmZGa/0vOJhFE/SxVHFVs/iUDR7HLvTvfG2PA9
  hwLQxdZAuX4PIDOGTgERxJ/FB9fxb0H3ga7FPuno=

Kanonikalizace - Canonicalization

Při přenosu poštovní zprávy by nemělo docházet k její modifikaci, přesto může dojít k sémanticky nevýznamných změnám (například změna velikosti písmen v hlavičce, přidání či odebrání bílých znaků). V takovém případě by byl podpis neplatný. DKIM nabízí možnost provést určitou definovanou úpravu dat (kanonikalizaci) před výpočtem hashe. Můžeme určit, že se používají originální data, parametr simple. Nebo se úprava provede, hodnota relaxed. Hodnota se zadává pro hlavičku/tělo. Výchozí je simple/simple, tedy bez úprav.

Výpočet hashů pro zprávu

Podpis i ověřování podpisu zprávy má jako základ výpočet dvou hashů. Podepisující (Signer) volí algoritmus a parametry, ověřovatel (Verifier) použije parametry z DKIM-Signature. První hash se počítá pro tělo zprávy (použije se uvedený kanonikalizační algoritmus (c) a délka se případně zkrátí podle (l)). Poté se převede na base64 a buď se vloží nebo porovná se značkou bh. Druhý hash se počítá pro zvolené položky hlavičky (vždy se započítává položka DKIM-Signature se značkou (b) prázdnou, na data se použije uvedený kanonikalizační algoritmus). Hash se následně podepíše daným algoritmem (a) a vloží jako značka b.

Podepisovat můžeme i položky hlavičky, které se ve zprávě nenachází. Tím zabezpečíme situaci, kdy by někdo cestou hlavičku doplnil (musíme počítat s tím, že určité hlavičky se po cestě doplňovat mají). RFC obsahuje seznam položek, které mají vztah k tělu zprávy, a tedy je dobré je podepisovat:

  • From (povinné)
  • Reply-To
  • Subject
  • Date
  • To, Cc
  • Resent-Date, Resent-From, Resent-To, Resent-Cc
  • In-Reply-To, References
  • List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

Některé položky hlavičky se mohou vyskytovat vícekrát, pak se podepisuje vždy poslední instance (prochází se odspodu nahoru). Pokud chceme podepsat více výskytů, tak musíme uvést položku vícekrát ve značce (h). Vícekrát můžeme uvést položku i v případě, kdy se aktuálně nachází pouze jednou. Tím zabráníme jejímu možnému dalšímu přidání.

Ověření DKIM podpisu poštovní zprávy

Ověření podpisu se doporučuje provést v době příjmu zprávy hraničním MTA (nečekat, až ke zprávě přistoupí koncový uživatel). Veřejný klíč může být kdykoliv zrušen, takže by se podpis nepovedlo ověřit, i když byl v době doručení platný. MTA může vložit výsledek ověření do položky v hlavičce. Koncový uživatel (poštovní klient) může využít tuto položku k filtrování zpráv.

Pozn.: SPF může odmítnout příjem zprávy již při přijetí SMTP příkazu MAIL FROM, kdežto DKIM musí přijmout celou zprávu.

Jak probíhá ověření podpisu poštovní zprávy

  • při příjmu zprávy se server (ověřovatel) podívá, zda se v hlavičce nachází položka DKIM-Signature
  • načte se DKIM-Signature ve zprávě a získají se parametry
  • pomocí selektoru (s) a domény (d) se sestaví DNS dotaz a hledá TXT záznam pro s._domainkey.d

Pozn.: Zaráží mne, že se ověřuje doména, která je uvedena v podpisu. Ta vůbec nemusí mít vazbu na domému v adrese odesílatele.

  • z DNS záznamu se získá veřejný klíč (a případně další parametry)
  • podle parametrů (c, l, h, a) se spočítají oba hashe zprávy
  • nejprve se porovná spočítaný hash pro tělo zprávy s načtenou hodnotou z podpisu (bh), pokud nesouhlasí vrací PERMFAIL
  • ověří se podpis (b) proti spočítanému hash hlaviček (podpis (b) se rozšifruje (a) veřejným klíčem, tím se získá hash hlaviček, který se porovná), pokud nesouhlasí vrací PERMFAIL
  • pokud nenastala chyba, tak byl podpis úspěšně ověřený, vrací SUCCESS (bylo ověřeno, že je email podepsán uvedenou doménou a zpráva nebyla upravena)

Pozn.: Pokud ověření selže, tak by neměla být zpráva odmítnuta, ale poskytnuta informace, proč nemůže být ověřena autentičnost zprávy.

Vyhodnocení ověření DKIM podpisu

Vyhodnocení (Evaluation) každého podpisu končí jedním ze tří stavů

  • SUCCESS - úspěšně ověřeno
  • PERMFAIL - ověření selhalo či jiná trvalá chyba
  • TEMPFAIL - dočasná chyba, například vypršení časového limitu DNS dotazu

Výsledek ověření podpisu by se měl předávat dále. Jedna z možností je přidat novou položku hlavičky (před existující DKIM-Signature). Jako vhodná se nabízí Authentication-Results.

Záznam veřejného klíče v DNS

DKIM podporuje více současných veřejných klíčů pro jednu doménu. K rozlišení se využívá Selector následovaný povinou částí _domainkey. Selektor může být třeba název lokality nebo datum (je v něm podporována tečka). Tak vzniká FQDN (subdoména), na kterém vytváříme záznam pro DKIM. Například leden.2020._domainkey.firma.cz. Vlastní záznam se publikuje jako DNS TXT (type 16) Resource Record (RR). Jeho formát je, podobně jako DKIM-Signature, složen ze značek oddělených středníkem.

Používané značky (tagy) v DKIM záznamu

(P) znamená, že daná značka se musí v záznamu nacházet.

  • v - version - verze záznamu DKIM klíče, pokud se použije, tak musí být první a obsahovat DKIM1
  • h - hash algorithms - dvojtečkou oddělený seznam přijímaných algoritmů hashe, default jsou všechny (sha256)
  • k - key type - šifrovací algoritmus, standardně RSA (nebo nový ed25519), znamená, že veřejný klíč je uložen jako ASN.1 DER-encoded RSAPublicKey (kódovaný pomocí base64)
  • n - notes - možné poznámky pro lidi
  • p - public-key data (P) - vlastní veřejný klíč, pokud je hodnota prázdná, tak to znamená, že byl odvolán
  • s - service type - pro jaké služby platí tento záznam, zatím možno pouze všechny *
  • t - flags - příznaky, y - tato doména testuje DKIM, s - pokud je v DKIM-Signature značka i, tak musí být doména stejná jako v d (nesmí jít o subdoménu)

Příklad DNS záznamu

"v=DKIM1;k=rsa;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2SyMwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8tt
kI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

Pro kontrolu DNS DKIM záznamu můžeme využít online služby, třeba DKIM Record Lookup, DKIM Record Check, DKIM Core Tools.

Praktické nasazení DKIM

Ověřování DKIM

To je jednoduché. Potřebujeme poštovní bránu (server), která podporuje DKIM (což Exchange Server není). Zapnutí ověřování je pak většinou jednoduché. Otázka je, jak reagovat na různé výsledky testu. U špatného podpisu můžeme doplnit informaci do předmětu zprávy. Pro uživatele je lepší vědět, že zpráva byla korektně podepsána, ale to není dobré umístit do předmětu. Další řešení je DMARC.

Příkladem brány s podporou DKIM je Cisco Email Security. Velmi stručně jsem zapnutí DKIM kontroly i podepisování zpráv popsal v článku Cisco Email Security - konfigurace AntiSpam řešení.

Podepisování DKIM

Potřebujeme poštovní server nebo bránu, která podporuje DKIM a bude provádět podepisování. Záleží, jakou podporu tento server má. Může nám vygenerovat klíče i připravit DNS záznam.

Obecné kroky, které musíme provést pro podepisování

  • určení algoritmů a vlastností a vygenerování klíčů
  • určení selektoru a vytvoření DNS záznamu na naší subdoméně
  • zapnutí podepisování zpráv při odesílání

Generování klíčů

Nejprve potřebujeme vygenerovat pár klíčů a k tomu rozmyslet, jaký chceme použít algoritmus (zatím asi jednoznačně RSA) a jakou délku klíče (pro praxi asi 1024 bitů nebo 2048 bitů).

Pro vygenerování klíčů můžeme použít řadu způsobů

  • webovou službu - z pohledu bezpečnosti není dobré řešení, protože klíče má 3tí strana
  • podepisující aplikaci - řešení, které nám bude vytvářet DKIM podpis, může podporovat i generování klíčů, například Cisco Email Security
  • OpenDKIM - sada nástrojů pro Linux
  • OpenSSL - známá sada nástrojů pro Linux, kompilovaná i pro Windows
  • PuTTYgen - nástroj pro generování klíčů, na Windows má GUI (součást balíku PuTTY)

Na Linuxu je nejlepší použít OpenDKIM, na Windows se dá velmi jednoduše využít OpenSSL for Windows.

Generování soukromého klíče

cd c:\Program Files\OpenSSL-Win64\bin

openssl genrsa -out DKIM-private.key 1024

Výsledný soubor vypadá následně:

 -----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDPtGH8e0rsuw7+Une1zYfuQ4taFz0dmQZqUVRaUN3ty+YLKMYS
2ntfRJsIjVGoEOVxunJMnTZwHNK2EhteyAMLSQ/sHFlE3couty1ExmsJHjeBdgBu
vOubrxAID10lvUUTTTwCqryGwIac59NRaVNsqLfQJnghus1g7BUV9ASSNQIDAQAB
AoGABxFGPEcdt4xt6C16MU97DppxxXEA/V7VnwyBaElUI+FKRJrwkneotwcol1Pn
sWZRyFrlxMGctpfke5mGIOWBZPM3BBPxNrTwSc3S3SIy9IO34UMgE+omGKDWtz6u
Go2BmkcRzGMngyaJ82igtTxae1KoNz8T35hFwQfwCju5osECQQDsJp+Kfkhy+XQk
6bRrO4AUydRDTpoPfPo2ZdtFY+yRa5lYNSiyugibldxiGBJS+Sh4/1Z1PsN1bajK
tjCElkVdAkEA4Smq0umbDQaZRFqkqxM2iM8keQbkQ5ZC//jqvAr9hV/Qqtu/6j7X
c5DJaQS7ouXl69AihtmMofnbwNE3MtUauQJAMTtwIXBobEfjVdq/OWfjMPJO5WVa
qwX0KCkeCJ5ncH3NL12NyY0NRFp+4piAIXo+XNNm0/SszSt6eCB5hvrJJQJBAJzn
MU/aVB7mm0VjuN4x/E2ns23XHJfwjO3dIo45RmN72mhFy93LPs4cdg4Fq0+fzvHd
z0GTNgnlmHosEMAOepkCQQC1RCMPCIsKli3u6Wui5fNAO1FXGWXbcHgHOKFuKm2F
jE09e3CoSkGOrgd2BTvGcO0v3DfNzHzzaUFIHjkMo9la
-----END RSA PRIVATE KEY-----

Výpočet veřejného klíče

openssl rsa -in DKIM-private.key -pubout -out DKIM-public.key

Výsledný soubor vypadá následně:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPtGH8e0rsuw7+Une1zYfuQ4ta
Fz0dmQZqUVRaUN3ty+YLKMYS2ntfRJsIjVGoEOVxunJMnTZwHNK2EhteyAMLSQ/s
HFlE3couty1ExmsJHjeBdgBuvOubrxAID10lvUUTTTwCqryGwIac59NRaVNsqLfQ
Jnghus1g7BUV9ASSNQIDAQAB
-----END PUBLIC KEY-----

DNS záznam pro DKIM veřejný klíč

Pro zvolený selektor (dkim2020) a doménu (firma.cz), například dkim2020._domainkey.firma.cz, vytvoříme TXT DNS záznam (Resource Record). Jeho hodnotu definujeme pomocí značek, povinná je pouze p, kam vložíme veřejný klíč bez hlavičky, patičky a konců řádků. Můžeme dočasně použít značku t=y, že jde o testování.

v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPtGH8e0rsuw7+Une1zYfuQ4taFz0dmQZqUVRaUN3ty+YLKMYS2ntfRJsIjVGoEOVxunJM
nTZwHNK2EhteyAMLSQ/sHFlE3couty1ExmsJHjeBdgBuvOubrxAID10lvUUTTTwCqryGwIac59NRaVNsqLfQJnghus1g7BUV9ASSNQIDAQAB

Prohlédnout záznam můžeme jednoduše, třeba řádkovým příkazem na Windows.

nslookup

> set type=txt
> dkim2020._domainkey.firma.cz
Server:  ns.firma.cz
Address:  192.168.0.10

Non-authoritative answer:
dkim2020._domainkey.firma.cz    text =

"v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPtGH8e0rsuw7+Une1zYfuQ4taFz0dmQZqUVRaUN3ty+YLKMYS2ntfRJsIjVGoEOVxunJM
nTZwHNK2EhteyAMLSQ/sHFlE3couty1ExmsJHjeBdgBuvOubrxAID10lvUUTTTwCqryGwIac59NRaVNsqLfQJnghus1g7BUV9ASSNQIDAQAB"

Pro kontrolu DNS DKIM záznamu můžeme využít online služby, třeba DKIM Record Lookup, DKIM Record Check, DKIM Core Tools.

Podepisování zpráv pomocí DKIM

Pokud náš poštovní server (brána) podporuje DKIM, tak je zapnutí podepisování relativně jednoduché. Například na Cisco Email Security Configuring DomainKeys and DKIM Signing.

Pokud pro odesílání používáme Microsoft Exchange Server, tak máme relativně smůlu, protože on-premises Exchange DKIM nepodporuje (na rozdíl od cloudového Exchange Online). Ale můžeme využít nějaký AddOn (Transport Agent) od třetí strany:

Vyzkoušel jsem Exchange DKIM Signer, který se na Exchange instaluje jako Transport Agent. Má tedy plný přístup ke všem poštovním zprávám, které zpracovává (ono by to jinak nešlo). Takže musíme zvážit důvěryhodnost instalovaného pluginu.

Stručná dokumentace DKIM Signing Agent for Microsoft Exchange Server. Běžná instalace znamená

  • stáhnout poslední verzi DKIM-Exchange Releases.
  • z balíku spustit Configuration.DkimSigner.exe
  • tlačítko Install stáhne větší balík z webu a nainstaluje knihovny podle verze Exchange Server
  • instalace je do C:\Program Files\Exchange DkimSigner, správu provádíme pomocí  Configuration.DkimSigner.exe
  • instaluje se jako Transport Agent, můžeme si vypsat pomocí Get-TransportAgent, po instalaci by měl být poslední Exchange DkimSigner
  • při správě pomocí tlačítka Configure můžeme zkontrolovat, že je poslední
  • na záložce DKIM Settings můžeme přidat položky hlavičky, které se podepisují, a nastavit algoritmus a kanonikalizaci, pro aplikaci volíme úroveň logování
  • na záložce Domain Settings nastavujeme jednotlivé domény, pro které se mají podepisovat zprávy, můžeme vygenerovat klíče nebo načíst vlastní soubor, je zde i navržený DNS záznam veřejného klíče
Exchange DKIM Signer

Agent Exchange DkimSigner nepodepisuje zprávy ve formátu TNEF (Transport Neutral Encapsulation Format, označuje se také jako Outlook Rich Text Format). Tento formát podporuje Microsoft Outlook (pokud zprávu otevírá nepodporovaný klient, tak většinou vidí email s přílohou winmail.dat). Exchange server běžně používá tento formát v rámci Exchange organizace, ale při odesílání na vzdálené příjemce (Remote Domain) je převádí na HTML či jiný formát.

Online kontrola DKIM

Ve chvíli, kdy nakonfigurujeme podepisování zpráv pomocí DKIM, tak můžeme využít některou ze služeb, která nám provede kontrolu, že jsou zprávy korektně podepsané. Buď pošleme mail na zadanou adresu a dostaneme v odpovědi report. Nebo se nám na webové stránce zobrazí adresa, na kterou opět odešleme mail, a na webu uvidíme výsledek testu. Testuje se více vlastností než pouze DKIM.

zobrazeno: 598krát | Komentáře [1]

Autor:

Související články:

Elektronická pošta - email

Protokol SMTP a jeho vlastnosti. Ochrana elektronické pošty proti SPAMu a Phishingu. Šifrování pošty...

Microsoft Exchange

Jednou částí mé práce je administrace poštovního serveru od firmy Microsoft, tedy Exchange Serveru. Články začínají u verze 2003 a jak jde čas, tak pokračují dále.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

  1. [1] Anarchista

    WoW jeden z mála profi článků ! Arigató !

    Úterý, 28.01.2020 21:06 | odpovědět
Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách