Názory k článku
DomainKeys - nová antispamová technologie

Jako největší (a téměř jediný) přínos mi přijde omezení joejobů.

Efekt na spam je zcela hypotetický. Získat "ověřenou doménu spamera" lze už dlouho, ze spamem propagovaných url. (+-deobfuskace) Spamy se podle toho blokují, domény registrátoři ruší. Spamery to nutí registrovat nové domény, ale cenu odeslání spamu to zjevně zvýší jen nepodstatně. Navíc je tu dostatek domén, které DomainKeys nemají a v dohledné budoucnosti mít nebudou.

"Jejím cílem je umožnit ověření, že odesílatel poslal mail z počítače, který je oprávněn odesílat maily pro doménu uvedenou v adrese odesílatele"

To bych nesouhlasil. Cílem je ověření, že odesílatel je oprávněn posílat maily s danou doménmou jako adresou sender. Narozdíl SPF není vázané na stanovení "oprávněných počítačů" (velká výhoda, např. pro mobilní odesílatele).

Jinak prima článek :)

> Získat "ověřenou doménu spamera" lze už dlouho, ze spamem
> propagovaných url.

No, mne nepripada, ze by tohle bylo moc pouzivano, ale nemam moc prehled o komercnich antispamovych produktech. Na druhou stranu, co asi ziskate z elementu:

<A HREF="http://www.microsoft.com&quot; onClick="window.open('ht'+'t'+'p://'+'sp'+'a'+'mm'+'erz'+'.'+'com'); return false;">

Cenu za odeslani spamu to nezvysi, ale na druhou stranu to umozni jeho podstatne presnejsi detekci.

> To bych nesouhlasil. Cílem je ověření, že odesílatel je
> oprávněn posílat maily s danou doménmou jako adresou
> sender.

Ad Sender: To resim o neco nize, co je to "v adrese odesilatele".

Jinak ja to myslel ve smyslu "mail prosel pres pocitac, ktery je opravnen podpisovat". Pokud k tomu pridate, ze dotycny pocitac typicky nepovoluje odesilat mailu komukoliv, tak dostanete vasi formulaci :-)

"Obfuskace" je zajimava vec, ale neb to dokaze deobfuskovat prohlizec, je to zjevne algoritmicky resitelne.

Je to pouzivano natolik, ze to nuti mnohe spamery domeny pomerne rychle stridat. Mimochodem, SpamAssasin neni komercni :)

DomainKey podepsana from domena bude jeden z udaju vyuzitelnych pro rozliseni spamu (spolu s ip odesilajiciho mta, from odesilatele, adresata, obsahu zpravy...). Vyuzitelnost bude dost podobna jako u ip adresy. Na tom jestli to umozni "podstatne" presnejsi detekci se asi neshodnem, IMO ne. IMHO je dokonce nestastne to prezentovat jako primarne protispamove opatreni, z toho ze je mail podepsany vubec neplyne, ze nejde o spam.

Ad Sender: - myslel jsem to jako "nezavisi to na definovani nejakych opravnenych MTA, dokonce to vubec nemusi bezet na MTA, ale staci i MUA".

Btw jsem zvedavy zda bude opet vadit, ze si Yahoo tenhle napad patentovalo. Softwarove patenty jsou opravdu zhouba :-( Objev, ze maily lze podepisovat a klic ulozit v dns - hmm, vsechny tyhle schemata vcetne SPF a DomainKeys lze systematicky sepsat tak za pulhodiny :-(

Algoritmicky to resitelne je, ale ne moc jednoduse. (Nicmene je, s tim musim souhlasit.)

Vida on to pouziva i SA? A kontroluje tu domenu oproti nejake databazi? (Pred nejakou dobou jsem tyhle veci v SA zkoumal, ale niceho podobneho jsem si nevsiml, mozna to byla nejaka starsi verze.)

> z toho ze je mail podepsany vubec neplyne, ze nejde o spam

Vsak to taky nikdo netvrdi. Naopak v uvodni fazi nejspis bude podepsani spise znakem spamu ;-)

Vyuzitelnost bude (snad) lepsi, nez u IP. Pokud ma domena vice odesilacich SMTP, tak budete mit povest pro vsechny. Jinak ja jsem tedy IP blacklisty zas tak moc ucinne neshledal :-/

Ad SW patenty: Souhlas :-) Ale zatimco MS dal licenci, ktera nevylucuje vymahani poplatku v budoucnosti a nerekl, co presne ma na te technologii patentovane (respektive co je v patentove prihlasce), tak Yahoo je v tomto ohledu podstatne benevolentnejsi a otevrenejsi.

