Vlákno názorů k článku DomainKeys - nová antispamová technologie od Ondřej Surý - > Problém číslo 4 je možno řešit ještě...

> Problém číslo 4 je možno řešit ještě tím, že uživatel
> bude odesílat firemní poštu vždy přes firemní SMTP,
> k němuž se připojí pomocí vlan nebo autentizuje přes
> SMTP autentizaci.

Nemyslel jste nahodou VPN misto VLAN? Davalo by to pak vetsi
smysl...

O.

Jo, sakra, samozrejme to ma byt VPN.

Side-efektem [4] je ovsem zavislost odesilani posty na konkretnim odesilacim serveru a funkcnim spojeni k nemu. Zatimco soucasny system "SMTP server poskytuje lokalni ISP" je mnohem odolnejsi proti vypadkum.

Mimochodem, kdyz tak koukam na mnozstvi pokusu vymamit pristup k CMD.EXE na nasem UNIXu, napada me, ze by se to dalo resit analogicky. Kazdy HTTP pozadavek by musel byt "podepsan" a predavan vyhradne prostrednictvim WWW proxy ve firme nebo u materskeho ISP.

Zajimave je, ze zatimco tohle kazdemu pripada jako hloupost na prvni pohled (coz tak eje) - a prakticky kazdy v tomto pripade respektuje, ze spravnym resenim je tlacit na "zdrojoveho ISP" aby si udelal ve sve siti poradek a "nehodneho uzivatele pacifikoval", u emailu se tentyz princip s pochopenim nesetkava a hledaji se specificke cesty. O kterych se navic vi, ze ledacos neresi a navic jsou nekompatibilni s nekterymi bezne pouzivanymi zpusoby uzivani posty. Zrejme za tim bude nejaky silny komercni tlak. Tusim, ze jen co se system objevi, tak nekdo zacne vehementne prodavat "bezpecne MTA" ...

O vyhodach SMTP u ISP jak ohledne autorizace k pouziti tak dostupnosti neni treba diskutovat.

Ohledne te dostupnosti - zas takovy problem to neni a vetsinou dela vetsi problemy nedostupnost inboxu nez nemoznost odeslat postu.

Ten priklad s HTTP je absolutne mimo. Tam neexistuje phishing ani spamy, takze po HTTP proste nepotrebuji urcovat, jestli request opravdu prisel od toho, od koho tvrdi, ze prisel ;-)

O nevyhodach (pripravovane) povinnosti posilat dopis prave timto zpusobem ovsem take ne. A, popravde receno, nenachazim rozumny duvod, proc by nedostupnost stroje A (s inboxem) mela byt castejsim problemem nez nedostupnost stroje B (pres ktery jediny mohu odesilat postu).

Zda je priklad s HTTP mimo nebo nikoliv je nepochybne vec nazoru, a mozne jsou v zasade dva, a to zcela protichudne.

Samozrejme, ze nepotrebuji urcovat, zda pozadavek prisel od toho, kdo o sobe tvrdi, ze od nej prisel - pokud na teto informaci nechci stavet ochranu proti pokusum "zavirovat" a DoS utokum. Ja ale myslim, ze i tam by se mnozstvi utoku omezilo, kdyby si nemohl volne komunikovat kazdy klient s kazdym serverem (navic anonymne), ale kazdy klient byl hezky jednoznacne oznacen a jeho komunikaci zprostredkoval (kontroloval a filtroval) konkretni pro nej urceny stroj. To, ze se technicke detaily konkretnich utoku a jejich nazvy lisi od tech, ktere probihaji na SMTP nic nemeni na tom, ze ucinna metoda obrany je stejna ...

Nevim nic o tom, ze by DomainKeys nekoho nutili posilat dopisy tim zpusobem - pokud se za nej "zaruci" ISP.

Ad nedostupnost - minil jsem tim, ze nedostupnost INBOXu je pro mne vetsinou o dost vetsi problem, nez nemoznost posilat maily.

Ad HTTP: Az bude traffic cervu zabirat vetsinu kapacity site/serveru, pak pravdepodobne bude nutne jej resit takto drasticky. Nicmene v soucasne dobe je to naprosto minoritni problem a PROTO vypada to reseni nesmyslne.

Proti spamu se nebojuje proto, ze by par zlych lidi vymyslelo "jakou provedeme jeste spatnost" a doslo k tomu "hele, spammeri si posilaji maily, to se jim musi zatrhnout". Proti spamu se bojuje proto, ze stoji ohromne naklady v sitovem provozu, vykonu pocitacu pro jeho zpracovani a ztracenem casu lidi / ztracenych prilezitostech (u false positives). Protoze uz zacina ohrozovat pouzitelnost mailu tak, jak ho zname ted.

> To, ze se technicke detaily konkretnich utoku a jejich
> nazvy lisi od tech, ktere probihaji na SMTP nic nemeni na
> tom, ze ucinna metoda obrany je stejna ...

A jaka?

Opustit princip "pustim do site kazdeho, kdo mi zaplati" - problemy, ktere dotycny zpusobi at si resi ten, komu je pusobi - me zadne nepusobi, me prece vcast a radne plati ...

Podruhé upozrňuju, že DomainKeys nevyžadují prohánět poštu konkrétním MTA. Klíče může mít MUA a řešení 4. tak není vyžadováno. (Narozdíl od jiných podobných návrhů.)

