Fórum Root.cz
Hlavní témata => Server => Téma založeno: Ondřej Novák 10. 12. 2013, 13:36:50
-
Ahoj, jen chci prodiskutovat takový nápad. Třeba už někoho napadl a třeba to někdo dávno implementuje.
Myšlenka boje proti spamu je založená na tom, že odesílatel musí spočítat nějakou obtížnou výpočetní úlohu, aby jeho e-mail byl přijat. S využitím znalostí okolo fungování bitcoinů mě jednoduše napadlo, že by se taková úloha mohla počítat podobně, jako když se doluje blok. Samozřejmě velmi zjednodušeně a s menší složitosti
Příklad: Odesílám zprávu A příjemci B. K výpočtu potřebuju spočítat dodatek C (jako řetězec), který odpovídá zadané složitosti k.
To číslo určuje, kolik bitů (nebo čtveřic?) zprava nějaké hashovací funkce (například SHA) provedené nad A+B+C musí být nastaveno na nulu.
Výpočet je tedy snadný, najít takový C, aby hash(A+B+C) = 000... kde nějaké K určuje počet počátečních nul.
Do protokolu SMTP by se to zapojilo snadno. Přibyla by nějaká položka mezi RPCT TO a DATA, kam by odesílatel zadal obsah řetězce C. SMTP server by provedl operaci hash(A+B+C) a zkontroloval by, že výsledný HASH opravdu odpovídá zadané složitosti. Pokud by neodpovídal, nebo by položka chyběla, odmítl by e-mail převzít a v chybové zprávě by sdělil, jak velkou složitost vyžaduje k přijetí e-mailu.
Nasazení mechanismu do existujících SMTP by byla složitější. Muselo by se to vyhlásit a musel by to nasadit velký poskytovatel (Google / Seznam, atd). Nejprve by se to nasadilo na IP z blacklistů a případně na způsob jak obejít greylisting. Následně by se tím bylo možné obcházet nějaká příliš přísná pravidla spamfiltru. Zároveň by se vydal nějaký plugin do existujícíh MX serverů, které by to uměly počítat. Část zátěže by se dala přenést přímo na uživatele (počítat by to musel přímo klient, nebo webová stránka webmailu). Postupně by se to zavedlo jako virtuální platidlo za příjem zprávy (platí se spotřebovaným výkonem)
Co si o to myslíte?
-
Ano, už to někoho napadlo: Bitmessage (http://en.wikipedia.org/wiki/Bitmessage)
-
Stara myslienka, precitaj napr Pricing via Processing or Combatting Junk Mail, Cynthia Dwork, Moni Naor, Crypto '92
-
Já o Bitcoinech vím kulový, ale nějak to celý nechápu... Takže tři otázky:
1. Odesílám email s obsahem A, příjemce je B, můj komp (poštovní server) k tomu spočte a přiloží C tak, aby vyšel nějaký "relativně konkrétní" HASH. Chápu dobře?
2. Příjemce (poštovní server) pak provede hash obsahu A, příjemce B a dodaného obsahu C a kouknul by, jestli vyšlo co mělo a pokud jo, není to spam?
3. A Spambot nebude moct spočítat C a poslat ho spolu se spam obsahem A příjemci B?
-
Uzasnej napad na DOS ... mas vubec predstavu, kolik mailu takovej mailserver zpracovava?
-
Ano, už to někoho napadlo: Bitmessage (http://en.wikipedia.org/wiki/Bitmessage)
Ked som to pochopil dobre, tak mu ide o boj proti spamu. To bolo prezentovane uz skor v clanku, ktory som napisal. Dalsie info o pocitani dost podobnom tomu popisanemu je na http://www.hashcash.org/
-
Uzasnej napad na DOS ... mas vubec predstavu, kolik mailu takovej mailserver zpracovava?
Slozitost je na strane klienta, overeni mailserverem by bylo mnohoradove snazsi.
Ja spis vidim problem v tom, ze toto reseni nefunguje, pouze spammerum lehce ztizi praci.
Aby tento system mohl v praxi fungovat, je nutne, aby i podprumerny pocitac byl schopen odeslat mail do maximalne nekolika sekund. Ja sam vnimam hranici, kdy me pomalost doruceni mailu zacne vadit, na cca 10 sekundach (typicky pri registraci na nejakem serveru, pripadne pri email-alertu z nagiosu apod.).
Takze pokud by spammer mohl poslat jeden spam-mail za 10 sekund, realne by mu to spamovani prilis neztizilo.
A pokud se podrzime analogie s BTC - spammer si poridi "ASIC-Miner" a spamuje jako drive.
Takze toto reseni vytvori komplikace v prechodu na nove smtp servery, zvysi spotrebe proudu, snizi vydrz zarizeni na baterie, zpomali beznou emailovou komunikaci a spammerum nijak neublizi.
-
belzebub mi to vysvětlil (ačkoliv na mě přímo nereagoval).
Takže spammer by to měl těžší kvůli tomu, že by potřeboval velký výkon na rozeslání spousty emailů v krátkém čase. Nijak jinak.
Co by na ten Tvuj nápad řekla třeba taková Alza, která odesílá (dle serveru Root.cz) až 50 000 objednávek denně? Tj. 50 000 emailů potvrzujících objednávku a dalších 50 000 emailů z předchozího dne o expedici/vyzvednutí objednávky. 100 000 emailů za 24 hodin, to je víc než jeden za sekundu. Asi by neměli radost z Tvýho nápadu...
To už bych viděl cestu v šifrování emailů. Nemám email jak rozšifrovat (tj. přečíst) = nezajímá mě. Otázka by byla, co s emailama od lidí, který si mě někde našli a chtěj se mě na něco zeptat (nemám jejich klíč = spadnou do spamu).
-
Zasadny problem vidim v tom, ze nie je spammer ako spammer. Vy hadzete vsetkych do jedneho vreca, kym hromadne posielanie mailov ludom, ktori sa dobrovolne prihlasili na ich odber je uplne v poriadku. Navyse riesit spamm na urovni spammera je ako riesit bankove lupeze na urovni lupica.
-
Toto riešenie sa vynorí každú chvíľu. Zaujímalo by ma či niekto vypátra pôvodného vynálezcu. Už v roku 2004 provokoval Bill Gates že elektronické poštové známky založené na zložitých výpočtoch eliminujú SPAM. http://news.bbc.co.uk/2/hi/technology/3426367.stm
Kongress ho poslal kade ľahšie, a neskôr z toho ťažil napríklad google keď nasadil captcha na skenovanie kníh.
-
Takze pokud by spammer mohl poslat jeden spam-mail za 10 sekund, realne by mu to spamovani prilis neztizilo.
A pokud se podrzime analogie s BTC - spammer si poridi "ASIC-Miner" a spamuje jako drive.
Hackuty PC v univerzitni siti dokaze rozeslat okolo 10000 spamu za hodinu. Spameri nepouzivaji vlastni servery
ale botnety. Navrhovane reseni by nejspise snizilo objem spamu odesilaneho ze zombie pocitacu - otazka je jestli by uzitek prevazil "transformacni" naklady.
-
Zasadny problem vidim v tom, ze nie je spammer ako spammer. Vy hadzete vsetkych do jedneho vreca, kym hromadne posielanie mailov ludom, ktori sa dobrovolne prihlasili na ich odber je uplne v poriadku. Navyse riesit spamm na urovni spammera je ako riesit bankove lupeze na urovni lupica.
+1, ja posielam nieco cez milion mailov za 5 hodin a toto by mi robilo dost velke problemy.
-
Ono je mozne si hrat se slozitosti. Pokud alza rozesila nejake emaily, pak to dela z nejake farmy, ktera ma vesmes stejne IP adresy. Takovee emaily by nemusely mit velkou slozitost. naopak emaily poslane primo z outlooka by mohly mit vetsi slozitost nez webmaily jejiz garantem by byl poskytovatel. Hash s vyssi slozitosti napriklad projde i mx serverem vyzadujici nizsi slozitost.
Dale maily prichazejici z ip adres ktere nejsou tak casto oznaceny za spam mohou byt prijimany s nizsi slozitosti nez emaily z uplne neznamych adres. Da se to postavit podobne jako greylisting. V soucasnem systemu mam moznost jen blacklistovat IP adresu. Ja ale nechci, ja treba chci, aby email dosel, ale mohu vyzadovat od odesilatele vyssi slozitost, jelikost je znam, ze casto rozesila spam.
Vyuzit se to da ruzne
-
Beru namitku pro ruzne potvrzovaci a jine emaily, na druhou stranu to dneska lze resit primo vypoctem v prohlizeci. Co treba vnimam pozitivne, tak by to vytvorilo tlak konecne presunout newslettery a dalsi reklamni materialy na systemy RSS/ATOM.
-
Co si o to myslíte?
Opět jste nezklamal... ;D
-
S ohledem na to, že nám EU zakazuje žárovky a nutí nás používat úsporné zářivky, tak by asi brzo někoho napadlo, proč by mělo odeslání emailu spotřebovat tolik výkonu. Asi by to udělalo radost řadě výrobců mobilních zařízení, uživatelé by si museli houfně kupovat nové mobily s nejvýkonnějšími mobilními procesory, aby odeslání emailu netrvalo déle než jeho napsání. Případně by si provideři web mailu museli zněkolikanásobit výkon svých serverů.
Zkrátka mi to přijde jako návrh bojovat se spamem tím, že se budeme sami střílet do vlastní nohy. A doufat, že spammer to udělá taky a že ho to tudíž bude bolet více. A v neposlední řadě plánujeme zavedení výjimek "pro ty co to doopravdy potřebují", nejlépe udělované nějakou "obecně uznávanou vyšší autoritou".
-
Mě by se možná líbilo, kdyby přijetí mailu bylo šlo podmínit nějakou premií (např btc) pro příjemce...zkrátka, kdo mi nepošle 0.1mBTC, tak mi nestojí za to, abych jeho mail četl...adresy osob, které mám v adresáři jsou z poplatku samozřejmě vyloučeny
Samozřejmě to má kupu vedlejších účinků (minimálně bobtnání blockchainu)
-
Takže když budu chtít přijmout email, tak si nejprve musím koupit sálovej počítač, abych měl dostatečný výkon na to, jestli je email určen pro mne, nebo ne. Spam se nejlépe řeší na bázi filtrů. Třeba takovej thunderbird má ten filtr na velmi slušné úrovni. Jednou klikneš a pak Ti to zahazuje. Toto třídění je mnohem rychlejší, než nějaké počítání.
-
I když tahle úloha bude dostatečně jednoduchá, aby mě příliš neobtěžovala na desktopu a zároveň dostatečně složitá, aby měla alespoň trošku smysl, tak dopad na mobil bude zdrcující. Spameří posílají skrze botnety, takže výpočetního výkonu mají na rozdávání (či spíš prodávání a to doslova).
Kdysi se mi tahle myšlenka líbila, ale se vzrůstajícím významem mobilní výpočetní techniky ho považují za zcestný.
-
Když budete chtít odeslat email cizí osobě, tak buď budete muset pořídít salový počítač (asi ne :) )... nebo si za pár drobných koupíte trošku kyberměny.
V opačném případě riskujete, že se váš email na straně příjemce zařadí do spamu :)
-
To se může týkat jen lidí, kteří si na svým linuxu nainstalují postfix na odesílání svých e-mailů. Velcí poskytovalé posílající hromady e-mailů asi nebudou mít tak vysoce nastavenou obtížnost na příjmu, jako neznámí odesílači.
E-mailoví klienti v mobilu často posílají e-mail přes nějakého poskytovatele, třeba přes gmail.com. Předpokládám, že jejich MX brána bude třeba na straně Seznamu whitelistována. A naopak.
-
Ještě k botnetům. Pořídit si velký botnet není moc levné. Na jednu stranu, spamery s botnetem to asi nezastavý. Ale nejspíš se jim to trošku podraží. Navíc to zpomalí ty zombie. Odeslat e-mail stojí nula nula nic výkon. Pokud ale začne zombie něco zběsile počítat, mohl by si toho všimnout i majitel
-
spamery s botnetem to asi nezastavý
A to je pravdepodobne duvod, proc se tato myslenka nikdy realne neujala. Pro omezeni spamu placnu treba o 10% nema smysl zavadet zeslozitujici princip do zabehane komunikace a opruzovat naprostou vetsinu uzivatelu, kteri nespamuji a ani se k tomu nechystaji.
-
Ondřej Novák: Jaké máš reálné zkušenosti s provozem poštovního serveru? Ze svých zkušeností můžu říct, že uživatele mnohem víc naštveš, když mu nějaký mail nepřijde, než když mu přijde jeden, dva spamy denně. Není vetší opruz, než když s někým visíš na telefonu a opakovaně se ptáš, jestli už to došlo a znovu si hláskujete email. I takový graylisting dokáže pěkně naštvat. Už vidím, jak vysvětluji zákazníkovi, že zahazuji k němu směřující poptávky, protože odesilatel nespočítal haš.
Když chceš whitelistovat velké odesilatele, tak kdo je velký? Seznam ano? A co Centrum, volny.cz, ... ? A slyšeli o nich třeba v Kanadě, aby jim stálo za to whitelistovat? Menší se budou bouřít a výrobci antispamu je v tom budou podporovat.
Současné antispamy jsou na docela slušné úrovni a nějaké Viagry nejsou problém. Spíš mě obtěžuje "legální" spam, kdy mi chodí mraky pochybných newsletteru, které chodí na základě registrací na různé servery a poskytování databází dalším subjektům, jak mívají ve všeobecných podmínkách. To je obzvlášť těžké fitrovat, protože co je pro jednoho spam, tak má pro člověka o kancelář vedle určitou informační hodnu a těm firmám se to i tak bude vyplácet posílat. Spočítání jednoduchého haše nebude velká nákladová položka.
-
Ondřej Novák: Jaké máš reálné zkušenosti s provozem poštovního serveru? Ze svých zkušeností můžu říct, že uživatele mnohem víc naštveš, když mu nějaký mail nepřijde, než když mu přijde jeden, dva spamy denně. Není vetší opruz, než když s někým visíš
Mě se líbí, že tady každý hned ví, že se bude něco odesílat hrozně dlouho. Ten výpočet se musí dělat co nejblíže ke klientovi, ideálně přímo na straně klienta... v Outlooku... v javascriptu na webovém rozhraní, atd... pokud to nejde, měl by to dělat první server u klienta.
Jakmile je zpráva podepsána hashem, už se nikde nezdržuje. Tedy pokud ten hash nemá menší složitost, než požaduje příjemce. Pak se asi nejspíš vrátí jako nedoručená.
Tu konstanta složitosti tu nikdo neurčoval. Může být nastavena tak, aby to běžnému počítači trvalo pár sekund, třeba 3-5. Během té doby uživatel ví, že dochází "platbě" za odeslání výkonem.
A ještě jedna poznámka. Botnety jsou drahé. Běžný spammer si vystačí s pár zombie počítači, které to tam sypou to tisících za minutu. Snížit jim to na desetinu (tedy místo 1000 za minutu to bude 100 za minutu), znamená to, že spammer si musí pořídit 10x větší botnet a to už může být treshold, který způsobí, že některé firmy se na tento způsob marketingu vykašlou... bude pro ně ... při určité slabé účinnosti ... příliš nákladný. A o to jde. Dívejte se na to ekonomicky.
-
Čéče Ondřeji, ty jsi ocitoval otázku, ale zapomněl odpovědět. Jaké máš reálné zkušenosti? Na mě to působí, že s e-mailem naprosto nulové.
-
Zkrátka mi to přijde jako návrh bojovat se spamem tím, že se budeme sami střílet do vlastní nohy.
Však to je právě ten princip převzatý z BitCoinu - ten taky podobným způsobem bojuje proti bublině na fiat měnách ;)
Ten výpočet se musí dělat co nejblíže ke klientovi, ideálně přímo na straně klienta... v Outlooku... v javascriptu na webovém rozhraní, atd... pokud to nejde, měl by to dělat první server u klienta. Jakmile je zpráva podepsána hashem, už se nikde nezdržuje. Tedy pokud ten hash nemá menší složitost, než požaduje příjemce. Pak se asi nejspíš vrátí jako nedoručená.
[...] ... příliš nákladný. A o to jde. Dívejte se na to ekonomicky.
Ondřeji, myslím, že ti bylo celkem jasně a srozumitelně řečeno, že takové návrhy už tu byly dávno. A neujaly se. Než znovu vymýšlet něco, co už někdo vymyslel, se prosím seznam s analýzami, proč to tenkrát nevyšlo. A napiš nám sem, co jsi zjistil. To bude pro všechny podstatně přínosnější, než když tady budeš plácat játrama o tom, co tě tak napadlo večer ve vaně poté, co ses vykašlal na bitcoinovou burzu (sorry za tón, ale imho sis ho vysloužil sám)
Opět jste nezklamal... ;D
Říkám si, že to je super, když mají lidi velké nápady a velké ambice...
...ale pak si zase říkám, že to zas tak super není ;)
-
Čéče Ondřeji, ty jsi ocitoval otázku, ale zapomněl odpovědět. Jaké máš reálné zkušenosti? Na mě to působí, že s e-mailem naprosto nulové.
No bude stačit, když řeknu, že v ponděli mi jeden newsletter od kasa.cz položil čtyři stroje ve dvou lokalitách? Naštestí to byla moje chyba a rychle jsme to s adminy opravili.
-
Než znovu vymýšlet něco, co už někdo vymyslel, se prosím seznam s analýzami, proč to tenkrát nevyšlo.
Já bych si možná dokonce dovolil i tvrdit, že tady není moc co vymýšlet. Problém není technologický, ale ekonomický. Hudební průmysl léta neúspěšně bojuje s warezem. Různými drahými a nespolehlivými nesmysly typu DRM, Cactus Data Shield a podobně spíše komplikoval život platícím zákazníkům a nikam to nevedlo. Pak přišly levné paušály za přístupy k obrovským hudebním archivům a situace se začala měnit.
V mé reálné poštovní schránce je nesrovnatelně více spamu, než v té virtuální a přitom náklady na výtisk a distribuci jsou o několik řádu jinde a stejně se to vyplácí. Klidně můžeme náklady na technologie vyšroubovat do srovnatelných výšin a stejně nám to nepomůže. To už raději tuny relativně snadno odfiltrovaného spamu, jako je tomu nyní, než drahé sofistikované metody na obou stranách barikády.
-
Panove, ja vazne nevim co resite ...
Pouzivejte SSL - nic vam nebrani komunikovat jen s protejsky, kterych certifikaty znate a akceptujete. A je po spamu, na 100%. Vazne netreba vymejslet kolo ... i kdyz to je v IT asi celkem standardni postup, vymejslet zavirak na votvirak.
Kdyz nic jinyho, kazdej muze mail podepsat, a akceptuju jen maily podepsany (!pro me!) duveryhodnym certifikatem (klidne si ho muze vydat protistrana a ja si ho dam do seznamu tech, ktery akceptuju). Samo, vyzaduje (jaksi z principu) pouzivat normalniho mail klienta, nikoli webove sracky. Certifikat ulozeny kdesi na netu jako by neexistoval - za tyden ho bude pouzivat 100 000 spameru.
-
Zkrátka mi to přijde jako návrh bojovat se spamem tím, že se budeme sami střílet do vlastní nohy.
Však to je právě ten princip převzatý z BitCoinu - ten taky podobným způsobem bojuje proti bublině na fiat měnách ;)
ROTFLMAO! :D
Naštestí to byla moje chyba a rychle jsme to s adminy opravili.
Asi se budu opakovat... ale - opět jste nezklamal. ;D ;D ;D
-
To už raději tuny relativně snadno odfiltrovaného spamu, jako je tomu nyní, než drahé sofistikované metody na obou stranách barikády.
To zcela vystihuje soucanou situaci. Videli jste nekdo v posledni dobe spam? Naprosta vetsina jsou totalni blaboly a je to schvalne. Spameri posilaji obrovske mnozstvi balastu, cimz oblbuji stroje, snazici se naucit, co je spam, a zaroven vytvareji pocit uspesne obrany - poplacame se po zadech, ze "pres nas filtr projde jen 5%", a principialni reseni se ani nehleda. Pokud by bylo trochu slozitejsi generovat kvantitu, spameri zlepsi kvalitu a jsou stale v pohode. Neni vubec nic tezkeho analyzovat vetsinou verejne antispamove nastroje a databaze a generovat maily, ktere jimi projdou, v tomto bude autor spamu vzdy o krok napred.
-
Musím říci, že se nám kdysi stalo že nám spadlo víc serverů najednou, ale jako kladné reference jsem to nikde neuváděl, to mě nenapadlo. ;D
Čéče Ondřeji, ty jsi ocitoval otázku, ale zapomněl odpovědět. Jaké máš reálné zkušenosti? Na mě to působí, že s e-mailem naprosto nulové.
No bude stačit, když řeknu, že v ponděli mi jeden newsletter od kasa.cz položil čtyři stroje ve dvou lokalitách? Naštestí to byla moje chyba a rychle jsme to s adminy opravili.
-
Zkrátka mi to přijde jako návrh bojovat se spamem tím, že se budeme sami střílet do vlastní nohy. A doufat, že spammer to udělá taky a že ho to tudíž bude bolet více. A v neposlední řadě plánujeme zavedení výjimek "pro ty co to doopravdy potřebují", nejlépe udělované nějakou "obecně uznávanou vyšší autoritou".
Krasne shrnuto. Sam bych to lepe nenapsal. Skoda, ze pan Novak opet ignoruje realitu a svou "viru" si nenecha zviklat.
-
Musím říci, že se nám kdysi stalo že nám spadlo víc serverů najednou, ale jako kladné reference jsem to nikde neuváděl, to mě nenapadlo. ;D
Já osobně bych nikdy nepřijal programátora, který by tvrdil, že nikdy neudělal chybu. Protože vím, že lže. To radši přijmu člověka, který jich za život udělal stovky a staly se mu větší průsery, pokud je dokázal rychle a operativně vyřešit. Chyby děláme každý a kolikrát to ani nemusí být chyba se kterou se dalo dopředu počítat (zrovna v tomto případě to bylo nevhodně navržené SQL query, které při trošku větší zátěži vytížilo databázi deadlockama... to fakt nikdo nemohl dopředu vědět)
-
Asi se budu opakovat... ale - opět jste nezklamal. ;D ;D ;D
Jsem rád, že se bavíte. Většina takových jako vy to totiž řeší tím, že to hodí na někoho jiného, nakoupí víc strojů a vyplácají tisíce člověkohodin, než aby udělali pořádnou analýzu logů a pokusili se zjistit, kde je chyba. Proto naštěstí to byla chyba. Mnohem horší by bylo, kdyby se ukázalo, že to ty stroje fakt nezvládají.
Ale ani vy mě nikdy nezklamete. Konečně, jste tu ikona, kterou nikdo nebere vážně :P
-
To snad není pravda. Ondřeji, já se zeptal na zkušenosti s e-mailovými servery. Na to jste mi odepsal něco jako: Jéje, těch mam, nedávno jsem odpálil několik serverů. Na to jsem napsal, že tím jsem se nikdy nikde nechlubil a nepovažuji to za reference. Na to opět vy, že prográmátor umí uznat chybu. Takto chronologicky seřazeno vám to dává smysl a nepřipadáte si jako blbec?
-
nepřipadáte si jako blbec?
Ondřej není žádný blbec, byl s ním rozhovor na rootu!
-
... zrovna v tomto případě to bylo nevhodně navržené SQL query, které při trošku větší zátěži vytížilo databázi deadlockama... to fakt nikdo nemohl dopředu vědět
Nemůžu si pomoct, ale tohle mi nedává smysl. Jak se dá vytížit databáze deadlockem? Při deadlocku na sebe čeká víc vláken, ale pasivně. A není to nějaké přetížení, ale kompletní zámrz.
Mimochodem na předcházení deadlocku jsou běžné postupy, jako zamykat vždycky ve stejném pořadí. Dost mě překvapuje, že by nějaký databázový server tohle neimplementoval. Obzvlášť když optimalizátor může SQL přeuspořádat jak se mu zlíbí.
Přes databáze jsem laik. Pokud mě někdo poučí, budu jen rád.
-
... zrovna v tomto případě to bylo nevhodně navržené SQL query, které při trošku větší zátěži vytížilo databázi deadlockama... to fakt nikdo nemohl dopředu vědět
...
Přes databáze jsem laik. Pokud mě někdo poučí, budu jen rád.
nic si z toho nedelejte, Ondrej je taky :)
mimochodem, Lol-a se da brat obcas i vazne, neni to Lael :)