Tyyy jooooo, takova obfuskace (natoz pak deobfuskace), to je slovo jak remen:)

Kdyz uz chcete vypadat za kazdou cenu svetove, pouzijte radeji "zmateni" nebo jeste lepe "obstrukce".

:-) Á, že by oblíbené termitologické disputace? (Omlouvám se, jazykozpytné hádky...) Takový kousanec nemůžu jen tak nechat.

Překládat se to dá všelijak, kromě zmást jsou ještě možné zatemnit a hravé zašmodrchat.

Ale proč překládat, není důvodu proč odbornou terminologii neobohacovat. Obfuskace je nejjednoznačnější. Obfuskace / deobfuskace je dobrá analogie k šifrovat / dešifrovat. Co bude inverzním postupem k vašemu "zmatení"? "Uspořádání"?

Obstrukce je opravdu blbost, zjistěte si, odkud se ty slova berou a pochopíte.

Bruste si Váš jazyk :-P

S tim musim souhlasit. "Obfuscation" je terminus technicus a kazdy, kdo se bezpecnosti alespon trochu zabyva, vi presne, o co kraci. Kdyz pouzijete "zmateni" nebo "obstrukce", tak zpusobite zmateni ctenaru, ktere ma povahu obstrukce pri snaze o pochopeni smyslu sdeleni.

Ještě bych asi zdůraznil, že "odeslat mail z dané domény" znamená "nechat si podepsat mail z dané domény". Replay útok lze snadno provést s doménami mailinglistů, přeposílačů atd. Pokud se návrh prosadí, bude možná vedlejším efektem, že se mailinglisty přestanou hrabat ve zprávě (žádná škoda).

> 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).

nevite nekdo proc se nikdo nesnazi protlacit elektronicke podpisy, kteryma by sel spam slusne omezit? (to nemluvim o pridane hodnote...)

mozna je uzky profil rychlost linky a ne vypocetni vykon nutny pro podepsani zprav

(certifikat pro elektronicky podpis neni drahy a vystavi ho mnoho certifikacnich autorit)

Ale tohle JE elektronicky podpis ;-) Jen se nepodepisuje konkretni osoba, ale domena.

Standard na elektronicky podpis jako takovy jednak uz +/- pouzitelny existuje (PGP). Ale domnivam se, ze nejvetsi brzdou zde je nutnost menit konfiguraci a uzivatelsky SW u kazdeho uzivatele.

U DomainKeys staci mit SMTP server, ktery je podporuje, samotne vygenerovani klice a vystaveni do DNS je pomerne trivialni.

chapu, ze se podepisuje cela domena, ale docela by me zajimalo, proc se el. podpis u normalnich lidi tak neujal, zatim sem to videl jenom u par "geeku", ze svoje mejly podepisuji.

Ja bych videl problem v nekolika vecech:

1) Velka cast lidi svoje maily podepisovat proste nepotrebuje
2) Lide, kteri by treba podepis vyuzili narazi na to, ze adresat neumi podpis overit
3) Pokud vim, zatim neexistuje framework s nejakou opravdu jednoduchou instalaci / konfiguraci (vcetne distribuce klicu)
4) Cela vec (jako i skoro cely zbytek pocitacove bezpecnosti) je pro obycejne uzivatele proste prilis slozita, takze se ji nezabyvaji

Vime. Protoze je to nesmysl a spam by to nijak vyznamne neomezilo.

Protoze bud' bude ziskani podpisu levne a pak to SPAMery prakticky nijak neomezi, nebo bude drahe a pak to proste znemozni elektronicky komunikovat spouste lidem v chudsich castech sveta. No, a jak tu kdosi poznamenal, navrhovany system vlastne je obdoba podpisu - pricemz klicove je "vlastneni domeny". No, a domeny a jejich hostovani bud' bude lacine nebo drahe. Se zbytkem uvahy, viz zacatek tohoto prispevku. BTW, domeny i jejich hostovani jsou velmi lacine ...