Jak uz tu ale take padlo, "klice" maji zase jiny problem. Bud' budou snadno a lacino dostupne - a pak nebude jejich potreba SPAMmerovi velkou prekazkou. Nebo snadno dostupne nebudou - a pak bude jejich potreba vaznou prekazkou pro nektere dosud bezne uzivatele. Samozrejme, za predpokladu, ze se technologie DomainKeys stane de-facto povinnou. Jenze, pokud se povinnou nestane - pak zase bude mit jen mizivy antispamovy efekt.

V soukromem dopisu jsi napsal, ze motorem teto technologie je patrne spise snaha zabranit "kradezi zdrojovych adres" nez snaha "omezit SPAM". V tom svetle cely ten navrh vypada hned daleko pochopitelneji. Pak ale DomainKeys nejsou novou antispamovou technologii - i kdyz to Lupa nakrasne pise do nadpisu. Pak jsou predevsim metodou jak zabranit "kradeni adres". Jenze, mam dojem, ze tohle zase daleko lepe resi elektronicky podpis.

Nemuzu se zbavit intenzivnoho dojmu, ze DomainKeys vznikla v umyslu vyresit neco, co uz reseno je - a lepe. A jelikoz to v prubehu casu asi zjistil i nekdo dalsi, vznikaji snahy zduvodnit jeji vznik i necim jinym - treba ochranou proti SPAMu. Jenze, na to ta technologie prilis dobra neni. Takze si opravdu nejsem jisty, zdali skutecne nejsme svedky pokusu o "vytvoreni poptavky". Mozna nekomu lezi v zaludku, ze el. podpis nema patentovany a nemuze na nej prodavat licence. Mozna je motivace uplne jina.

Mozna jsem to, co nabizi DomainKeys prostudoval nedostatecne. Ale zatim opravdu nemohu prijit na to, ktery nevyreseny problem se tato technologie pokousi resit. Krome SPAMu - a ten neresi nijak zvlast dobre ...

Asi takhle. Idealni anispamova technologie prenasi "elegantne" naklady za posilani spamu na spammera a pritom legitimni odesilatele mailu ovlivnuje jen velmi malo. Jenze takovou neznam.

Ano, DomainKeys nejsou "idealni" technologii ve smyslu ze by dokazala prenest naklady na spammera. Dokaze vsak IMHO zlepsit detekci spamu tim, ze omezi moznost false positives (ktera jsou radove horsi nez false negatives) u mailu z domen, ktere se chovaji "slusne".

Ad nadpis: Ten je dilem redakce :-) Ja jsem dodal clanek bez nadpisu a v nem pisu o obou efektech.

Ad el. podpis: Ne, (osobni) elektronicky podpis to neresi daleko lepe. Dukazem je fakt, ze se proste nepouziva. Jak uz jsem psal vyse, jeho chyba neni v technickem (kryptografickem) provedeni, ale v prilis velkych nakladech na jeho zavedeni, ktere se lidem proste nevyplati, zvlast pri jeho male rozsirenosti. O DomainKeys jsem napsal clanek prave proto, ze podle meho nazoru ma sanci na rozsireni, jelikoz naklady na jeji implementaci jsou zlomkem nakladu na (osobni) elektronicky podpis.

Ad vas navrh: To je na hodne obsahlou diskusi, zkusim byt strucny:

Kratce receno, vylevate s vanickou i dite. Pokud to budete uplatnovat "mekce", tak se to da lehce obejit, pokud tvrde, tak zcela znicite to, cim je internet dnes. A pritom spam stejne moc neomezite (spammeri mohou pouzivat bile kone, vyhackovane pocitace, nebo si zalozit vlastni ISP).

Dal mam za to, ze odpovednost se musi prenaset na puvodce problemu. Prenaset ho na ISP je nesmysl. Bylo by to zcela proti zvyklostem v obdobnych pripadech (posta, telefony, WWW hosting, ...).

Dale je otazka, jak tu odpovednost prenest. Pokud ji prenesete ze zakona, tak to jednak bude dosti problematicke z pravniho hlediska (viz predchozi odstavec) a jednak to neni sance prosadit celosvetove.

Pokud to prenesete "de facto", tak postavite ISP do situace, kdy budou zodpovedni za chovani zakaznika, ktere ale nemohou pravne nijak ovlivnit. Muze to vest maximalne ke smlouvam "muzeme vas vypovedet kdykoli udelate neco, co se nam nebude libit" a tvrdemu lustrovani zajemcu o pripojeni. To uz tedy radsi spam, nez takoveto podminky.

(P.S.: A ten zakaz odesilan posty lze resit podstatne elegantneji firewallem nez nejakym "znackovanim" zakazniku, kteri nemohou posilat postu pres DNS.)

To, ze nadpis je dilem redace, az ze nadpis spolecne s perexem (ktery je take dilem redakce) na Lupe nikoli vyjimecne poskozuji vyzneni celeho clanku je uz snad znamo vseobecne ...

