Navic, pokud si mam pod pojmem "normalni uzivatel" predstavit cloveka, ktery dotycne problematice nerozumi, jak ma poznat, ze nova aplikace (napriklad proudovani multimedii) nebezi kvuli nastaveni filtru u providera nebo kvuli nejakemu problemu na lokalnim PC?
Ja radeji zustanu u udrzovani sveho systemu v aktualnim stavu.
Myslim, ze to neni spravne reseni. Mnohem lepsi by bylo, kdyby provider (muze to byt i jiny subjekt) aktivne upozornoval na bezpecnostni problemy uzivatelova pocitace. Spravne nastavena aplikace typu "Windows Update" vyresi 99% podobnych problemu.
Ja bych hlasoval pro to, ze drazsi je vypocetni kapacita :-) Disky jsou za babku a navic ma uzivatel zaplaceny prostor o fixni velikosti, kterou nemuze prekrocit.
Samozrejme nepopiram, ze by "povinne" podepisovani mohlo vyresit NEKTERE problemy se sirenim viru a se spammingem - ale v pomeru problemu, ktere by to prineslo se mi jevi, ze to vyresi prilis malou cast. Podotykam, ze ztratu anonymity vubec nepovazuji za vazny problem pro tyto ucely - uz proto, ze by k ni prakticky nedoslo ...
Urcite by bylo legracni, kdybych meril dostupnost Internetu napriklad podle funkcnosti LUPY(.cz) :-)
Na problemy Contactelu se musite optat Contactelu. Na problemy IOL se musite zeptat Ceskeho Telecomu, na problemy servery.com se musite zeptat Globe. Web NIXu nejede, protoze je nejaky problem s hardwarem serveru, na kterem bezi web. Funkcnosti NIXu jako propojovaciho centra se ten problem nedotyka.
Cena zahranicni konektivity i prenosove kapacity je dneska uz hodne nizko. Pokud mate tedy zahranicni kapacitu a prenosove linky drahe, nakupte u nekoho jineho. Tedy, samozrejme, pokud vam vas vlastnik, ktery vam tuto drahou konektivitu momentalne dodava u nekoho jineho nakoupit dovoli ...
Nemuzu se take zbavit dojmu, ze nekdo ma dojem, ze analyzovat datovy tok na urovni gigabitu az na uroven aplikacni vrstvy je nejaka trivialita ...
Navic takove reseni popira cely princip Internetu - hloupa sit a chytre koncove stanice :-|
Za prvé: nevidím jediný důvod, proč by to mělo pomoci. Za druhé: vidím jasný důvod, proč by to vadilo. Za třetí: nevidím způsob, jak v historicky krátkém čase zjistit, zda na se na danou adresu resolvuje hodnota nějakého MX záznamu. Takže bych prosil nějaké bližší vysvětlení.
Take i ja jsem si pohraval s myslenkou neprijimat SPAM od adres bez PTR, bohuzel bordel nejen ceskych ISP je prilis veliky...:-(
K tomu slouží whois databáze a IMHO lépe.
ale samozřejmě ani zde vynalézavost spammerů nezná mezí a tudíž posílají spamy v HTML, kde jsou znaky jako entity
Na což spamassasin promptně reaguje a přiřazuje tomu náležité bodové ohodnocení... :-)
Mezi příkazy 'host 1.2.3.4' a 'whois 1.2.3.4' je rozdíl jednoho znaku... :-)
Navíc je nepochybně snazší v blacklistu udržovat záznam *.abc.com.tw než tam mít konkrétní adresové rozsahy a navíc hlídat, zda provider abc.com.tw náhodou nezměnil IP adresy.
To bezesporu ano. Ale v minulém příspěvku jste operoval možností zjistit, komu si mám na nežádoucí chování z dané IP adresy stěžovat. Proto jsem upozornil, že tento problém řeší (a lépe) whois.
Ale myslím, že to jsou již detaily a shodneme se na tom, že revezní IP určitě ano.
S tím naprosto souhlasím, jak už jsem napsal, na blokování jakékoli komunikace z hostů bez reverzního záznamu nevidím nic principiálně špatného. Jenomže doba je taková, že provider, který umožní na jedné adrese existovat padesáti virtuálním webům s adresami typu firma.cz bez reverzních záznamů, není označen za vyvrhele, ale dáván ostatním za příklad. :-(
Je to podobne, jako bych Vam rekl, ze muj trivialni filtr ve schrance, ktery presouva vsechny e-maily, ktere maji v hlavicce odesilatele z Ruska, Ukrajiny, Koreje a Ciny (a dalsich) ... resi problematiku SPAMu. Ne, on resi problematiku SPAMu, ktery je adresovan me osobe - coz je pomerne velky rozdil. Rozhodne bych se neodvazil vydavat ho za nejake univerzalni reseni :-)
213.168.177.86. Udělejte si reverzní lookup a zkuste odhadnout, kdo by asi tak případnou stížnost dostal. A pak zkuste pro srovnání whois.
tato myslenka je zcela zcestna. Do reverzniho zaznamu si muze kazdy napsat, co chce, takze se muze stat, ze zablokujete nekoho, kdo za dany problem jednak nemuze a jednak nemuze ovlivnit dalsi chovani (ani pripadne vyreseni problemu).
Jedinou alespon trosku spolehlivou metodou identifikace providera jsou zaznamy v RIR.
A mimochodem, zmena IP adres je pro providera MNOHEM slozitejsi nez zmena domeny.
Myslim, ze v kazdem systemu bychom meli mit pred ocima predevsim spravnost a az teprve pote jednoduchost implementace.
MK
Nicmene - prijmout takova pravidla, ze jednomu MTA smi posilat postu pouze
by mohlo veci trochu zlepsit. Prinejmensim o to, ze by bylo jasne, kdo odovida za odesilani posty z dane oblasti.
Pricemz pro zjisteni informace, ktery MTA je opravneny obsluhovat dane koncove stroje (a tedy zprostredkovavat pro ne vstup posty do site) by se muselo neco vymyslet - nejspis do DNS.
Jene zatim nic takoveho neexistuje a i kdyby se neco takoveho zavedlo, dlouhe prechodove obdobi je nevyhnutelne. Posta je jednou nejstarsich standardizovanych aplikaci Internetu ...
Received: a do těch si každý může napsat, co chce. A navíc se k nim dostanu až v okamžiku, kdy je mail přijímán - což je svým způsobem pozdě.Spíš bych viděl jako průchodnější zavedení jakési analogie MX záznamům. Tedy něco na způsob 'firma.cz. MT smtp.firma.cz.' s významem počítač smtp.firma.cz je určen k odesílání pošty s adresou odesílatele cokoli@firma.cz. Tj. nedefinovat "oprávněný MTA" podle místa vzniku mailu ale podle adresy odesílatele. To by umožňovalo kontrolu ze strany přijímajícího MTA už po příkazu MAIL.
Trochu se to blíží diskusi, která tu nedávno proběhla ohledně toho, že Atlas a iDnes údajně nabízejí připojení k Internetu bez SMTP relay. Šlo o to, zda uživatel, který se připojí přes iDnes a chce poslat mail ze své adresy ferda@seznam.cz, má používat k tomu účelu SMTP relay iDnes nebo Seznamu. Osobně mi vyhovuje dnešní stav, kdy si může vybrat (a navíc může mail odeslat přímo). Ale jsem připraven na to, že tomu tak nemusí být navždy.
Stale si myslim, ze kontrola "opravneneho MSA" podle IP je vhodnejsi - ma lepsi parametry ve vsech vyse zminenych vlastnostech a pritom si nejsem vedom vaznejsich komplikaci. Dokonce ani explicitni autentizace odesilatele neni nutna, i kdyz neni ani vyloucena. Souhlasim ale s tim, ze zjistit udaj z "received" hlavicky je pozde - udaj o IP adrese, ze ktere MSA postu prijal by ale mohl byt celkem bez problemu predavan jako extenze MAIL FROM. V cem jsou nase navrhy spolecne je existence informace o "opravnenych MSA" ulozena v DNS, s tim, ze ja je klicuji podle IP zdrojove stanice - tento udaj by pak byl tedy nejspis obsazen v DNS v reverzni zone.
Samozrejme, ze chapu, ze jako uzivateli vam vyhovuje , ze si muzete SMTP siroce vybrat - jenze ja pak, jako nestastny prijemce vic nez stovky SPAMu denne se nemam na koho obratit aby takove radeni zatrhnul - prave proto, ze vy si muzete prilis siroce vybirat (samozrejme predpokladam, ze pouziva prvni osoba nebude chapana jako osobni utok). Prave zuzeni teto moznosti vyberu - pricemz se ale soucasne snazime, aby nikdo nebyl omezen vice nez je naprosto bezpodminecne nutne umozni nejaky zasah.
Samozřejmě předpokládám, že SMTP relay (např.) Seznamu bude i nadále posílat ven pouze poštu od svých klientů. Jak si definuje své klienty a jak to bude ověřovat, to bych nechal na něm (autentizace, IP restrikce, ...). Pokud to dělat nebude, samozřejmě riskuje, že se brzo ocitne na veřejných blacklistech (pokud tam už není :-) ). Ale tohlo jsou věci, které fungují (resp. měly by fungovat) už dnes.
Pri vasem systemu by tedy clovek cestujici po svete mohl mit problemy s postovni komunikaci, pokud by si nezrizoval "lokalne prislusne" adresy
Toho problému jsem si vědom. Nemyslím si, že varianta, kterou jsem navrhoval, je nějak výborná. Pouze si myslím, že je o něco lepší (nebo spíš méně špatná) než ta druhá. Její výhodu vidím v tom, že by aspoň zamezila tomu, aby kdokoli mohl rozesílat po světě viry s adresou odesílatele security@microsoft.com. Protože bohužel pořád existuje dost uživatelů, kteří věří tomu, co je napsáno ve From: (a nevěřím, že by se to mohlo změnit).
Souhlasim ale s tim, ze zjistit udaj z "received" hlavicky je pozde - udaj o IP adrese, ze ktere MSA postu prijal by ale mohl byt celkem bez problemu predavan jako extenze MAIL FROM.
To byl jen vedlejší problém. Ten hlavní vidím pořád v tom, že příjemce nemá možnost tu IP adresu zdrojové stanice zjistit, je odkázán na to, co mu předávající MTA řekne. Takže není problém napsat tam jako zdrojovou IP adresu cokoli, co se zrovna hodí. Takže to svým způsobem není o nic věrohodnější údaj než adresa odesílatele.
s tim, ze ja je klicuji podle IP zdrojove stanice - tento udaj by pak byl tedy nejspis obsazen v DNS v reverzni zone
Tady vidím jednu zjevnou výhodu, kterou rozlišení podle IP adresy zdroje má. Obvykle je výrazně obtížnější dostat se k reverzním záznamům než k přímým. Na přímé záznamy stačí si zaregistrovat nějakou doménu; ty reverzní by mi musel někdo nadelegovat - a když je budu zneužívat, můžu o tu delegaci snadno přijít.
Samozrejme, ze chapu, ze jako uzivateli vam vyhovuje , ze si muzete SMTP siroce vybrat - jenze ja pak, jako nestastny prijemce vic nez stovky SPAMu denne se nemam na koho obratit aby takove radeni zatrhnul
Bohužel je tady jasně patrné, že klasické internetové protokoly vznikaly v době, kdy slušné chování bylo samozřejmostí a pokud náhodou u někoho nebylo, nebyl problém ho z Internetu velmi rychle vyobcovat. Proto v nich chybějí jakékoli obranné mechanismy proti nežádoucím jevům, které jsou dnes na denním pořádku. Problém vidím právě v té možnosti se na někoho obrátit: je mnoho provozovatelů služeb, kteří jakékoli žádosti o zákrok (snad kromě policie) ignorují a klidně si provozují open relay nebo jiným způsobem umožňují masivní spamming prostřednictvím jejich serverů. Dokud se toto nezmění, bojím se, že žádné z navrhovaných řešení nebude k ničemu.
Co se tyce druhe casti prispevku - ja mel dojem, ze rec je o MAIL FROM adrese, tedy o adrese ze SMTP obalky. Alespon ja se celou dobu bavim o SMTP. To ale neni adresa, kterou uzivatel vidi, takze to, co popisujete jako problem a jeho reseni povazujete a vyhodu je patrne daleko komplikovanejsi problem, nez vas napadlo - a bude tezke to doladit tak, aby to stale zustalo resenim a jeste se to dalo povazovat za vyhodu. Krome toho, nas problem neni autenticita from (at uz se bavime o kteremkoliv ze FROMu) ve spojeni s laickymi uzivateli. Problem duveryhodnosti dopisu resi dostatecne uplne system elektronickych podpisu a neni duvod ho resit duplicitne upravou systemu dorucovani. Nas problem, ktery zatim dobre reseni nema a o nalezeni ktereho diskutujeme je SPAM. Pri reseni tohoto problemu zminena vyhoda vlastne zadnou vyhodou neni (a to optimisticky predpokladam, ze problem vubec resi, coz opravdu neni prilis jiste) a neni tedy zvlastni duvod kvuli ni toto reseni preferovat. Mimochodem, ve vasem systemu budete muset nejak vyresit posilani dopisu se zdrojovou adresou <>.
Co se tyce tretiho prispevku - tam jste nepochopil (nepochybne proto, ze jsem to spatne vysvetlil), PROC je ta adresa predavana. Ta adresa je predavana proto, abych v pripadech, kdy MTA VERIM, ze ta adresa je prava mohl, pri vyskytu SPAMu blokovat jen zminenou adresu a nemusel blokovat hned celou komunikaci daneho MTA (predstavte si, ze se bavime o MTA celeho AOLu nebo nekoho jineho podpbne velikeho) a tim komunikaci vsech ostatnich uzivatelu. Neduveryhodne MTA (jejichz seznam muze byt snadno vedeny formou RBL) se samozrejme blokuji cele a takto predavana IP je irelevantni a k nicemu se nepouziva. Cela DNS kontrola na "patricnost" MTA k dane IP je pak uz jen mala pojistka celeho procesu - aby MTA, o kterem se jeste nevi, ze neni duveryhodny, nemohl rozesilanim SPAMu a uvadenim nahodnych zdrojovych adres blokovat komunikaci nevinnych - takze MTA sice verim, ale preci jen je ta duvera limitovana a overovana jeste jednim udajem pochazejicim z vice-mene nezavisleho zdroje. Naopak, kazdy "kecajici" MTA by tim mel k dispozici jen omezenou sadu IP adres, ktere by mohl takto pouzit a ty by se na black-list dostaly velice rychle vsechny i v pripade, ze by nebyl MTA zablokovan jako celek. Tento system je bezpecny prave tim, ze ackoliv "kecani" neni uplne vylouceno, pomaha jen na malou chvili a neni jednoduche se po "kecani" vzpamatovat a zopakovat ho. Prave ve spojeni s tim, ze kontrolni system je navazan na pridelovani IP, ktere je pod daleko vetsi kontrolou nez pridelovani domen vidim hlavni silu, pritom ji ale dosahuji bez negativnich pruvodnich jevu sily systemu vaseho a pritom nevyzaduje zadne razantni zasahy do existujicich postupu a umoznuje i postupne zavadeni.
Klicovy je ale zaver vaseho prispevku - stav, ktery popisujete, je dan prave tou vysokou variabilitou. Prijemci nemaji zadnou jednoduchou moznost jak konkretniho spammera blokovat a mohou blokovat prakticky jen cele obrovske bloky adres (a ani to neni spolehlive), coz prinasi neprijatelne side-efekty a proto se to vetsinou nedela. Tim nemohou vyvinout tlak na ISP a ti tedy neprijimaji zadna efektivni opatreni - a ostatne, jejich moznost je prijmout je vysokou variabilitou take dost zasadne komplikovana. Prave to, ze ISP zasah umoznite a vyrazne zjenodusite a soucasne obetem umoznite reagovat daleko selektivneji (a tedy bez neprijatelnych side-efektu) by mohlo prinest vyrazne lepseni. Bavime se prave o tom, ze bude mozne efektivneji zasahovan proti "ignorujicim" i bez policie - respektive, dokazete je jasne znevyhodnit proti neignorujicim, coz pro ne muze ekonomicke nasledky a tim vyvolate ten tlak. Ano, to o cem mluvim nevyresi problem ani uplne ani mavnutim kouzelneho proutku - ale to na tom se svym systemem nejste lip. Ja mluvim o navrhu, ktery by MOHL pomoci a ktery se mi, alespon zatim, zda pomerne dobry (to je, ostatne i ten vas, i kdyz neni TAK dobry ;-) ). Uz jsem prilis stary na to abych zahodil dobre reseni jen proto, ze neni dokonale.
Nicmene, bavime se v ciste teoreticke rovine. Aby byla sance, ze se nektery ze systemu nekdy ujme v praxi, bylo by nutne precizovat navrh dokonce, napsat draft, predlozit ho odborne verejnosti, zkusit protlacit implementaci do distribuce sendmailu (treba jen jako volitelny option), presvedcit par veltsich ISP, aby vyplnily do DNS prislusne zaznamy - proste, delat na tom. Jen tak si o veci povidat na Lupe (kde jsme mimochodem, dost mimo bezny typ diskuse nemluve o tom, ze v bezne mailove konferenci by se o tom diskutovalo pohodlneji) nic neresi - a SPAMy chodi dal. Jen za dobu napsani tohoto prispevku jsem jich dostal osm ...
Samozřejmě. Původně jsem chtěl napsat, že uživatelé věří dokonce i tomu, co je v položce From: hlavičky mailu, která je ještě méně důvěryhodným údajem než adresa z obálky. Protože příspěvek byl už tak dost dlouhý, větu jsem zkrátil, takže výsledek působil poněkud mimo mísu (a to, co mi zůstalo v hlavě, se nepřeneslo).
Krome toho, nas problem neni autenticita from (at uz se bavime o kteremkoliv ze FROMu) ve spojeni s laickymi uzivateli. Problem duveryhodnosti dopisu resi dostatecne uplne system elektronickych podpisu a neni duvod ho resit duplicitne upravou systemu dorucovani.
Systém elektronických podpisů tento problém řeší, ale jen za předpokladu, že se je uživatelé naučí používat (a hlavně vyžadovat). Po svých zkušenostech se současnými typickými uživateli elektronické pošty jsem poněkud skeptický vůči řešením spoléhajícím na změnu chování uživatelů (a navíc si myslím, že bude ještě hůř). Ta myšlenka, kterou jsem prezentoval, byla zamýšlena čistě jako podpora pro to, aby blacklisty založené na adresách odesílatele měly aspoň trochu šanci být užitečné.
Systém založený na IP adrese zdroje má také své výhody (jinde než ten první), ale vidím tu jeden technický problém: až do masového nasazení IPv6 (v tomto ohledu bych byl strašně rád optimistou, ale moc mi to nejde :-) ) bude potřeba řešit problém maškarádovaných lokálních sítí. Řešení, že taková síť bude muset veškerou poštu posílat přes MTA svého ISP, se mi moc nelíbí. Adresa zdroje typu 10.23.51.73 je samozřejmě bezcenná. Takže ve výsledku by takový MTA musel jako IP adresu původu uvádět tu svoji a bylo by potřeba nějak řešit otázku toho, kdo smí být oprávněným MTA pro svou vlastní adresu. Také by bylo potřeba vyřešit to, že vzhledem k tomu, jak je implementován sendmail od řady 8.12, by u všech lokálně generovaných mailů byla adresa zdroje 127.0.0.1. Nejjednodušší by asi bylo řešení, kdy by MTA u jakéhokoli mailu pocházejícího z privátních rozsahů (nebo lokální smyčky) použil svou IP adresu.
Horší problém vidím u dial-upů s dynamicky přidělovanými adresami. Zablokuji-li IP adresu, z níž byl poslán spam, spammera se to pravděpodobně nijak nedotkne a místo toho může být příště zablokován někdo, kdo se ničím neprovinil. Tady mne nějaké jednoduché a efektivní řešení nenapadá - samozřejmě kromě toho, že provozovatel dial-upu, který trpí posílání spamu přes svou relay, si zasloží být zablokován jako celek. Stejně jako u problému z minulého odstavce je to důsledkem toho, že v dnešním Internetu není IP adresa příliš dobrým identifikátorem klienta.
Ano, to o cem mluvim nevyresi problem ani uplne ani mavnutim kouzelneho proutku - ale to na tom se svym systemem nejste lip. Ja mluvim o navrhu, ktery by MOHL pomoci a ktery se mi, alespon zatim, zda pomerne dobry (to je, ostatne i ten vas, i kdyz neni TAK dobry ;-) ). Uz jsem prilis stary na to abych zahodil dobre reseni jen proto, ze neni dokonale.
Netvrdím, že je to špatná myšlenka. Jenom nejsem (ani u jedné varianty) jednoznačně přesvědčen, že by výhody, které by přinesla, byly větší než implementační problémy. Jinak si ale nemyslím, že by se ty dvě varianty a priori vylučovaly, dokážu si představit, že by fungovaly společně.
Co se maskarad tyce - zadne maskaradovane site na Internetu neexistuji. Z hlediska Internetu existuje jeden jediny pocitac (typicky s jednou adresou) - to, ze tento ocitac na a sebou dalsi sit, ktera NENI soucasni Internetu, a ktere nejakym zpusobem zprostredkovava komunikaci nas nezajima a zajimat nemusi. Zdrojova adresa mailu je pak TATO jedina IP adresa - to je adresa, kterou ostatni vidi.
Nenapadlo me, ze uvidite problem v tom, ze MTA uvadi jako zdrojovou adresu sebe sama - ja to naopak povazoval za bezne a caste a to jsem vubec nepremyslel o prekladech. Neshledavam to dokonce byt zvlastnim pripadem - resim to stejne jako kdyz ta adresa stejna neni.
Ani s dial-upy nevidim velky problem. ISP bud' omezi moznost svych dial-upovych zakazniku komunikovat s koncovymi SMTP servery primo (prave zaznamy v reverznim DNS budou rikat, ze tato koncova IP ma pravo odesilat postu jen pres konkretni SMTP servery - a tedy nema pravo komunikovat primo) a na svem SMTP serveru bud eprovadet takove kontroly, ktere snizi (nikoli zcela vylouci) pravdepodobnost, ze jeho adresy budou zarazeny na black-list, nebo to neomezi - a pak proste jeho adresy budou postupne zablokovany jednotlive a zakaznici takoveho ISP budou mit smulu.
Mate samozrejme pravdu, ze IP adresa neni dobrym identifikatorem klienta - jenze, a ja to opakuji stale dokola a stale neuspesne, ja na vec jdu jinudy nez vy. Ja se SPAM nesnazim omezit tim, ze autentizuji odesilatele. Ja se poue snazim odesilani mailu navazat na neco, ceho je omezeny pocet a proto si o to kazdy dba. A IP adres je omezeni, i kdyz velky pocet, a tak je vetsi sance ze ten, komu byly prideleny, se bude pokouset dbat o to, aby techo adres slo do sveta dopisy odesilat. Jestlize to nedokaze, muze se stat, ze si proste neposle zadny mail - a ziskat nove adresy nebude jednoduche. Jinymi slovy - me nezajima, kdo konkretne z te IP neco delal - ja za tuto cinnost cinim odpovedneho toho, kdo mu tu IP adresu ma pridelenou a jemu ji propujcil cimz nutim drzitele adresy mit nejaka pravidla a dbat na jejich dodrzovani. Mimochodem, ja tim zachovavam moznost anonymni vymeny zprav (i kdyz zrovna ja nejsem anonymum naklonen, domnivam se, ze je skoda tuto vlastnost ztratit, pokud to neni nutne).
A tu literaturu si skutecne proctete - kdyz mluvite o implementacnich problemech, rekl bych, ze jste ve svem systemu napriklad nerozmyslel co s forwardovanymi zpravami (FROM se nemeni, ale zpravu odesila "divny" stroj) vcetne emailovych konferenci a co s chybovymi hlasenimi (FROM je <> - proti cemu budete co overovat ?) - implementacni problemy vaseho reseni jsou znacne a vyzadovaly by patrne pomerne zasadni zasahy do systemu dorucovani zprav.
Problém nevidím v tom, že by MTA mohl uvádět jako adresu zdroje sebe. Vidím ho v tom, že to bude muset dělat i v případech, kdy to není pravda a podle dnešních pravidel by tam uvedl něco úplně jiného. Samozřejmě to není problém - ale je potřeba s tím počítat. A navíc tím dochází ke splynutí většího množství odesílatelů bez možnosti odlišit je v blacklistu.
a na svem SMTP serveru bude provadet takove kontroly, ktere snizi (nikoli zcela vylouci) pravdepodobnost, ze jeho adresy budou zarazeny na black-list, nebo to neomezi - a pak proste jeho adresy budou postupne zablokovany jednotlive a zakaznici takoveho ISP budou mit smulu.
Zkusím-li si představit zákazníka, který nikdy žádný spam neposílal, a najednou je jeho řádný mail odmítnut s tím, že jeho adresa je na blacklistu (protože je ošklivý spammer), rozhodně to nevidím okrajový problém. Upřímně řečeno, v té současné záplavě mi daleko víc než samotný spam a viry vadí hlášení, že "můj" mail byl odmítnut jakožto nedoručitelný - například proto, že obsahoval virus. Už jsem dokonce dostal několik výhrůžek, že jestli toho nenechám, bude moje adresa zařazena na blacklist. Tlak na ISP, aby tomu zamezil, je v tomto případě na můj vkus příliš nepřímý - v první řadě by to odnesli zákazníci (všichni ve stejné míře - vinní i nevinní), ISP až potom.
Co se maskarad tyce - zadne maskaradovane site na Internetu neexistuji. Z hlediska Internetu existuje jeden jediny pocitac (typicky s jednou adresou) - to, ze tento ocitac na a sebou dalsi sit, ktera NENI soucasni Internetu, a ktere nejakym zpusobem zprostredkovava komunikaci nas nezajima a zajimat nemusi. Zdrojova adresa mailu je pak TATO jedina IP adresa - to je adresa, kterou ostatni vidi.
Uvědomím-li si, že tato jediná IP adresa v některých případech reprezentuje desítky až stovky zákazníků kabelové televize, mikrovlnného připojení nebo ADSL, opět z toho nemám dobrý pocit. Pomíjím teď fakt, že bych si, existuje-li jiná možnost, nepořídil připojení, kde bych neměl skutečnou IP adresu - každý takové striktní požadavky nemá. Je to podobný problém jako u toho dial-upu, a pro zákazníka "nepořádného" ISP daleko horší. Změna poskytovatele dial-upu trvá pár minut a stojí pár korun. Změna poskytovatele mikrovlny nebo kabelovky v nejlepším případě trvá několik dnů a stojí několik tisíc. V horším případě také nemusí být vůbec možná.
co s forwardovanymi zpravami (FROM se nemeni, ale zpravu odesila "divny" stroj) vcetne emailovych konferenci
Ve většině případů (zejména u těch diskusních listů) se From mění (tedy adresa z obálky).
a co s chybovymi hlasenimi (FROM je <> - proti cemu budete co overovat ?)
Tohle zrovna považuji za určitý přežitek poplatný době vzniku SMTP. Osobně bych tuto specialitu vůbec nepostrádal. Ale je tu samozřejmě možnost tento typ zpráv z požadavku na ověření odesílatele vyjmout.
implementacni problemy vaseho reseni jsou znacne a vyzadovaly by patrne pomerne zasadni zasahy do systemu dorucovani zprav.
V tom jsou na tom oba systémy stejně. Pokud by to mělo dojít tak daleko, že by bylo možné bezproblémově používat e-mail a přitom přijímat jen ověřenou poštu (ať už přes IP nebo e-mailovou adresu), znamenalo by to výměnu software naprosté většiny MTA a globální zásahy do DNS. A jak už jsem napsal, nejsem si jistý, jestli přínosy kteréhokoli z těch dvou modelů za takový obrovský zásah stojí. Protože potom by už stálo za úvahu, zda by se srovnatelnými nároky nešlo realizovat např. kompletní přechod na autentizovanou SMTP komunikaci, jejíž přínos by byl IMHO podstatně větší.
Adresa <> je mozna prezitek presto je to dosud dulezita a integralni soucast SMTP protokolu - je to zpusob, jak posilat chybova hlaseni bez zacykleni. Vas nazor na zbytecnost mechanismu pro hlaseni problemu s dorucenim pravdepodobne nechapu spravne. Verim, ze vam nechybi, ale v tom protokolu by vazne chybel a musely by byt nahrazeny necim jinym. Mimochodem, ja se za kazdou cenu snazim vyhnout zpetne nekompatibilnim zasahum do existujicich protokolu (zejmena SMTP). To pravdepodobnost vzniku, nasazeni a skutecneho rozsireni takoveho systemu IMHO vyrazne snizuje. Muj navrh nevyzaduje takove zasahy a tak pripousti dokonce pozvolne nasazovani - i kdyz nakonec skutecne smeruje k vymene vsech MTA. Vy, zda se, budete potrebovat zpetne nekompatibilni zasah do SMTP - a to samo je vec, ktera, IMHO, prakticky anuluje sanci na prosazeni takoveho systemu.
A ze se i v poslednim odstavci stale vracite k myslence, ze autentizace vyresi problem SPAMingu - naposled se pokusim tuto utkvelou ideu vyvratit. Nevyresi. Potrebny el. podpis musi byt natolik dosazitelny (tedy laciny) aby na nej dosahly vsichni uzivatele - tedy nejen vy se svym mesicnim prijmem, ale vsichni. Tedy musi byt pomerne hodne laciny. Jakmile bude hodne laciny, nebude problem si jich poridit hromadu - nariklad na kazdou SPAMerskou davku jeden. To sice SPAMovani, jako reklamni metodu, mirne zdrazi , presto to stale bude nejlacinejsi zpusob jak reklamne zasahnout obrovske mnostvi lidi. Autentizaci dokazete mozna vyresit "nekomercni" SPAMy - ano, je to hezke, ale tech je preci jen v celkovem objemu vyrazna mensina. Dokud me nekdo nepresvedci, ze tohle neni pravda, pak trvam na svem - autentizace problemy el. posty s nevyzadanymi zasilkami nevyresi. A narazite i na principialni problemy - autentizace je vzdy end-to-end problem mezi tim, kdo tvrdi, ze nekym je a tim, kdo mu to veri. Nedomnivate se, predpokladam, ze el. podpisy zavedly nejaky OBJEKTIVNI (tedy na osobe prijemce nezavisly) model overovani autenticity odesilatele. Vas system by tedy vyloucil, aby uzivatele-prijemci v jedne domene mely rodilne predstavy o tom, ktery podpis je autenticky a ktery nikoliv. Policy by musela byt centralne urcena spravcem prijemcovy domeny. Ledaze predpokladate, ze dopis bude mit podpisy nejmene dva nezavisle - jeden urceny pro transportni system a druhy pro koncoveho uzivatele.
Dokud nebude efektivní možnost, jak přidělit dostatek skutečných IP adres i těmto uživatelům, tak je potřeba s nimi počítat, ať se nám to líbí nebo ne. Stejně tak jako se mi stýská po starých dobrých časech, kdy x@y znamenalo uživatel x na počítači y a kdy poslat 1MB mail nebo mail na sto adres (až na samozřejmé výjimky) znamenalo riskovat, že si nějakou dobu nepošlu vůbec žádný mail, ale beru na vědomí, že staré dobré časy jsou určeny pouze k tomu, aby se o nich vyprávělo potomkům, a že realita dnešní doby je jiná.
Vas nazor na zbytecnost mechanismu pro hlaseni problemu s dorucenim pravdepodobne nechapu spravne. Verim, ze vam nechybi, ale v tom protokolu by vazne chybel a musely by byt nahrazeny necim jinym.
Netvrdil jsem přeci, že nemá existovat způsob, jak posílat chybová hlášení. Pouze tvrdím, že způsob, jakým je to v současné době řešeno, je přežitkem. Pokud už by se vymýšlel tak zásadní zásah do systému posílání mailů, že by vyžadoval výměnu (téměř) všech MTA, pak bych považoval za vhodné odstranit i tento relikt.
Muj navrh nevyzaduje takove zasahy a tak pripousti dokonce pozvolne nasazovani - i kdyz nakonec skutecne smeruje k vymene vsech MTA. Vy, zda se, budete potrebovat zpetne nekompatibilni zasah do SMTP - a to samo je vec, ktera, IMHO, prakticky anuluje sanci na prosazeni takoveho systemu.
Jestli jsem to pochopil správně, ten systém by mi měl umožnit zavést politiku, že odmítnu jakékoli spojení, z něhož nebude patrná IP adresa zdroje nebo nebudu schopen ověřit, že IP adresa MTA, který mne kontaktoval, není oprávněna fungovat jako relay pro ten zdroj. A to nemohu efektivně zavést do té doby, než bude naprostá většina MTA a domén tyto mechanismy podporovat. Můj názor je ten, že výměna naprosté většiny MTA je natolik kritickou záležitostí, že výměna (E)SMTP za nějaký XSMTP už náročnost takového procesu zvýší relativně málo. Na podobné filosofii je založen i IPv6 - když už bude potřeba tak jako tak předělat implementaci sítě (prakticky) všech hostů, tak ať to stojí za to.
autentizace problemy el. posty s nevyzadanymi zasilkami nevyresi
Nemyslím si, že autentizace vyřeší problém spamu. Problém spamu nevyřeší autentizace, ale stejně tak ho nevyřeší váš model, můj model, zákonná opatření, IPsec ani nic jiného. Problém spamu by vyřešila jediná věc: pokud by nikdy nikdo za žádných okolností neklikl na jediný odkaz ve spamu a pokud by si nikdy nikdo nekoupil žádný výrobek, který je propagován formou spamu. To je bohužel nereálné. Všechny zmíněné mechanismy mohou spam pouze do určité míry omezit a musíme si položit otázku, zda by náklady a negativní efekty těchto metod byly vyváženy jejich přínosem. A já jsem přesvědčen, že odpověď zní v obou diskutovaných případech ne. V případě autentizace o tom tak striktně přesvědčen nejsem, protože je potřeba brát v úvahu i jiné výhody, které nesouvisejí bezprostředně se spamem.
Je zasadni rozdil rozsirit (zpetne kompatibilne) funkcionalitu SMTP a zmenit (zpetne nekompatibilne) funkcionalitu. I kdyby oboji vyzadovalo vymenu vsech MTA, pak to prvni ji umoznuje provest postupne, kdezto to druhe nikoli - a proto to povazuji za nerealne. A - pochopil jste to nespravne. Predavani zdrojove IP je dobre jen k tomu abych mohl (jako vyraz dobre vule) blokovat maily z teto jedine IP misto toho, abych zablokoval IP MTA a tim blokoval celou sit coz udelam u tech MTA, ktere nespolupracuji a IP adresu zdroje utaji. Tim cinim z predavani IP ciste dobrovolnou a volitelnou zalezitost - jakysi vyraz dobre vule ze strany odesilajiciho MTA umoznit blokovani s lepsi granularitou coz je v jeho zajmu - ale muze se rozhodnout teto moznosti nevyuzit a IP nepredavat, pak samozrejme ponese nasledky.
Co se autentizace tyce - neodmitam ji proto, ze problem nevyresi dokonale. Odmitam se o ni bavit v diskusi tykajici se reseni problemu se SPAMem proto, ze problem SPAMu neresi prakticky vubec - jeji vliv bude neporovnatelne nizsi nez lze dosahnout jinymi metodami a SPAM tedy bude treba resit jinak. To, jestli ma nebo nema autentizace nejake dalsi vlastnosti vyhody a nevyhody s resenim tohoto problemu nesouvisejici je vec na jinou diskusi a ne diskusi tykajici se reseni problemu se SPAMem pro jehoz reseni nemuze autentizace pravdepodobne nabidnout reseni vubec, a pokud preci jen ano, tak velice narocne a jen mizive ucinne.
Obávám se, že situace je daleko horší (a hlavně čím dál horší). Takových klientů je (přinejmenším v ČR) poměrně dost, mnohé z nich by migrace stála poměrně dost peněz a pro mnohé není ani dost dobře možná.
Vize ve druhém odstavci vypadá na první pohled pěkně, ale trpí jednou podstatnou vadou. Vzhledem k tomu, že IP adresa v dnešním Internetu v mnoha případech (překlady, dial-up) odesílatele spamu neidentifikuje, znepříjemním jejím zablokováním život v první řadě sobě, ve druhé všem, kdo takovou adresu mohou dostat (ano, někde mezi nimi je i ten skutečný viník - ale je jen jeden, ostatní za nic nemohou) a teprve ve třetí řadě providerovi, který by s tím měl něco dělat. A jak jsem vyrozuměl, ti neviní zákazníci by měli vyvinout tlak na providera (ať už tím, že mu budou nadávat na hotline, nebo tím, že přejdou jinam), aby vyvinul tlak na toho, který to zavinil (pokud je ho vůbec nějak schopen identifikovat - což u "free" dial-upů není zrovna jednoduché) - případně mu v tom nějakým hypotetickým způsobem zabránil preventivně.
Přeženu-li to, trochu mi taková idea připomíná myšlenkové schéma určitého typu filmů: stane se zločin, policie chytí prvního, kdo jí přijde pod ruku a ten pak ve vlastním zájmu dopadne a usvědčí skutečného pachatele; pro policii je to samozřejmě jednodušší a pohodlnější, jenže morálně to asi neobstojí. Takže když mi někdo pošle spam, já budu odmítat maily poslané z téže IP adresy. Co na tom, že skutečný viník ji dost možná už nikdy nedostane a že místo něj budu odmítat maily náhodných zákazníků téhož providera. Je přeci v jejich zájmu, aby toho providera donutili něco s tím udělat. Ve výsledku by to asi spíš dopadlo tak, že ti zákazníci by usoudili, že to nemám v hlavě v pořádku, a raději by se mnou přestali komunikovat (a osobně bych se jim ani nedivil).
K třetímu odstavci: autentizace (samozřejmě záleží na přesné definici, pod tím pojmem si lze představit mnoho různých mechanismů), stejně jako jiné metody, boj proti spamu zjednodušuje tím, že mi umožní zjistit, kdo ten spam skutečně poslal, a zablokovat jeho identitu. Je samozřejmě pravda, že pokud bude umožněno jednomu subjektu používat více identit, může je používat jednu po druhé a blokování se tak vyhnout. Ale to je prostě principiální problém metody, který se dá odstranit jedině použitím identit, které budou jednoznačně přiřazeny subjektům/osobám (a něco takového by asi neprošlo přes ochránce lidských práv). Proto jsem několikrát zdůraznil, že to za řešení nepovažuji.
Nemá smysl si namlouvat, že metoda blokování podle IP adres zdroje tento problém nemá. Má ho v nemenší míře - záškodník může střídat IP adresy ještě snáze než identity pro autentizaci - dynamicky přidělované IP to dokonce budou dělat za něj. Rozdíl je pouze v tom, že na stejné IP adrese budou společně s ním systémově a plánovitě pranýřováni nevinní kolemjdoucí. Jakkoli mi spam leze na nervy, pořád jsem nucen odmítnutí řádného mailu považovat za řádově horší chybu systému než přijetí spamu. Takže smysl by to (z mého pohledu) mohlo mít teprve po rozšíření IPv6, který poskytuje účinné prostředky pro eliminaci tohoto nežádoucího efektu.
Uz jen kratce bych se pozastavil nad jednim omylem, ktery bych od vas, pri vasich zkusenostech, rozhodne necekal - NENI pravda, ze IP adresy lze stridat stejne snadno jako emailove adresy. IP adresu vam musi nekdo pridelit, tu si rozhodne nemuzete "jen tak" vzit. Shodou okolnosti je prideluje ten, komu budou, kdyz je prideli neuvazene, blokovany a kdo s tim bude mit jen starosti - je tedy na nem, aby je prideloval odpovedne (ojedinele excesy jsou pripustne a pocita se s nimi jako nutnym zlem). Pokud ale budete tvrdit, ze takovou odpovednost po poskytovateli konektivity zadat nelze, pak jen rikate, ze problem je zcela neresitelny - pokud nedokaze SPAMera eliminovat ten, kdo mu dava konektivitu, nedokaze to naprosto nikdo vzdalenejsi.
Zbytek jen heslovite:
argument, ze ISP pri znalosti IP a casu neni schopen identifikovat a eliminovat SPAMujiciho zakaznika jiste nemyslite vazne
S oběma tvrzeními bych bez výhrad souhlasil, kdyby neexistovaly věci jako je "free" dial-up. U takého typu připojení se o zákazníkovi vůbec nedá mluvit. A je samozřejmě úplně jedno, zda je to dotaženo až do té míry, že se klient vůbec nepřihlašuje (iDnes, Atlas) nebo se pouze skrývá pod symbolickým přihlašovacím jménem a při registraci vyplní pár vymyšlených údajů. Dokud bude existovat tento typ připojení k Internetu, musím trvat na tom, co jsem napsal.
i v pripade, ze jde o "free dial-up", ma skutecny postytovatel sluzeb k dispozici telefonni cislo, ze ktereho se telefonovalo. ISP tedy muze napriklad zablokovat telefonni cislo stanice, ze ktere se volalo, pripadne tyto informaci poskytnout represivnim organum.
MK
Pri formovani meho nazoru mi pomohly nasledujici materialy:
draft-crocker-spam-techconsider-02.txt
rfc2505.txt
draft-fecyk-dsprotocol-04.txt
draft-fakih-amdp-00.txt
draft-danisch-dns-rr-smtp-02.txt
draft-vixie-repudiating-mail-from.txt
asrg-emailpathverification-presentation.pdf
IETF ASRG WG mailinglist
Z toho, mimochodem, plyne, ze mnoho lidi premysli spis smerem k vasemu typu reseni - nicmene, ja jsem zvykly byt mimo hlavni proud ... ;-)
Z toho bych si vrásky nedělal. Kdybych takhle uvažoval, asi bych tento příspěvek nepsal v Mozille na Linuxu (a to to ani není Redhat :-) ). Na ty drafty se příležitostně zkusím podívat.