Navrhovany system totiz nesmeruje primarne k omezeni SPAMu, ale k omezeni moznosti padelat adresu odesilatele (a vubec, k omezeni moznosti byt nedohledatelne anonymnim odesilatelem). Byt paranoidni, tak me asi napadne, ze tlak ve skutecnosti vychazi z uplne jine motivace, nez je omezeni SPAMu a z ve skutecnosti uplne jinych mist, nez z tech, ze kterych se vychazet zda. Ale tvrzeni, ze jde o snizeni poctu SPAMU je pomerne dobre kryti. A navic je mozne, ze snizeni poctu SPAMu bude skutecne jeden z vedlejsich ucinku zavedeni takoveho systemu ...

Ale omezi. Budou muset neustale menit domenu, coz sice neni neprekonatelna prekazka, ale zamrzi. A hlavne, takova nova domena nebude moc duveryhodna, takze je podstatne pravdepodobnejsi, ze mail od ni bude vyhodnocen jako spam. Oproti osobnim klicum ma klic na domenu vyhodu v tom, ze jednak novych domen vznika mene, nez novych e-mail adres a hlavne kdyz budu delat povest "po domene", tak podstatne drive ziskam statisticky vyznamny vzorek mailu. Coz ma oboji za nasledek zmenseni problemu novych poctivych domen.

A dalsi plus je, ze zatimco dnes nelze z mailovych hlavicek rici, ze ktere domeny/stroje mail pochazi, u mailu takto podepsaneho to mozne je.

Ad paranoia: Troufam si tvrdit, ze moznost byt nedohledatelne anonymnim odesilatelem bude +/- stejna jako dnes. Pouze nektere [naivni] zpusoby budou jeste o neco jednodussi na vytrasovani (viz predchozi odstavec).

ze jednak novych domen vznika mene, nez novych e-mail adres

Ano, dnes tolik nových domén nevzniká. Proč ale předpokládáte, že po zavedení vámi prosazovaného systému to tak zůstane? Zkuste si, máte-li možnost, prohlédnout nějaké typické tři roky staré spamy a nějaké dnešní. Určitě si všimnete, že jsou tam velmi podstatné rozdíly, které jsou důsledkem nasazení různých antispamových řešení. Proč si myslíte, že na vaše řešení spammeři reagovat nebudou?

Upresneni: Ten pomer mel byt domen/mailu pro "korektni" (ne-spamove) ucely.

Slovo "zamrzi" je pravdepodobne velmi presnym odrazem toho, jak bude opatreni ucinne. Opatreni, ktere SPAMery "zamrzely" tu uz bylo spousta. A nektere z nich dokonce dokazaly *kratkodobe* mnozstvi SPAMu snizit ...

Samozrejme, ze za soucasnych podminek novych domen vznika mene nez novych email-adres. Neni zdaleka potreba vytvaret pro kazdy dopis novou domenu. Neni ale jakykoliv duvod se domnivat, ze pocet zrizovanych domen prudce nevzroste, pokud to nezacne byt v novem prostredi potreba.

Ja nepopiram, ze jakekoliv prijate opatreni nebude mit nejake vysledky. Jen si myslim, ze se to vzalo z nejakeho spatneho konce.

SPAMer odesilajici dopis ma od nekoho IP konektivitu (rikejmemu ISP) a (pokud se system prosadi) je jednoznacne, od koho "ziskal" emailovou adresu (rikejme mu Mailbox Provider). Muzeme hodnotit "serioznost" ISP - podle toho, jak caste je posilani SPAMu z jejich siti, nebo "serioznost" MP, podle toho, jak casto je odesilan SPAM z "jejich domeny". Z nejakeho, me neznameho, duvodu se ale veri, ze vlozit odpovednost na ISP za to, komu poskytuje IP konektivitu je nemozne, zatimco vlozit odpovednost na MP za to, komu poskytuje mailbox je "ta prava cesta". Zatimco "blokovani siti" - proto, ze z jejich IP jsou podnikany utoky se povazuje za nevhodne (protoze by se to dotklo nevinnych), vyhodnocovani serioznosti emailove domeny se znovy povazuje za "pravou cestu".

Jinymi slovy - z meho pohledu je ISP jedna komercni organizace se vztahem ke SPAMerovi a MP druha. Je v zasade naprosto jedno, na kterou z nich budeme tlacit, aby si v radach svych klientu udelala poradek. Jedno, az na jeden detail - v pripade, ze budeme tlacit na tu prvni, nemusime se omezit jen na reseni problemu s emailem. Presto se jako "prave reseni" prosazuje natlak na organizaci druhou, coz podle me nema zadne vyhody - jen nevyhody. Proc, to me tedy opravdu nenapada ...