Co se druheho odstavce tyce - ano, to je presne to, co ja te technologii vycitam. Jednou vetou by se skutecne dalo rict, ze DomainKeys se snazi dosahnout "hlavne abyste za SPAM nepovazovali dopisy, ktere maji ve FROM moji domenu". To je ale dost nezajimavy problem. Podivejte, soucasny email proste jakoukoliv autenticitu FROM adresy nezarucuje. Kdyby se tohle pokousely DomainKeys resit, pak dobra. Ale pokud spravne chapu DomainKeys, tak ani ty se ji nepokousi na urovni jednotlivych uzivatelu zajistit (ano, je mozne, ze to odesilaci MTA udela, ale neni to povinne a z pohledu prijemce tedy jiste) - ty se snazi zajistit jen to, ze dopis "odesel z nejake domeny", nikoli "od nejakeho uzivatele". Takze DomainKeys opravdu resi shora uvedeny velmi uzce izolovany problem. No, a troufam si trochu odvazne tvrdit, ze jeho reseni mozna pali par spolecnosti, ale minimum beznych koncovych prijemcu emailu ...

No a prave proto, aby se prekonal tento "nezajem" o "skvelou technologii", je "SPAM" pomerne umele zduvodneni, ktere ma zajistit, ze vec zacne zajimat prave je. V tom, ze DomainKeys nejsou nastroj na boj proti SPAMu (i kdyz pokud budou zavedeny budou mit URCITY dopad i v teto oblasti) se, mam ten dojem, shodneme.

MOzna jen doslo k nedorozumeni - ja nejsem proti nove technologii jako takove. Ja jen upozornuji, ze nei az tak vhodna pro to, pro co jest vam predkladano, ze vhodna je, a soucasne upozornuji na to, ze zajem na zavedeni teto technologie ve skutecnosti patrne nemate az takovy, jak se vam snazi vnutit. Jinymi slovy, ze tu do jiste miry dochazi k urcite manipulaci za ucelem prosazeni zajmu relativne male skupiny zajemcu - mensi nez se na prvni pohled zda.

To, ze se k zajisteni autenticity nepouziva elektronicky podpis neni nutne dukaz toho, ze by to, co je treba zajistit nezajistil daleko lepe nez DomainKeys. To muze byt stejne dobre dukaz prave toho, ze vetsinovy uzivatel na zajisteni takove autenticity skutecne proste zajem nema. Mozna jsem neco prehledl a rad si necham poradit - ale reknete mi, v co DomainKeys zajistuji lepe nez prosty podpis odesilaneho dopisu ? Hlavni vada EP je, ze uzivani nelze koncovemu uzivateli vnutit, pokud sam nechce. A praxe ukazuje, ze on prilis nechce. A tim se vracime k memu puvodnimu podezreni - hlavni cil DomainKeys je zameren na oblast, kde masove kraluje techologie, ktera neni nikym patentovana a software, ktery je zcela zdarma - a zni "najit zpusob jak v teto oblasti zacit alespon neco prodavat". EP tento cil samozrejme splnit nemuze - protoze uzivatele si mohou prilis vybirat - jak v tom smyslu, ze si mohou prilis vybrat od koho si klic poridi, tak to, ze so vubec mohou vybrat zda si ho vubec poridi.

Uz jen kratce k te odpovednosti ISP. Nekdo koncoveho uzivatele, ktery pak dela bordel a obtezuje ostatni, do site pustil. Nevim, co je nepatricneho zadat po onom dotycnem, aby zajisti, ze ti, ktere do site pousti (a bere za to od nich penize) budou dodrzovat nejaka pravidla. Mozna je nedorozumeni v tom, ze ja nepzoaduji, aby ISP zajisti, ze jim pripojena osoba neporusi zakon, nebo nebude obtezovat nekoho *poprve*. Ale myslim, ze jakmile to dotycny dela opakovane a dany ISP mu i nadale pripojeni k siti umoznuje, s tim, ze dotycny preci plati a jeho zajimaji jedine penize, pak je za takove jednani moralne spoluodpovedny. Vim, ze analogie jsou vzdy nepresne a diskutabilni, ale pokud ja jako nozir prodam nekomu nuz a on jeste v tom krame pred myma ocima tim nozem nekoho zapiche, tak za to odpovedny nejsem. Az toho cloveka pusti a on ke me znovu prijde koupit nuz, ja mu ho prodam - a on obratem znovu nekoho zapichne, pak, s urcitou mirou tolerance, stale odpovedny nejsem. Ale az si po propusteni prijde ten nuz koupit potreti - a ja mu ho prodam - pak za tu treti mrtvolu uz odpovedny, tim myslim moralne, v kazdem pripade jsem.

P.S. Podcenujete me - samozrejme, ze vim, ze firewall by, problem resil stejne. Jenze firewall je reseni mozne jen teoreticky. Zeptejte se nektereho vetsiho ISP, co udela s vykonem jeho hranicniho routeru nekolik set firewallovych pravidel. Ne vsechno, co lze jako reseni vymyslet na papire, je se soucasnou technologii zvladnutelne i v praxi...

Ale to "hlavne abyste za SPAM nepovazovali dopisy, ktere maji ve FROM moji domenu" vidim prave jako nejvetsi motivaci, ktera by mohla vest k prosazeni DomainKeys. U el. podpisu per uzivatel je problem v tom, ze sice kazdy by byl rad, aby prichozi posta mela overene odesilatele, ale ze jeho (deslana) posta je neoverena ho zas tak moc nepali. Proto lide nemaji motivaci podepisovat dopisy a neni co overovat na prijmu. Naopak motivace "venuji 10 minut konfiguraci a moje maily nebudu [pri mem dobrem chovani] povazovany za spam" muze spoustu firem motivoat k pouzivani.

Jinak v tom pripade nic co bylo kdy prezentovano neni nastrojem na boj proti spamu ;-)

