Názory k článku DKIM podpisy pro důveryhodnější e-mail
-
Ondřej CaletkaZlatý podporovatelVám nepíše nikdo z Gmailu?
Pokud vám chodí spam s validním DKIM podpisem, máte aspoň jistotu, že spam přišel ze serveru, odkud tvrdí že přišel, takže víte, na koho si máte stěžovat.
-
Kverulant (neregistrovaný)
Bohuzel, nekdy mi take prijde SPAM a ma SPF i DKIM oboje validni. Jenze to ma odesilatel trojskeho kone v kompu, pres ktery utocnik rozesila SPAM. Obycejne klasicke padelani a vydavani se za nekoho jineho je ale diky SPF a DKIM mnohem obtiznejsi, zbyva jen hacknout ten komp a vzdalene jej nejakym bootnetem ovladat.... co u nekterych BFU neni bohuzel problem....
-
M. (neregistrovaný)
Ono se jede i to, že se jen ukradnou autorizační údaje z Outlooku/Thunderbirda a pak pomocí nich valí z několika míst spamy přes ten správný SMTP server s ověřením. Zrovna včera jsem propleskával takového neštastníka. Nečím se mu vyžraly autorizační údaje a pak pomocí nich přes správný SMTP daného uživatele (takže jak bylo znmíněno, tak SPF a DKIM v pořádku) z Ukrajiny, Azerbajdžánu a dalších jelo rozesílání nějakého svinsta (SPAMu ne, posílalo to nějaký SCR a Eset a další na něj ani nepípl, takže asi nějaký nový downloader bordelu).
-
Filip JirsákStříbrný podporovatelTo je ale nepochopení SPF a DKIM. Ani jedno nemá bránit rozesílání spamu. Problém se spamem je ale ten, že nevíte, kdo ho rozesílá, takže nemáte s kým to řešit. SPF a DKIM zajistí „jenom“ identifikaci odesílatele (SPF server, DKIM subjekt – člověka nebo firmu). Nebo-li díky tomu zjistíte, s kým máte ten spam řešit – a pokud nebudete úspěšný, můžete dotyčného blokovat.
Dá se to tedy použít jen proti opakovanému spamu, když spammer bude mít nové a nové počítače v botnetu a nové a nové domény, SPF a DKIM nepomůže. Ale je jistá naděje, že když se tyhle nástroje pro zajišťování důvěryhodnosti e-mailu rozšíří, budou problém muset řešit i ti, kteří se dnes pohybují v šedé zóně (např. ISP nijak neřeší spamující klienty), a pro spammery zůstane jen úzký prostor, který bude snadné eliminovat.
-
BobTheBuilderStříbrný podporovatelTo je nějaký ohavný tvar, doslovný převod z angličtiny. Jestliže se má něco učinit kanonickým, pak se to snad kanonizuje.
-
JD (neregistrovaný)
co delat, kdyz spam chodi z validni domeny vcetne DKIM a SPF? Poslednich nekolik tydnu me chodi takovyto cesky SPAM pravidelne.
MA vzdy stejnou strukturu, kdy emal adresa je nahodne vygenereovane jmeno s propojenym cislem. Napriklad vasil_vavra_13_02.86@shishicaii.com. Domena ve validni, vsechno formalne v poradku, ale patri nejakemu proxy registratoru v Paname. Co me ale nejvice prekvapuje, ze vsechny domeny jsou na adresach 95.140.38.0/24 vctne serveru, ze kterych se to rozesila. Adresy patri nejakemu virtualnimu cloudu v Madarsku a prekvapive nejsou na prakticky zanem blacklistu.
Kazda domena je pouzita pouze jedinkrat, priste to prijde z jine podobne generovane jako lorem ipsum.
Rozesilatel ma evidentne jaky extra laciny pristup na registraci domen, kdyz kazdou pouzeje pouze 1x
Ten spam je jeden jako druhy, az na nahodne chyby na ztizeni detekce. Nadpis, linkovany obrazek a na konci ruzne komolenym "odhlasuji se z nabidky ubytovani"Na serveru jsem blouknul cely rozsah pouzivanych adres, ale riskuji tim, ze tam hostuje i nejaky regulerni zakaznik co posila regulerni postu.
-
Filip JirsákStříbrný podporovatel
Určitě to nahlašte na ÚOOÚ. Když to mají všechno pěkně podepsané, bude snazší dokázat, kdo to doopravdy rozeslal.
-
Filip JirsákStříbrný podporovatel
Vy jste šel po technické stopě. Psal jste, že jde o český spam a nějaké ubytování, předpokládám tedy, že jde o nějaký český subjekt, který z toho chce mít profit. A to je zase stopa, která bude zajímat ÚOOÚ. Ostatně, po vás se nechce, abyste po tom spammerovi pátral, po vás se chce jenom to, abyste spam nahlásil. To, že se ÚOOÚ podaří spammera vypátrat a usvědčit (což není jisté, ale pořád lepší, než nic), je jediné, co může spammera nějak citelně zasáhnout. Pokud toho spammera vypátráte sám a zablokujete na svém serveru, budete z toho mít možná dobrý pocit, ale toho spammera se to nijak nedotkne.
-
mijo (neregistrovaný)
Resim jeden zásadní problem
U domény svého zákazníka mám nastaven spf record, emaily podepisují Dkim a když poslu email ze sveho webserveru na 5 různých emailových adres pod doménou @gmail.com tak vždy skončí ve spamu
Nevím co stím mám dělat,IP serveru ze ktereho se maily odesílají nikdy nebyla na internetu,dokonce IP rotují .....IP nejsou na žádném blacklistu .....když se mrknu do hlaviček z gmailu.....vidím ze google respektuje spf a dkim (spf=pass , dkim=pass) a stejně email zkonci ve spamu....
Kontaktovat google jsem zkoušel ale ti mi nic kloudneho neřekli....
Jestli někdo resite podobný problém nebo víte jak to vyresit prosím o pomoc
Moc díky
Mijo
-
Filip JirsákStříbrný podporovatel
Zkuste poslat jen jeden e-mail, který vytvoříte ručně (s nějakým testovacím textem). Pokud to pošlete na 5 adres najednou a je to nějaký automaticky generovaný e-mail, Google už jenom podle toho ví, že jde o hromadný automatický e-mail.
-
V článku je uveden příklad, kdy se generuje klíč o délce 2048. Tady bych upozornil, že dns servery mívají maximální size limit 255 bytes 255 znaků, víc do jednoho txt záznamu vložit nejde. Proto nezbývá, než generovat klíč o velikosti 1024.
Zdar Max
PS: teď jsem dokončil nasazení SPF, DKIM, ADSP, DMARC na všech našich firemních doménách ... -
Ten, co splňuje rfc1035. Jinak třeba z reálu, dns servery pipni.cz neumožňují delší klíč (nedávno to právě řešila jedna firma, kde jsem nasazoval Kerio Connect, který vygeneroval 2048 klíč a i když webmgmt říkal, že je dns nastaveno, tak nebylo a byl právě problém s neošetřením délky záznamu, aspoň myslím, že to tak nějak bylo, sám jsem to nenastavoval).
Dále, nezkoušel jsem to (teď ho nikde nemám), ale údajně bind by se také tento rfc měl držet, viz :
https://kb.isc.org/article/AA-00356/0/Can-I-have-a-TXT-or-SPF-record-longer-than-255-characters.htmlNeříkám, že je to dobře, nebo špatně, jen říkám, bacha na to, reálné nasazení 2048 klíče může být někdy problém.
Zdar Max
-
Ondřej CaletkaZlatý podporovatel
Díky, o tomhle omezení jsem nevěděl. Nicméně jsem prohledal RFC 1034 a nikde jsem nenašel zmínku o limitu délky TXT RR. Jediný limit 255 znaků je limit délky doménového jména.
V každém případě tohle je daň za to, že si implementátoři zvolili znovupoužití existujícího RR, místo aby zadefinovali RR vlastní, podobně jak to udělalo třeba DANE.
-
Dan (neregistrovaný)
Ano, zmiňované omezení na TXT/SPF záznam je pravdivé (RFC 1035 sekce 3.3). Důvod je prostý, textový řetězec obsahuje na začátku 1bajtovou délku. Nicméně TXT záznam může obsahovat libovolný počet takových textových řetězců (s omezením na celkovou délku dat záznamu 2^16 bajtů).
Většina DNS serverů toto omezení dodržuje, ale například v Knot DNS plánujeme zavést automatické rozsekání delších textových řetězců při vstupu ze zónového souboru. Není to sice dokonalé řešení problému, ale někteří uživatelé po tom volají.
-
Ondřej CaletkaZlatý podporovatel
Aha, tak opravuji. Skutečně RFC 1035 v sekci 3.3 definuje limit jednoho character string záznamu na 256 B s tím, že jeden bajt určuje délku. Ovšem
TXTzáznam obsahuje jeden nebo několik character string a RFC 6376 určuje, že pro DKIM se mají všechny řetězce spojit bez jakékoli mezery. Mělo by tedy stačit do TXT záznamu na některá místa vložit" "pro rozdělení záznamu na víc kratších řětězců. -
Ano,
pomocí multiple string lze takto řešit i delší SPF záznam, ostatně obdobně je to popisováno i v linku, co jsem dával ohledně bindu - rfc4408 z roku 2006.
Osobně jsem ale nezkoušel, jaká je ohledně těchto rfc aktuální podpora (hlavně u reálných nasazení). Osobně jsem tedy k tomu to řešení byl zdrženlivý a raději použil 1024 klíč s tím, že tomu dám ještě rok a pak se uvidí.
Zdar Max -
Antonimous (neregistrovaný)
Panove, sorry, ale tahle cast diskuze mne primo nadzvedla.
Stacilo se podivat na zoubek opendkim-genkey, aby se zjistilo, ze se jedna o perlovy skript, kde se naleza nasledujici kod:
276: $len = length($keydata);
...
281: if ($len < 250)
...
286: else
287: {
288: print $txtout substr($keydata, $cur, 250);
...Jinymi slovy, tento "problem" byl jiz vyresen primo u zdroje.
(facepalm)
Uff...A ted' vazne, uspesne pouzivame klice o delce > 1024 v bindu, powerdns a knotu.
-
Filip JirsákStříbrný podporovatel
Celá ta předchozí diskuse řeší to, jak se to dělá správně podle standardů. Váš komentář řeší jenom to, jak to dělá jeden nástroj - což vypovídá pouze o tom, jak to řeší ten jeden nástroj. Bez té předchozí diskuse by byl váš komentář úplně k ničemu, spolu s ní přidává malý střípeček do mozaiky.
-
Ondřej CaletkaZlatý podporovatel
U mě na Debianu Wheezy s opendkim 2.6.8-4 je
opendkim-genkeyshellový skript, který délku TXT záznamu nijak neřeší.Chcete-li někdo testovat interoperabilitu, právě jsem instaloval 2048bitový klíč na automatické odpovídače serveru nebezi.cz a doesnotwork.eu. Já jsem zatím žádný problém neobjevil a nemyslím si, že by to byl reálný problém, vzhledem k tomu, že způsob nakládání s TXT záznamy je pro DKIM definován od samého počátku a konzistentně s praxí u SPF.
-
Filip JirsákStříbrný podporovatel
DNS je jediný všeobecně používaný protokol, kterým můžete bezpečně (pokud se použije DNSSEC) zjistit údaje o doméně. Navíc velké záznamy mohou být v DNS už teď, takže se to stejně musí řešit nějak obecně.
-
Ondřej CaletkaZlatý podporovatel
Paradoxně v tomhle ohledu jsou hodně velké záznamy lepší než nějaké menší. To proto, že u hodně velkých záznamů se odpověď nevejde do UDP a je nutné použít TCP, které má vestavěnou odolnost proti zfalšovaným zdrojovým adresám. Osobně taky doporučuji nastavovat maximální velikost UDP odpovědi na něco kolem 1300 B místo výchozích 4096 B.
-
Díky za nasměrování. Kdybyste měl po ruce nějaký prověřený zdroj podrobnějších imformací, byl bych za něj rád. Co jsem tak googlil, tak se infromace rozcházejí.
Například Wikipedie o tom říká: "The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers. Some resolver implementations use TCP for all queries."
-
lol (neregistrovaný)
je to tak ako na wikipedii. Podobne to komentuje aj D.J.Bernstein vo svojom djbdns:
When are TCP queries sent?
If you're in one of the following situations, you need to configure your DNS server to answer TCP queries:
1. You want to publish record sets larger than 512 bytes. (This is almost always a mistake.)
2. You want to allow outgoing zone transfers, for example to a third-party server.
3. A parent server refuses to delegate a name to you until you set up TCP service.If you aren't in any of those situations, you have no need to provide TCP service, and you should not set it up. DNS-over-TCP is much slower than DNS-over-UDP and is inherently much more vulnerable to denial-of-service attacks. (This applies to BIND too.)
K tomu sa da doplnit este DNSSEC
-
Ondřej CaletkaZlatý podporovatel
Zrovna názory D. J. B, bych nebral jako bernou minci. Řekl bych, že názory DNS komunity jsou spíše opačné. Ono je taky otázka kdy tohle DJB napsal a jaký byl tehdy průměrný výkon serverů a síťových prvků v porovnání se současností.
Teď se spíš ukazuje, že DNS přes TCP docela dobře funguje (Geoff Huston naměřil rozbitost asi u 2% uživatelů). Samozřejmě, pokud by najednou začali všichni na všechno používat výhradně TCP DNS, nejspíš to položí kořenové a TLD servery. Rozhodně se ale zdá, že použití TCP je pro větší dotazy lepší nápad než EDNS0, které umožňuje odesílat UDP DNS zprávy o velikosti až 4096 B.
-
lol (neregistrovaný)
Tak DJB je velni ortodoxny co sa tyka dodrziavania standardov - vid. jeho letity problem s errno. Pisal to urcite davno, ale pochybujem ze sa jeho nazor na pouzitie TCP u DNS zmenilo. V kazdom pripade naozaj su situacie kedy je TCP vyhodnejsie a DNS servery by mali vediet handlovat oba protokoly.
-
Ondřej CaletkaZlatý podporovatel
Wikipedia bohužel zřejmě nereflektuje rozšíření EDNS0, které systémům umožňuje odsignalizovat si libovolnou maximální délku UDP zpráv (standardně 4096 B)
Tady jsem třeba našel prezentaci o fragmentovaném provozu a DNS:
https://ripe65.ripe.net/archives/video/91/ -
tjjdno (neregistrovaný)
A ne https://tools.ietf.org/html/rfc4398? Zpetna kompatibilita?
-
Ondřej CaletkaZlatý podporovatel
Nejspíše na základě „dobrých zkušeností“ s TXT záznamem pro SPF, zejména s tím, že pro zavedení není potřeba doplňovat pro nový RR podporu v nejrůznějších webových rozhraních pro editaci DNS.
Ovšem když vidím base64 kód v textovém poli, které by bylo schopné klidně přenášet osmibitové znaky, trochu při tom skřípu zubama.
Důležité je, že DKIM je navržen rozšířitelně a může být později doplněn o jiný způsob přenosu klíče. Způsob dns/txt je však dnes jediný definovaný a povinně implementovaný.
-
tjjdno (neregistrovaný)
"pro zavedení není potřeba doplňovat pro nový RR podporu v nejrůznějších webových rozhraních pro editaci DNS"
To je doufam vtip :) Prece kdyz mame specialni typ zaznamu pro certifikaty, ktery umoznuje ulozeni az 64 KB, tak proc to davat do TXT? Neni to opras? Ale nejaky duvod to musi mit, RFC4871 je o vic nez rok starsi nez RFC4398.
-
Ondřej CaletkaZlatý podporovatel
Máme speciální typ záznamu na kde co, to nic netvrdí o tom, jestli se takové záznamy taky používají. Já jsem třeba ještě neviděl nějaké praktické použití záznamu typu CERT neviděl.
Nepodpora v systémech pro správu DNS je poměrně zásadní překážkou. Zkuste obejít české registrátory, kteří nabízejí vedení DNS k doméně a zjistíte, že drtivá většina je značně omezená co se týče možností použití různých typů RR. Je to také zmíněno jako jedna z příčin nepopularity záznamů typu SPF.
-
tjjdno (neregistrovaný)
Pokud jste jeste nevidel prakticke pouziti CERT zaznamu, pak doporucuji podivat se na http://www.directtrust.org/. Pokud mate v USA lekarskou praxi a nejste schopen vystavit svoje S/MIME certifikaty pres CERT RR (a nebo LDAP), pak nemate narok na urcity typ statni podpory, protoze neumite komunikovat elektronicky.
-
vasek (neregistrovaný)
Jen bych doplnil, že s DKIM umí dobře pracovat i Amavis, není potřeba další software.
Nějak mi připadá zbytečné nasazovat najednou jak DKIM, tak SPF. Pokud mail server podepisuje zprávy pomocí DKIM, tak tím pádem je i autorizuje a je jasné, že pocházejí ze známého/pověřeného serveru a lze se tím vyhnout mnoha nevýhodám SPF. Proti SPAMu DKIM ani SPF moc nepomůže (teda na straně gmailu mi kdysi pomohlo, aby zprávy nebral jako spam), dohledatelnost oprávněného zdroje (odesílacího serveru) je s DKIM realizovatelné stejně jako se SPF.
-
j (neregistrovaný)
DKIM nezaridi, ze mailserver mail vubec neprijme. Nejdriv ho musi prijmout, overit podpis a pak jej teprve muze pripadne zahodit, coz znamena, ze uz spotreboval spoustu prostredku a zcela zbytecne.
DKIM resi pouze to, ze uzivatele nejsou schopni/ochotni podepisovat svoje maily. Zaroven se da (hypoteticky) predpokladat, ze uzivatele nejak autorizoval ten, kdo mail podepsal. Ma to smysl u firemnich mailu, protistrana muze predpokladat, ze mail skutecne odeslal majitel domeny (to prozmenu vubec neresi SPF).
V boji proti spamu je SPF radove lepsi nastroj. Naopak, pokud budu chtit MTA DOSnout, poslu na nej hromady mailu z domen, ktery DKIM specifikujou => bude muset kazdej ten mail zvlast prepocitat a bude jich stacit radove min. Pokud mu bude jedno odkud ty maily prisly == nepouzije kuprikladu SPF.
-
Filip JirsákStříbrný podporovatel
S DKIM nezjistíte oprávněnost odesílacího serveru, ale pouze autora zprávy. Oprávněnost odesílacího serveru zjistíte právě přes SPF.
Například někdo může poslat e-mailem článek pár svým známým, o kterých ví, že je to bude zajímat. Google ten e-mail podepíše DKIM podpisem. Já budu jeden z těch známých a usmyslím si, že je to tak důležitá článek, že o něm musí vědět svět, a rozešlu ho na tisíce e-mailů. DKIM na těch e-mailech bude pořád sedět a bude odkazovat na toho původního odesílatele, přitom tím lumpem, který to rozeslal, jsem já. Ono to, že SPF brání chybně udělanému přeposílání, má své důvody.
-
vasek (neregistrovaný)
Jenže to je pořád něco za něco. SPF svaluje jakoukoliv zodpovědnost za doručení a hlavně obsah mailu na server, který to přeposílá. Bez SRS se mail nemusí dostat ke konečnému příjemci, se SRS (pominu-li fakt, že pro SRS neexistují všude distribuční balíčky, což může přinášet bezpečností problémy) může být za případné SPAMování potrestaný přeposílací server.
DKIM zařídí, že email byl původně odeslaný autorizovaným serverem. Co se s ním děje pak už je zodpovědností dalších osob nebo serverů.
Když pak hledám kompromis, tak díky DKIM může protistrana alespoň zjistit, že mail "vzniknul" na serveru, který neslouží pouze jako relay pro spammery.
-
Filip JirsákStříbrný podporovatel
SPF svaluje jakoukoliv zodpovědnost za doručení a hlavně obsah mailu na server, který to přeposílá.
Ani ne tak SPF, jako SMTP. A nejde jen o přeposílání. Prostě mail server nějakým způsobem dostane e-mail, a ten má svým jménem doručit. Pokud se mu to nepodaří, měl by vědět, odkud se u něj ten e-mail vzal, a ideálně stejnou cestou oznámit neúspěch při doručování.DKIM zařídí, že email byl původně odeslaný autorizovaným serverem.
Což je nepochybně užitečná informace, nicméně dnešní problém se spamem není v tom, kde ty e-maily vznikají, ale kdo je rozesílá.Mimochodem tomu, aby někdo (buď server nebo človek) přeposlal email tisícům dalších lidé z principu nezabrání ani SPF, ani DKIM.
Přeposlání nezabrání opravdu nic, ale SPF dokáže ukázat na toho, kdo je za to rozeslání e-mailu zodpovědný. -
vasek (neregistrovaný)
Prostě mail server nějakým způsobem dostane e-mail, a ten má svým jménem doručit
Právě. Pak nastane situace, kdy uživatel toho poštovního serveru nastaví přeposílání na třeba gmail. Pokud můj server nepozná, že nějaké zprávy jsou spamy a přepošle to dám a gmail to pozná, pak za to může být potrestaný můj server - kvůli SPF bude jako odesilatel uvedený účet na mém serveru a ne původní odesilatel zprávy a je pak na konečném serveru, jak se zachová.Což je nepochybně užitečná informace, nicméně dnešní problém se spamem není v tom, kde ty e-maily vznikají, ale kdo je rozesílá.
No i zde může mít odesilatel platný SPF záznam. To je podobný problém jako s blacklisty. Můžu sice efektivně odmítat zprávy od blacklistovaných serverů, ale můžu přijít i o užitečné maily. Už se mi stalo, že nějaký útočník zneužíval účet na mnou spravovaném serveru. Je sice hezké, že si toho po nějaké chvíli člověk všimne a účet zablokuje, ale to se děje v mnohem větším měřítku a ta chvíle mezi nabouráním do účtu a jeho zablokováním poslouží k zaslání mnoha zpráv. -
Filip JirsákStříbrný podporovatel
Pokud můj server nepozná, že nějaké zprávy jsou spamy a přepošle to dám a gmail to pozná, pak za to může být potrestaný můj server - kvůli SPF bude jako odesilatel uvedený účet na mém serveru a ne původní odesilatel zprávy a je pak na konečném serveru, jak se zachová.
SPF v tomhle nehraje moc velkou roli, protože cílový server hlavně zná IP adresu vašeho serveru, takže váš server může potrestat tak jako tak.Nejlepší by bylo, kdyby existovaly standardní a používané hlavičky, do kterých by se zapisovaly údaje o přeposlání. Cílový server (třeba ten GMail) by se pak mohl řídit i tím, od koho ten e-mail k přeposlání dostal. DKIM (nebo i SPF) by pak sloužilo k ověření toho, zda ten záznam o přeposlání vložil někdo důvěryhodný.
No i zde může mít odesilatel platný SPF záznam.
No ale v tom případě jsme vyhráli. Protože přesně víme, na koho si došlápnout - a pokud to nepomůže, máme v DNS pěkně vyjmenované servery, které jsou vážnými adepty na blacklist (samozřejmě to blacklistování je potřeba dělat s rozmyslem, kdyby spamoval můj server a někdo zabanoval všechny servery, které mám uvedené v SPF, zabanuje i GMail). -
lol (neregistrovaný)
pokial viem, tak amavis riesi len overovanie dkim, sam nepodpisuje ked cez neho prechada. Opendkim (po starom sa tusim volal dkim-filter) riesi podpisovanie mailov pre domeny ku ktorym ma key.
Posledny cas pozorujem ze plno MTA sa snazi podpisovat DKIM, v MIME sa odkazuju na selector "default" ale nemaju TXT zaznam default._domainkey.domain. Su to desiatky domen u roznych ISP. Vsetky pouzivaju ten isty selector, ako keby ich konfiguroval jeden a ten isty clovek a uplne sa vyprdol na DNS
-
Filip JirsákStříbrný podporovatel
Nejsou podpisovější, jsou důvěryhodnější. Protože když máte jen tak nějaký podpis, víte o něm akorát to, že byl vytvořen vlastníkem příslušného klíče. To podpisu na důvěryhodnosti moc nepřidá. Zato když máte příslušný certifikát v DNS, ještě lépe podepsaný DNSSEC, podpis je mnohem důvěryhodnější, protože víte, že byl vytvořen se souhlasem vlastníka příslušné domény. Což je u e-mailu docela podstatná informace.
ČLÁNKY DO MAILU