Ad pocet domen - viz jina odpoved.

[Tise predpokladam, ze za IP odesilatele budete povazovat IP druheho konce SMTP.]

Neresite "kdo to je vlastne ten MP". A to je zasadni vec. MP je:

1) Uzivatel sam (firma, lide kteri maji soukromou domenu, skola atp.). V tom pripade je preci lepsi vlozit odpovednost na uzivatele nez na jeho ISP.

2) ISP (@quick.cz atp.). Zde je model ekvivalentni.

3) Freemail, placeny mail. Pres ne se moc opravdu hromadnych mailu neposila, nebot to neni prilis sikovne. V pripade placenych mailu je MP ve zhruba stejnem postaveni jako ISP.

Ted bych rozebral technicke detaily. Predne - jak urcite ISP? Rekl bych ze sitovych rozsahu v RIPE. Nabizi se otazka, jestli opravdu jsou informace ke vsem adresam pres RIPE dostupne a jestli je RIPE na takovou zatez vubec stavena.

Dovoluji si tvrdit, ze blokovani (nebo znevyhodnovani) podle IP rozsahu ma podstatne vetsi negativni dusledky na "poctive obcany". Pokud se jako firma chovam "dobre", mam nejakou domenu a alespon trochu si hlidam sit/zamestnance, je silne nepravdepodobne, ze by moje domena ziskala spatnou povest. Ve vami uvedenem modelu ale staci, aby nejaky zakaznik na stejnem adresnim rozsahu zacal posilat spam a mam problem.

ISP ho sice treba zablokuje (i kdyz to taky nebude hned a rozhodne to bude ex post), ale muj rozsah ziskal spatnou povest. (I kdyz tomu by se dalo nejspis branit duslednym delegovanim rozsahu na kazdou firmu zvlast...) A to nemluvim o pripadu, kdy ziskam rozsah "po nekom"...

Dale premitam, co s celym systemem udela fakt, ze spameri pro odesilani hodne casto vyuzivaji vyhackovanych cizich pocitacu.

Netvrdil jsem, ze "rezim podle ISP" by nevyzadoval jakekoliv zmeny. I v tomto ohledu by si na sve prislo DNS, stejne jako v metode navrhovane. Jen bych misto zaznamu v domenach doprednych pouzival domeny reverzni. Tam by, pro konkretni IP byl docela obycejny a prosty zaznam, zda je konkretni IP opravnena odesilat postu. ISP by tak mohl "oznamit", ze, napriklad, jeho dialupove IP proste primo postu odesilat nemohou (a musi pro odchozi provoz pouzit jim provozovany SMTP server), zatimco jine ji odesilat mohou. A tam, kde by prislusna IP postu odesilat mohla - muzete take vzit v potaz "duveryhodnost" prislusne domeny - stejne jako v modelu navrhovanem. Jenze vezmete domenu reverzni, nikoli doprednou. Zjistit presneho ISP pak nepotrebuji - priblizna aproximace ISP je ten, kdo delegoval prislusnou reverzni zonu postaci. A pokud nestaci - v ramci stejneho zaznamu, kterym jsme rozeznavali, ktera IP ma moznost postu odesilat a ktera nikoliv muzeme mit i nejakou identifikaci "koncoveho zakaznika" (jednoznacnou v ramci jedne reverzni zony) - pro pripad, ze prideleny adresni prostor je tak maly, ze se v jednom prostoru setkava klientu vice. Pomoci takove identifikace lze adresy v ramci jednotlive reverzni zony dale libovolne seskupovat.

Reverzni domeny se zrizuji podstatne obtizneji nez domeny "dopredne". V ostatnich ohledech jsou problemy podobne - jestlize se jako firma chovam dobre, tak snad neprichazi v uvahu moznost, ze by z mych pocitacu (meho adresniho rozsahu) delal kdokoliv cokoliv spatneho, nemyslite ?

Fakt, ze dnes se SPAMy zhusta odesilaji z pocitacu napadenych virem ci trojskym konem je zhoubny pro obe varianty stejne. V takovem pripade odchazi mail se stejnymi identifikacnimi znaky ajko by ho skutecne odeslala ziva osoba u tohoto pocitace sedici. Takze vazny problem mame at uz si hlida odesilani posty MP nebo ISP ...