DomainKeys nejsou technologicky/kryptograficky lepsi, nez osobni el. podpis, to jsem nikdy netvrdil. Ale jsou jednodussi a daji se zavest radove levneji. A vo tom to je.

Mam jeden priklad z praxe. V lete jsem objednaval pujceni lodi pres internet. Firma mi poslala platebni udaje pres internet. Lec ten mail byl (Bayesovskym) mail filterem vyhodnocen jako spam a ja si toho nevsiml. Nastesti upominka jiz prosla, takze se vsechno nakonec vyresilo... Ale stejne z toho mohl byt neprijemnosti.

Troufam si tvrdit, ze kdyby fungoval system (treba) DomainKeys, ze by odesilajici domena mela dobre hodnoceni a mail by s nejvetsi pravdepodobnosti jako spam vyhodnocen nebyl.

A jinak, kdyz tady porad tvrdite, ze DomainKeys prosazuje nejaka lobby - precetl jste si podminky DomainKeys? Zjistil jste, ze/jak je Yahoo muze zneuzit? Mne se to nezda prave proto, ze narozdil od inciativy Microsoftu maji DK podstatne benevolentnejsi podminky a jejich "zneuziti" Yahoo je takrka vyloucene.

P.S.: To ze jste paranoidni neznamena, ze po vas nejdou ;-)

Jenze prave o to jde - ta "firma" to dokaze uz dnes. Ta rozda svym zamestnancum klice (at uz koupene nebo vystavene vlastni CA), naridi jim je pri komunikaci z firemni domeny pouzivat - a ma hotovo. V cem je to jednodussi nebo lacinejsi nez zavedeni DK mi ponekud unika.

Co se vaseho pripadu tyce, kdyby byl onen dopis podepsany a dotycny mel dobrou povest (proc bych mel posuzovat povest jednotlivce na zaklade udaju o jinych, jemu naprosto cizich lidech - a i pokud vam takove "kolektivni posuzovani" pripada rozumne, muzete posuzovat povest cele CA, ktera jeho podpis vydala) pak by nebyl nejmensi problem zaridit aby filtr dopis propustil take ...

Ja netvrdim s jistotou, ze DK prosazuje nejaka lobby. Jen s ohledem na jeho vlastnosti tvrdim, ze nejpravdepodobnejsi vysvetleni smyslu jeho existence je "komercni zajem". Protoze ze vsech cilu, ktere me napadaji, tento jediny cil resi bez vetsich problemu a zadrhelu. A ten nemusi byt jen primy - v tomto pripade by take mohlo jit o "natruc aktivitu" snazici se vyvazit aktivity Microsoftu.

No, v neposledni rade se skutecne mohou pokouset resit nejaky realny problem - jako treba kradeni adres. Pak je ale skoda, ze je ten navrh takovy trochu "nedodelany". Nebo vam snad pripada, ze dopravat takhle sirokou propagaci systemu, ve kterem spatne funguji konference a prakticky vubec nelze dopis auto-forwardovat je "bezne" a v prumeru k tomu, jak se typicky rozsiruji "nove veci" na Internetu "normalni" ?

No jednoduse... Urcite chapete rozdil mezi spravou jednoho pocitace a tisice pocitacu. Stejne tak je radove jednodussi zaridit podpisovani na centralnim SMTP serveru, nez to resit v MUA kazdeho uzivatele. Proste pokud je podpora DomainKeys v smtp serveru, tak je zavedeni podepisovani pro firmu o tisici zamestnancich zalezitost na 10 minut a pak to bezi a nemusi se na to sahat.

U osobnich klicu je to pracny, dlouhy a drahy proces. A navic se clovek musi neustale starat o vydavani a pridelovani novych klicu a take ruseni klicu starych zamestnancu [a co kdyz si ten klic zamestnanec odnese s sebou? To lze resit jen CRL a to je dalsi komplikace.]

Jeste k tomu domenove versus osobni klice - myslim, ze rozil mezi nimi v praxi neni zas tak podstatny, jak by se mohlo na prvni pohled zdat. Kdyz mi totiz napise nekdo z (treba) banky nejakou "divnou" zadost, tak je jedno, jestli vim, ze to byl "nekdo" z te banky nebo konkretni osoba. Stejne vetsinou nevim, zda dotycny ma pravo takove veci posilat, a musim celou vec proverit osobne.

Ad motivace: Souhlasim, reakce na MS mohla byt jednou z hybnych sil tohoto navrhu.

Ad problemy: Jezuskote, cetl jste vubec ten clanek? Prave DomainKeys maji pomerne slusnou (zvlast oproti jinym navrhum) kompatibilitu se soucasnou architekturou. Mail listy chodi zcela bez problemu dokud nemeni From nebo Subject. Pokud uz do dopisu hrabou, pak musi novou verzi dopisu podepsat - tedy prevzit za jeho obsah zodopovednost (coz je logicke). Forwardery totez v blede modrem. Ale tohle je principielni vlastnost el. podpisu.

To je prave ten problem - DomainKeys se to pokousi resit centralne v MUA kazdeho uzivatele - ktery o to nestoji. A pokdu jste firma - pak nejakou formu pece a konfigurace pocitacu svych zamestnancu uz davno mate. Obzvlast mate-li zminenych 1000 zamestnancu ...

Domain keys tedy "lepe" resi neco, co uz "lepe" vyresene je. Tedy, v pripade firem. V ostatnich pripadech resi "jak centralne indivudualnim uzivatelum natlacit neco, co by si mohli zajistit i sami, jenze to nechteji - coz je problem, ktery DK resi 'lepe'". Nicmene, je zrejme, ze v tom se asi neshodneme.

Zatimco ja jsem v podezreni, ze nevim presne, co je DK a jak funguje, v opacnem smeru vas zase podezrivam z toho, ze vy nevite jak funguje el. podpis. Nevim, co je na tom pracneho, dlouheho - a dokonce draheho. Neni jasne, jaky je rozdil v zapisu, oprave, vyjmuti zapisu do/z jedne databaze (DK) a zapisu do jine databaze (vydanych klicu - pricemz CRL je jen podepsany seznam klicu zrusenych - jinak zadna zvlastni veda). Takze se, zrejme, neshodneme ani v tehle komplikacich - ja je, tak nejak, nevidim.

Jak jsem ale vyrozumel, vlastne mi rikate, ze mezi DK a EP neni vlastne velkeho rozdilu - jen DK je administrativne jednodussi. Musim rict, ze me obvykle neni sympaticke presouvani jakychkoliv pravomoci na "centrum" tam, kde ho muze snadno a jednoduse vykonavat jednotlivec osobne. Jelikoz ja nesouhlaism s argumentem o "administrativni jednoduchosti", zbyva mi, u jinak rovnocennych metod, vyse zmineny zapor - jako jediny zapor. Asi jsem opravdu prilsi paranoidni. Neverim nejakym "centrum", kdyz tvrdi, ze musi pecovat o me blaho a ze to delaji z lasky ke me ...

Ale to je problem, ktery uz diskusi nevyresime ...

DomainKeys to snad řeší na úrovni MTA a ne MUA?

Mě to připadá jen jako alternativa k SPF.
SPF: podle MAIL-FROM (RFC2821) je v DNS v TXT záznamu uvedeno, z kterého stroje smí mail přijít.
DK: podle Sender nebo From (RFC2822) je v DNS je v TXT záznamu veřejný klíč k podpisu mailu
Sender-ID: nevím, ještě jsem neprostudoval

Viz
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-01.txt
http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-mailfrom-00.txt
a třeba i
http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt
nebo
http://www.ietf.org/internet-drafts/draft-lorenzen-marid-mxout-00.txt
a řada dalších pokusů....

Ano, resi to na urovni MTA, ale je MOZNE to resit i na urovni MUA.

Dane, ten rozdil mezi osobnim elektronickym podpisem je asi takovy. V pripade DomainKeys investujete 100 korun a mate podpis na roky. V pripade osobniho podpisu musite zaplatit 100 tisic a kazdy dalsi rok 10 tisic.

Mozna jsem ten pomer prehnal, ale pro ilustraci je to snad jasne. Zavedeni DomainKeys je mozne i pri male motivaci, zatimco osobni podpis se vyplati jen pri opravdu velke motivaci.

Ano, ve firmach je samozrejme pece o pocitace uzivatelu. Jde o to, ze timto jim pridelavate dalsi praci navic, kterou budete muset zaplatit. A proc byste to delal, kdyz vam to vpodstate nic neprinasi? A to nemluvim o nakladech na zmenu internich predpisu a postupu, pripadne skoleni atp.

> Jak centralne indivudualnim uzivatelum natlacit neco, co
> by si mohli zajistit i sami, jenze to nechteji

Nechteji = nevedi o tom, nerozumi tomu, prilis je to nezajima. Nikoli (v 99.9% pripadu) odmitaji.

> vas zase podezrivam z toho, ze vy nevite jak funguje el.
> podpis

V tom pripade doporucuji precist si muj serial o OpenSSL na Rootu ;-)

> Neni jasne, jaky je rozdil v zapisu, oprave, vyjmuti
> zapisu do/z jedne databaze (DK) a zapisu do jine databaze
> (vydanych klicu)

Asi jako slozit do sklepa kilo uhli nebo tunu uhli ;-) U toho osobniho podpisu nejde o nejake principielni otazky. Jde jen o to, ze to musi "nekdo" delat a toho nekoho musite platit. Zatimco DomainKeys nastavite jednou a pak na to vpodstate nemusite sahat.

> Musim rict, ze me obvykle neni sympaticke presouvani
> jakychkoliv pravomoci na "centrum" tam, kde ho muze snadno
> a jednoduse vykonavat jednotlivec osobne.

Kdyby to mohl snadno a jednoduse vykonavat jednotlivec osobne, nejspis by se to uz pouzivalo. Problem je, ze prumerny uzivatel problematice nerozumi a potrebuje nekoho, aby mu to minimalne nastavil.

Dane, ten rozdil mezi osobnim elektronickym podpisem je asi takovy. V pripade DomainKeys investujete 100 korun a mate podpis na roky. V pripade osobniho podpisu musite zaplatit 100 tisic a kazdy dalsi rok 10 tisic.

Co prosim ? Tak to si tedy reknete. Ja vam vystavim podpis podle PKCS za 80Kc a dobu platnosti muzete mit treba stovku let. Nehodlam se tim zivit, takze vam jich udelam nejvys pet. Pak vam zdarma predam klic CA co je vystavila, kterou specialne pro tento ucel vytvorim. A vy sam si dalsi klice dokazete vystavit zadarmo, pouze za cenu lidske prace. Rozdil mezi touto cenou a vami uvadenou "beznou cenou za klic a rok" budeme povazovat za dar. Darovaci dan platite vy. Domluveno ?