Celkove se snazim rict, ze problemu na Internetu se nezbavime, pokud ten, kdo nekomu zprostredkovava do teto site pristup, nema jakoukoliv odpovednost za to "koho k tomu pustil". Zacneme-li resit tento problem, pak zjistime, ze vytvoreny mechanismus lze pouzit i na ochranu proti odesilani nevyzadane posty. Soucasny navrh ale resi problem jen z izolovaneho pohledu prave te posty - a vytvoreny mechanismus nebude dobry k nicemu jinemu (navic si myslim, ze i k ochrane pred nevyzadanou postou je horsi - protoze proste vytvorit "novou" doprednou domenu je prilis snadne). I kdyz se takovy system nakrasne "rozjede", potreba onoho druheho reseni nezanikne a stejne se to, driv nebo pozdeji, bude muset resit take. Chapu ale, ze ISP, pro ktere kdokoliv, koho pripoji znamen proste jen "dalsi prachy" - a dokonce reklamni kampane lakaji klienty na hesla "pristup uplne kdokoliv, bez hesla" nemaji zadny zvlastni zajem na tom, aby se neco takoveho resilo a soucasne patrne tusi, ze pokud se nenajde nejake reseni toho nejzjevnejsiho dusledku jejich pristupu (coz je prave nevyzadana posta), pak by mohl tlak na to, aby veci nejak resili narust. A proto se mozna navrhy ubiraji tak vehementne smerem, ktery z toho jakoukoliv odpovednost ISP vynecha - jim zustanou ty prachy a moznost pripojit uplne kazdeho kdo zaplati, a problemy, ty at si resi nekdo jiny ...

Co SPF? Neni to to samy? Kolik tech standardu vubec je?

SPF se snazi garantovat (s drobnymi odchylkami) totez, co DomainKeys, ale jde na to trochu jinak. Podobne jako Sender-ID od MS. Pokud by byl zajem, muzu se venovat i temto dvema technologiim, v clanku mi na ne uz nezbyl prostor.

Vždy když někdo něco takového vymyslí, tak si připadám jako nějaký podivín.
Stačí se přece podívat do všech E-mailových hlaviček a provést (v nejasných případech třeba ručně) kontrolu, zda souhlasily údaje uváděné v SMTP-komunikaci u příkazů HELO, Mail-From a v položce From:
Při nesouladu je samozřejmě mail podezřelý jako spamový. (A většina spamerů musí nějaký nesoulad našvindlovat, aby se jim stovky spamů nevrátily.)
A pokud někdo skutečné dopisy odesílá s rozdílnými informacemi, no tak má prostě smůlu, a třeba jeho dopis budou někde pokládat za spam. (A tak si musím časem vybrat třeba věrohodnějšího providera.)
Naprosto ale nechápu, proč se někdo nepokusil zmíněné kontroly naprogramovat do ochran? Vysvětlení jsem si našel jediné. Anti-spamoví experti se neumějí podívat třeba na Unixu do /var/spool/mail/uživatel , protože se naučili pracovat jen s Windows, kde je (asi schválně) telnet tak na úrovni roku 1982. (Konec konců hlavně přece vadí šíření virů spamy, a antivirová ochrana je u současného Windows stále na stejné úrovni jako v DOSu, tedy tak z roku 1980.)

A proc tedy takovou kontrolu nenaprogramujete Vy? ;-)

LOL! Jee, vy jste ale genius. :-))) A to vas nenapadlo, ze zaprve vsichni neposilaji postu ze sveho mailserveru a zadruhe nekdo posila z tehoz pocitace postu pochazejici z nekolika (desitek/stovek) domen?

Když budete 5 minut přemýšlet, tak zjistíte, že toto se dá snadno vyřešit.
I když většinou švindl v hlavičkách je vidět na první pohled (a ne až na onen duhý na pětiminutové přemýšlení).
P.S.
Opravdu mě už nebaví vždy vysvětlovat situaci lidem, kteří o ní z principu nechtějí přemýšlet.

Rozhodne. Doporucuji si to nechat patentovat. :-)))

Ze by syndrom "Na kazdy problem existuje alespon jedno zjevne, jednoduche, elegantni a snadno vysvetlitelne nespravne reseni"? ;-)

Bingo! :-)))