Jednomu z nas tady z problematiky PKI neco zasadniho unika. Bez ohledu na pocet clanku napsanych na WWW nebo kdekoliv jinde. (Ja zase absolvoval prednasku z bezpecnosti a mam z toho i zkousku. Tak se snad nebudeme predhanet v tom, kdo ma vic cervenych prukazek.) Odkud porad berete ta desiva a dost nerealna cisla ? Pak se nedivim, ze vam vychazi tak obrovske rozdily v motivaci. Ale do jiste miry prekvapujete vlastne jen sam sebe, protoze ty ohromne rozdily jste si nejprve umele vytvoril vy sam ...

Stale nechapu ani to, odkud berete predstavu, ze v systemu DK udelate neco jednou a navzdy, zatimco PKI vyzaduje nejakou neustalou pozornost. Vy snad budete propoustet pres svuj MTA jakykoliv dopis, ktery se pres nej kdokoliv pokusi prenest ? A k cemu by pak DK v tom pripade bylo ? Nebo budete mit nejakou databazi "opravnenych" a propoustet budete jen jejich maily ? A pokud ano, nebudete muset snad do te databaze nove uzivatele pridavat a po ukonceni vztahu je zase rusit ? A pokud ano, jaky je rozdil mezi touto peci, kterou nazyvate "jednou nastavim a dost" a peci, kdy zavadite noveho klienta (tim, ze mu vyrobite 100 let platny klic) a rusite klienta (tim, ze seriove cislo toho klice pridate do seznamu neplatnych) v systemu PKI - coz nazyvate "potrebou neustale pece" ? Me pripada, ze pocet ukonu je v obou pripadech stejny. Jeden pri prichodu, jeden pri odchodu klienta. Zrejme me nebo vam mi cosi zasadniho unika.

Jestlize ma byt system DK k necemu dobry, tak se ti, kteri pres vase MTA budou muset, zrejme, autentizovat. Nebudete, nahodou, muset vsem svym uzivatelum vyrobit navod jak nastavit MUA aby se autentizoval ? Jestli sve uzivatele naucite navodem nastavovat autentizaci, nebo je naucite naimportovat zaslany blok dat je, co do obtiznosti totez.

Jedinec bude muset, tak jako tak, v souvislosti se zavedenim tohoto systemu, cosi delat. Jestlize to je ta prekazka, ktera brani pouzivani PKI, pak se, ze stejneho duvodu, neprosadi DK ...

Na druhou stranu, pokud to spravne chapu, velkymi "tlacici" DomainKeys jsou provozovatele webmailu - a ti maji nastaveni "MUA" sveho klienta plne pod kontrolou. Ten nedela zminene a pro klienta udajne obtizne prenastaveni problem vubec zadny. At na to koukam zleva nebo zprava, ty technologie jsou schopny byt, co se tyce koncovych uzivatelu i funkci, dost identicke. Zasadni rozdil je opravdu v te centralizovanosti - a tim nemyslim jen to, ze u DK si jedinec s konkretni emailovou adresou nemuze vybrat, zda technologii pouzivat bude ci nikoliv. Zejmena je rozdil v tom, ze vsichni musi odesilat postu pres misto, ktere je pod plnou kontrolou a dohledem toho centralniho nekoho. Kvuli jednomu z techto rozdilu se nepouzije hotova celkem funkcni technologie, ale vytvari se zcela nova, kterou navic bude potreba prosadit. No, klidne mi rikejte paranoik - ja vim, ze jim jsem, a jsem v tom dobry. Mam to uz leta v pracovni naplni a zivi me to ...

> A vy sam si dalsi klice dokazete vystavit zadarmo,
> pouze za cenu lidske prace

Prave jste roztomilou, protirecici si vetou poukazal na zasadni rozdil mezi nasimi uvahami. Ja stavim na tom, ze prace NENI zadarmo. Mozna u domaciho uzivatele, ktery si to dela pro sebe (pokud na to ovsem ma znalosti), ale ve firme rozhodne ne.

Naklady (pocitam se scenarem "firma"):

1) Zavadeni:
DK: Vygenerovat klic, nakonfigurovat MTA, nakonfigurovat DNS.
PKI: Vygenerovat CA klic. (Vystavit CA klic.) Zajistit, aby vsichni MUA ve firme pouzivani ho umeli pouzivat. Udelat navody,

2) Novy zamestnanec:
DK: 0,-
PKI: Vygenerovat novy klic a nakonfigurovat MUA aby ho pouzival.

3) Odchazejici zamestnanec:
DK: 0,-
PKI: Revokovat klic.

Dale ma PKI diky vice instalacim i vetsi sanci, ze se "neco podela" a budou tam dalsi naklady. U centralizovaneho reseni je ta sance naopak minimalizovana.

Autorizace: Jenze ta uz je davno hotova a funkcni (byt na urovni IP, ale to pro DK neni rozhodujici). (Skoro) nikdo uz nedovoluje posilat maily komukoli, ale pouze opravnenym uzivatelum => nakladu na DK jsou 0.

Jediny rozumny argument je ten, ze webmaily maji MUA pod kontrolou a mohly by automaticaci stlacit provozni naklady PKI. To beru.

> Kvuli jednomu z techto rozdilu se nepouzije hotova celkem
> funkcni technologie, ale vytvari se zcela nova, kterou
> navic bude potreba prosadit.

Myslite formalne nebo realne prosadit? Pokud jde o to realne, tak PKI rozhodne realne (ve smyslu hromadne) prosazena neni.

A stejne byste u PKI potreboval nejaky standard na vystavovani certifikatu CA (treba pres DNS), aby to vsechno nemuselo jit pres par "obecne duveryhodnych" CA.

> Proste pro to nevidim dostatecny duvod [pro podepisovani
> sve posty]

A chtel byste, aby posta od jinych lidi byla el. podepsana?

Kdyby to mohl snadno a jednoduse vykonavat jednotlivec osobne, nejspis by se to uz pouzivalo.

Nestaci, ze vec je snadno a jednoduse dostupna. Nutnou podminkou stale musi byt, ze dotycny o takovou sluzbu vubec stoji. Ujistuji vas, ze je plne v mych moznostech veskerou postu, kterou odesilam, podepisovat. Nedela mi problem ani nastaveni MUA a ni ziskani klice - at uz zakoupenim u komercni CA, nebo tim, ze si CA a klic vytvorim sam. Presto svou soucasnou korespondenci nepodepisuji. Proste pro to nevidim dostatecny duvod. Ani pri sve profesionalni paranoie. S ohledem na zisky, ktere to prinasi, je mi vic lito tech par byte prenasenych (a u prijemce skladovanych) navic, zcela zbytecne ...

Jen pro uplnost, pracoval jsem ale take dost let ve financi instituci (i tam na pozici "paranoika") - a tam, kdyz uz je potreba zajistit "jistotu" v odesilateli (a ani tam to zdaleka neni potreba vzdy), pak ta jistota musi byt naprosto osobni - "sdilene" jistoty nikdy nefunguji dobre.

"Příklad z praxe" je ovšem tautologie. DomainKeys neřeší hodnocení reputace. Nejspíš byste použil nějaký blacklist naprosto obdobný ip blacklistům. Že by doména měla dobré hodnocení je čístě přeformulace odhadu, že domain-keys ověřená doména odesílatele bude velmi spolehlivý znak pro filtrování.

Také je naopak možné, že majitel firmy měsíc před komunikací s vámi rozeslal 20 spamů, ale některého adresáta to naštvalo a doménu přidal do všech blacklistů, do kterých mohl. Nebo je možné že červ rozeslal z té domény 100000 spamů. Nebo firma nemá vlastní doménu a sdílí freemailovou doménou s řadou odesílatelů scamu.

Stručně řečeno, není jasné, proč by reputace domén měla být výrazně líp hodnotitelná než reputace ip adres. Ostatne "spamovitost" je vlastnost trojice odesilatel-prijmce-zprava, reputacni hodnoceni zalozene jen na odesilateli ma nejakou horni mez presnosti.

Btw já jsem se tak asi před rokem také domníval, že omezení typu domainkeys může dobře fungovat proti poště z cracknutých počítačů (http://www.lupa.cz/clanek.php3?show=3142). Dneska už si to nemyslím, pravděpodobnějším vývojem je eskalace protiopatreni. Spmaeri proste budou vyuzivat nechranene domeny a registrovat nove domeny.

reputacni hodnoceni zalozene jen na odesilateli

Reputacni hodnoceni zalozene jen na domene odesilatele ...

DK zajistuji, pokud to spravne chapu, ze postu MTA predal skutecne nejaky regulerni uzivatel domeny. Nikoli, ze to byl ten uzivatel, jehoz adresa je uvedena ve FROM. V zasade je tak garantovano, ze "driztel domeny" nema nic proti tomu, aby konrektni uzivatel uzil prave tuto konkretni emailovou adresu (ale neni garantovano, ze je jeho a nepatri nekomu jinemu). Nebo jsem neco prehledl (coz se stat klidne mohlo) ?

Ano, na doméně odesílatele. Výrok platí obecně, tím že v DK ještě ignoruju část informace se přesnost nemůže zvýšit.

DomainKeys je elektronický podpis, na úrovni domény, s distribucí klíčů řešenou pomocí DNS.

Výhodou oproti stávajícím standardům podpisu je nízká cena klíčů (zdarma k registraci domény) s rostoucím počtem adres v doméně jdoucí k nule. Vzhledem k zanedbatelným transakčním nákadům se samozřejmě uplatní tvoje námitka, že když je to levné, tak to spamery nerozhází.

Probémem současných podpisů je, že PKI podle X.509 je šité pro úplně jiné aplikace a proto je to ohromný drahý moloch, a PGP síť důvěry kradení adres nijak explicitně neřeší (aneb nic mi nebrání přidat na keyservery klíč například pro neexistující adresu jk@obluda.cz nebo dokonce pro nějakou cizí existující adresu).

--

Hlavním přínosem v oblasti antispamu může být omezení joejobů a nedoručenek za spamy/viry, kde někdo podvrhnul mojí doménu. Nedoručenky jsou spamový problém, je to nežádoucí pošta, bohužel generovaná slušnými odesílateli, což z principu vadí filtračním metodám, které nějak postihují odesílatele nežádoucí pošty.

No, PKI je jednak definice nejakych matematickych funkci a operaci, jednak definice formatu dat. PKI NENI definice podminek, za kterych smi byt vystaven nejaky konkretni certifikat. Pri pohledu na algoritmy a formaty dat u DomainKeys neziskavam dojem, ze by spocteni matematickych funkci a vytvoreni balicku vyslednych dat v pozadovanem formatu melo byt v pripade PKI nejak vyrazne narocnejsi a tedy drazsi nez v pripade DK. Mluvme tedy o tom, ze nektere existujici CA si za cil vybrali trochu jinou oblast nasazeni el. podpisu, nez by se nam aktualne hodilo. Jejich "policy" neni pro nase ucely optimalni a vystavovani certifikatu podle teto policy je drahe. Nebylo by tedy nejednodussim resenim aby si zajemce o to, co DomainKeys zajistuji vytvoril vlastni CA, s adekvatnejsi policy, a svym zakaznikum proste, jednoduse a lacino vystavoval klice vhodne prave k tomu ucelu, ktery sleduje on ? Vytvorit CA samu o sobe neni nijak zvlast drahe. Cena stoupa az s dalsimi pozadavky, ktere ma takova CA splnit - a v tomhle pripade pozaduji splnit velmi malo - klic vystavuji kazdemu, komu jsme ve sve domene zridil schranku. Softwarove celkem trivialni a logisticky (vzdyt uz jsem s tim clovekem v kontaktu, kvuli vytvoreni te schrany) take. Problem je, zrejme, v tom, ze uzivatele nelze donutit, aby technologii pouzival. A zkusenost ukazuje, ze on o takovou ochranu typicky nijak zvlast nestoji. DK se mi tedy stale jevi predevsim jako zpusob jak uzivateli vnutit neco, co mohl mit i bez toho, ale nestal o to. A to je dost zvlastni motivace, tedy, pokud samozrejme nejde o kseft, kde jsou podobne metody naprosto bezne ...

A co se tyce chybovych hlaseni ("nedorucenek") a jejich negativniho vlivu na filtry - chybove hlaseni se preci rozezna naprosto snadno a spolehlive, podle MAIL FROM: <> hlavicky v SMTP. Jak muze neco takoveho vadit nejakemu filtru ? Ten preci vi, nebo prinejmensim snadno muze vedet, ze prave zpracovava chybove hlaseni. Nicmene, i kdyby ne. Jak v tomto pripade pomuze DomainKeys ? Presneji receno - na cilovy MTA dojde hlaseni, jehoz DK signatura "nesedi". Z toho duvodu nebude dorucen do cilove schranky. Duvodem, proc signatura muze "nesedet" muze bty samozrejme to, ze dopis odeslal nejaky utocnik. nebo muze jit o chybu pri jejim vytvareni, nebo se pri prenosu mohlo stat, ze nejaky MTA udelal, kvuli jakekoliv chybe (treba ve svem nastaveni) nejakou transformaci, ktera je nekompatibilni s vypoctem DK. Ktera z techto moznosti to je samozrejme ten "posledni" MTA nevi. Takze co udela ? Zahodi zpravu "jen tak" a ja, jako odesilatel, se nikdy nedozvim, ze moje zpravy kamsi nedochazeji, protoze po ceste je nejaky zparchantely MTA, ktery zpravu vzdycky nakopne ? Nebo mi o tom nedoruceni posle chybove hlaseni ? Pak by ale DK problem poctu chybovych hlaseni nijak neresila ...

Mimochodem, ja preferuji byt informovan o kazdem nedoruceni - i za tu (pomerne velkou) cenu, ze jsem, nanestesti, informovan i o nedoruceni tech dopisu, ktere jsem ve skutecnosti neodeslal. Predstava, ze se mnou (skutecne mnou) odeslane dopisy nekde "jen tak" tise zahazuji a ztraceji je mi opravdu krajne neprijemna. DK nam v tomto pripade nepomuze - a jestli pomuze, pak zpusobem, ktery me ponekud desi ...

Jak jsem se před časem díval, běžně mi chodí normální maily s MAIL FROM: <>. Takže ve skutečnosti MAIL FROM: <> vůbec neznamená, že jde o chybovou zprávu. Bohužel.

Pokud si dobre pamatuji RFC, tak prazdna obalkova adresa odesilatele znamena "Na tuto zpravu neposilej chybova hlaseni." a ne "toto je chybove hlaseni". Z pochopitelnych duvodu maji chybova hlaseni prazdnou adresu odesilatele, ale je to "vedlejsi efekt", nikoli vylucne poznavaci znameni.

RFC2821 6.1:

If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope. The recipient of this notification MUST be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification.

RFC2505:

2.6.1. "MAIL From: <>"

The MTA MUST NOT refuse to receive "MAIL From: <>".

The "MAIL From: <>" address is used in error messages from the mail system itself, e.g. when a legitimate mail relay is used and forwards an error message back to the user. Refusing to receive such mail means that users may not be notified of errors in their outgong mail, e.g. "User unknown", which will no doubt wreak more havoc to the mail community than spam does.

The most common case of such legitimate "MAIL From: <>" is to one recipient, i.e. an error message returned to one single individual. Since spammers have used "MAIL From: <>" to send to many recipients, it is tempting to either reject such mail completely or to reject all but the first recipient. However, there are legitimate causes for an error mail to go to multiple recipients, e.g. a list with several list owners, all located at the same remote site, and thus the MTA MUST NOT refuse "MAIL From: <>" even in this case.

However, the MTA MAY throttle down the TCP connection ("read()" frequency) if there are more than one "RCPT To:" and that way slow down spammers using "MAIL From: <>".

Nemyslim, ze by to bylo pripustne - vyjma specialne vyjmenovanych pripadu, coz jsou prave automaticke notifikace (o chybe, o doruceni a podobne).