Názory k článku
České portály znovu na černé listině

Pokládat Atlasu otázku:

Lupa: "Používá Seznam některou technologii pro ověřování původu odesílatele (SPF, DomainKeys, apod.)?"

mi přijde docela divné :-))

Nedavno byl (mozna jeste je) na blacklistu i smtp server Eurotelu a neslo poslat e-mail do vetsiny akademickych domen ...

V současnosti u Eurotelu tento stav pořád trvá a projevuje se tím, že nelze odesílat zprávy z placené brány. Zpráva sice odejde, Eurotel si odeslání nechá zaplatit, ale není doručena, protože je odmítnuta u příjemce jako spam.

S blacklisty jsem take nejakou dobu koketoval, ale musel jsem je vyradit jako dost mizerne reseni. Ucinnost nic moc a hodne false positives. Jsou dobre maximalne jako poradni hlas, treba pro SpamAssassina.

SPF neni pro freemaily moc vhodne, nebot uzivatele mohou pouzivat adresu freemailu i pri odesilani z mnoha jinych mist, nez pres SMTP portalu. (Taky SPF zaznam Seznamu vypada: "v=spf1 mx ip4:212.80.76.43 ~all", tedy "z mych MX a IP 212.80.76.43 urcite, z ostatnich adres asi taky".

Ohledne atlasu - v TXT zaznamu nic nemaji, takze zrejme SPF/CallerID pro odchozi postu nepouzivaji... (Nebo Caller-ID dava informaci jinam???)

No, Caller-ID podle puvodni MS specifikace melo udaje v XML formatu (a jinde), jak to stale jeste implementuje treba Kerio Mailserver. Nicmene uz asi od cervna Microsoft uvadi ve svych dokumentech SPF, a ten Atlas nema.

SPF muze byt resenim i pro takove servery, ale pro odesilani musi pouzivat nejaky submssion port, treba 465/SSL (to podpruje i treba OE) vcetne autentizace, pak neni problem zablokovat zneuzivane ucty a cernym listinam by se mohli celkem uspesne vyhybat.

Submission port (587/START TLS) je problematicky, protoze MS klienti pro jiny port nez 25 pouzivaji SSL a nikoli START TLS.

> No, Caller-ID podle puvodni MS specifikace melo udaje v XML
> formatu (a jinde)

OK, mne se nechtelo dohledavat kde presne ;-)

> SPF muze byt resenim i pro takove servery, ale pro
> odesilani musi pouzivat nejaky submssion port

No prave. Pokud chci odesilat z jednoho klienta dopisy s ruznymi adresami odesilatele, tak to neni moc realizovatelne :-(

Ted jsem se na seznam dival a pravidlo "~all" me rozesmalo.

Jinak atlas SPF nepublikuje a CallerID taky ne. To se dava
do _ep typu TXT.

Napr. dig _ep.microsoft.com txt

S nazorem na pouzitelnost (cizich) blacklistu nelze nez souhlasit. Podminky pro zarazeni jsou na kazdem jine a navic se v case meni. Nemluve o tom, ze tam, kde k zarazeni staci to, z enekdo napise stiznost je relativne snadne aby nekdo, kdo je dostatecne zlomyslny, nechal zaradit prakticky jakykoliv server. A ten spravce, ktery proste jen zacne pouzivat nejaky (nejake) BL, aniz si dukladne procte jeho (jejich) podminky a rozhodne, zda OPRAVDU chce blokovat vsechny ty servery, ktere se na takove listy mohou dostat si snad ani oznaceni odbornik nezaslouzi.

I nam se v minulosti parkrat stalo, ze nektere cislove servery pouzivajici nejaky konkretni BL proste odmitaly dopisu z nasich serveru (nikdy to ale nedosahlo nejakych sirsich dopadu). V takovych pripadech ale neresim problem ja - pouze radim svym uzivatelum, at informuji sve prijemce, ze jejich spravce bezduvodne cenzuruje prichod nekterych dopisu - at si to vyresi na strane prijemce, Chapu, ze v pripade masivniho blokovani, ktere potkava obcas Seznam, to takhle uplne udelat nelze, ale pokud je Seznam presvedcen, ze to, co mu jest vycitano, neudelal, pak by nebylo od veci proste jen rict svym uzivatelum, ze nemuze odpovidat za vsechny nasledky neodpovedne a neodborne spravy cilovych SMTP severu a pozadat je, at prostrednictvim adresatu, kterym pisi, vyvinou tlak na opacnou stranu ...

SPF je pre freemaily vynikajuce riesenie. To ze pouzivatelia MOZU rozoslat mail so spiatocnou adresou freemailu cez hociaky server, je ich problem a je to vlastnost drvivej vacsiny spamov. SPF je tu prave na to aby tomuto zamedzilo. Freemail si moze dat do podmienky ze spravy s ich spiatocnou adresou musia byt odoslane cez ich rozhranie, a kto to neakceptuje bude sam zodpovedny za t,o ze su jeho maily odmietane ako spamy.

Vzhladom na to, ze v sucasnosti neexistuje ziadna dostatocne spolahliva a rozsirena technologia na zamedzenie tomuto problemu, je SPF to najvhodnejsie, co sa da dnes pre overenie platnosti odosielatela e-mailu pouzit.

Freemail si to samozřejmě do podmínek dát může (může si tam ostatně dát cokoliv), ale nevím nevím, jak se to bude jeho uživatelům líbit.

SPF podle mého názoru neřeší prakticky nic, spammery maximálně donutí spamovat z adres, které SPF record nemají. Na druhou stranu ovšem způsobuje spoustu nesnází - např. s automatickým forwardováním nebo s mailing listy.

Spravca/majitel domeny moze svoju domenu chranit proti tomu aby bola falsovana/zneuzivana rozosielatelmi spamov tym, ze uvedie SPF zaznamy. Je vzdy na nom, ci ich publikuje a ako ich nastavi.

Avsak ked uz su niekym nastavene, je hlupost ich nepouzivat. Ak si niekto zle nastavi SPF, nebude mu korektne fungovat posta. Avsak to je problem nastavenia - ak si niekto zle nastavi MX, riskuje to iste.

Problemy s forwardovanim su riesene v drafte SPF, problemy s mailing listami nastavaju iba v pripade ze mailing list nepreposiela prichadzajuce maily so svojou adresou v obalke ale s adresou toho kto mail odoslal. Ale taky mailing list bude mat ovela viac problemov...

Nevím, jestli myslíte ten samý draft jako já, ale draft-lentczner-spf-00.txt sice problémy s forwardováním zmiňuje, ale o něčem, čemu by se dalo říkat řešení, tam není ani slovo. Více méně říkají "buďto si zaveďte white list strojů, které pro vás forwardují, nebo forwardování nepoužívejte".

Ale jak už jsem psal, hlavní problém vidím v tom, že SPF prakticky nic nevyřeší -- odporní spammeři zůstanou odpornými spammery, ať jim pár adres zablokujete nebo ne, a na jakoukoliv vážnější autentikaci odesilatele stejně zůstávají použitelné pouze kryptografické podpisy.

Ako som uz pisal, bud si svoju domenu ochranite proti tomu aby ju niekto pouzival pri odosielani mailov/spamov/virusov, alebo nie.

A ako som uz pisal, SPF neriesi spam ale falsovanie adresy odosielatela, nech je charakter mailov hociaky, takze nevidim dovod preco stale tocite o spame.

A ako som este nepisal, ak si niekto praje aby ste maily s jeho domenou v mail from: prijimali IBA z jeho serverov, nevidim dovod mu nevyhoviet, prave naopak, kaslat na to je voci nemu pekne drze. A to, ze napr. vas drzy kamarat posiela mail s uvedenou domenou odosielatela cez server, napriek tomu ze si to spravca dotycnej domeny nepraje, je problem vas respektive dotycnej drzej osoby.

Takze, ak SPF neimplementujete vo svojej domene, bude vam potencialne chodit viac staznosti/notifikacii ohladom mailov, ktore ste vy ani nikto z vasej domeny nikdy neposielali.

Ak SPF neimplementujete na vasich mail serveroch, prichadzate tak o moznost kontroly na ludi, ktori posielaju maily z adries, z ktorych take maily prichadzat nemaju. V oboch pripadoch tak dostavate viac posty, v tom druhom vsak zbytocne viac.

Po pravdě řečeno, nerad bych měl správce sítě, který mi veden takovýmito zajisté svatými pohnutkami rozbije všechno forwardování pošty.

Myslím, že pokud si správce něco takového přeje, nejen, že by se mu mělo nevyhovět, ale hlavně by se mu to mělo rozmluvit. Připomíná mi to totiž ono pověstné vylévání dětské vaničky :)

Ja myslim ze to k vanicce ma dost daleko.

Rozdelme si lidi na dve kategorie.

Prvni ma vlastni domenu. Treba ja, ze ;-). A me skutecne dost poskozuje, ze musim lidem vysvetlovat, ze ten virus s moji adresou neni ode me. Pro me by tedy bylo dobre, kdybych mohl zajistit, ze maily s moji adresou pujdou jen z nektereho z rekneme dvou stroju, ktere pripadaji v uvahu jako odesilaci. Ale SPF jsem jeste nenasadil, protoze si tak nejak nejsem jisty, jestli je to ono a hlavne, ze kdyz bude mail v transportni obalce mit pepa@tu.cz a v hlavickach potom me, tak lidi stejne uvidi me, ale prijimaci server to akceptuje podle zaznamu pro domenu tu.cz

Druha kategorie pouziva domenu "sdilenou", volny.cz, ruzne skoly a podobne. Tam je skutecne problem, ze takove mnozstvi lidi se na obsahu SPF zaznamu nedohodne, i kdyby se jich cirou nahodou nekdo ptal. A tem muze nekdo rozbit forwardovani a oni budou dlouho hledat proc se tak stalo a kdo za to muze.

Problem je s lidmi, kteru odnekud na svete delaji nejaky bordel. Tim muze byt DoS utok, virove scanovani portu, a, krome toho, take odesilani nevyzadane posty nebo adresy s falesnou adresou. To je spousta ruznych veci, ktere takovy nehodny uzivatel muze delat. A bylo by potreba tento problem nejak vyresit. Kdyby se podarilo vyresit alespon castecne, hle, vyresilo by to i problem, ktery se snazi resit SPF. Jenze, na to neni prilis vule - typicky ISP preci nebude buzerovat klienty, kteri mu plati - at uz cini co chceji a komukoliv pusobi problemy jake chteji. Hlavne kdyz plati.

Nehleda se system jak postupovat proti problemovym uzivatelum. Nehledame zpusob jak omezit pristup do Internetu tem ISP, u kterych se problemovi uzivatele vyskytuji. To byste, a to si kazdy uvedomuje, musel za chvili resit i nehodne uzivatele ve sve siti - jinak byste riskoval, ze i vas, jako ISP budou celkove blokovat. Jenze, to je prave ono. To byste se musel zbavovat platicich klientu. A to vy nechcete - vy se chcete branit proti radne platicim nehodnym klientym jinych ISP - vlastni vam nevadi. A to je idea, na ktere je vystavene SPF. A proto je mi nesympaticke.

Predstavte si takove telekomunikace. Podvodne dialery presmerovavajici volani na Internet k nejmenovanemu operatorovi se jmenem od "A". A vy nehledate spolecnou dohodu operatoru o tom, ze "podvodniky" proste zadny z vas pripojovat nebude. Vy hledate metodu, jak zabranit, aby podvodnici jinych operatoru nemohli poskozovat vas, ale soucasne, tato metoda nesmi branit pripojovani podvodniku obecne - to by totiz omezilo i ty vase. Predstavujete si to ? Tak presne to je SPF ...

A co http://spf.pobox.com/emailfwdpng.html ?

A ještě je tu http://www.ietf.org/internet-drafts/draft-leibzon-emailredirection-traceheaders-00.txt

Jestli mají opravdu správci mailserveru seznamu natvrdo nastaveno upozorňování o spamech (a tím pádem většinou na podvržené e-mailové adresy), tak jsou to naprostí diletanti a je to neomluvitelné.

Zadne upozornovani o spamech nastaveno neni. Jde o to, ze pokud prijde rekneme spam k nam a je nedorucitelny (uzivatel u nas nema schranku, ma ji plnou, atd) tak se (dle RFC) bouncne na odesilatelovu adresu. Ta samozrejme muze byt podvrzena a bounce dostane nevinny uzivatel.
Zde by mohla/mela by kontrola, zda nebouncujeme spam. Myslim, ze by se nam to melo podarit implementovat.
Jinak s blacklistama je to slozite, kazdy ma trochu jiny pristup, mene ci vice profesionalni. Nelze tvrdit, ze zachytime kazdy odchozi spam ale radikalne jsme to v poslednich mesicich zredukovali (viz nejznamejsi Abuse newsgroup - http://groups.google.com/groups?q=212.80.76.44&hl=en&lr=&group=news.admin.net-abuse.sightings&c2coff=1&sa=G&scoring=d ), posledni vyskyt reportu 26. cervence. To, ze odchazi neskutecne mnozstvi spamu se zfalsovanou odchozi adresou ze Seznamu je vec dalsi. I samotny Spamcop, ktery osobne vidim jako velmi kvalitni, dela chyby a blokuje obcas na zaklade falesnych ci spatne interpretovanych vysledku.
Tohle vse je ovsem na dlouhou diskuzi... :-)

SpamCop sám sebe označuje za experimentální a nedoporučuje sám sebe k použití v komerční sféře. Kdo jej používá prostě jen neumí dostatečně anglicky nebo si jeho stránky nepřečetl. Navíc jeho politika doplňování svého black listu je HODNĚ divná - přiřadí servry na základě upozornění kýmkoli a bez ověření, nesdělují důvody zařazení apod. Prostě je to experimentální black list a z toho plyne vše.

Seznam je taky experimentální - zkouší kdo co vydrží :-))

Boucovat ci neboucovat SPAMy je slozita otazka. Vzhledem k tomu, ze SPAM nelze poznat stoprocentne (a ani s pravdepodobnosti tem sto procentum jen dostatecne se blizici), je treba vzdy pocitat s tim, ze doruceny dopis SPAM neni. A v takovem pripade musi byt pouzity vsechny prostredky k tomu, aby byl odesilatel o nedoruceni informovan.

Co se me tyce, radeji snesu stovku chybnych oznameni o nedoruceni dopisu, ktere jsem neodeslal, nez jedno chybejici oznameni o nedoruceni dopisu, ktery jsme skutecne odeslal.

Resit tento problem neprislusi prijemci, protoze ten ho nemuze vyresit dobre. Resit je treba jednak SPAM obecne, jednak by stalo zato vic prosadit standardizovana chybove hlaseni - a ta by mela obsahovat dost informaci na to, aby odesilateluv MUA mohl, u dosleho hlaseni o chybe, jednoznacne urcit, zda patri k nekteremu z dopisu odeslanych drive, nebo nepatri. Ty druhe pak muze uzivateli neukazat a mazat ...

To by mělo jít detekovat pomocí Message-Id. Stačilo by si pamatovat Message-Id odeslaných mailů a mazat hlášení o nedoručitelnosti, která neobsahují evidované Message-Id. Pokud tedy někdo posílá hlášení o nedoručitelnosti, kde nejsou hlavičky nedoručeného mailu - o užitečnosti takového hlášení bych ale stejně měl určité pochybnosti.

Jenze, ty hlavicky musi byt nalezitelne strojove. A jedno z RFC upravuje, jak ma vypadat strojove zpracovatelne chybove hlaseni. Ale mam dojem, ze hlavicky, nebo tuto hlavicku konkretne, tam nenajdu ...

Docela dobře mi funguje posílat všechny maily se speciální adresou odesilatele v obálce, kterou na nic jiného nepoužívám,
a která obsahuje aktuální datum a zahazovat všechny bounces, které přijdou na adresy jiné, případně které mají datum v příliš dávné minulosti.

Zatím všichni spammeři a červi, které jsem potkal, ulovili vždy hlavičkovou adresu, nikoliv obálkovou.

Co se me tyce, radeji snesu stovku chybnych oznameni o nedoruceni dopisu, ktere jsem neodeslal, nez jedno chybejici oznameni o nedoruceni dopisu, ktery jsme skutecne odeslal. vidim to podobne, ale BFU jsou nauceni, ze mail nedojde, muze se ztratit apod... houby s voctem, pokud neni nekdo trubka, tak kazda akce ma nejakou reakci...

Komunikujeme z provozovateli a ještě jsme se nenaučili, že se sedmým pádem se pojí "s".

Diky za upozorneni. Do skoly nechodili v Seznamu, u nas "jen" tento fakt prehledla korektorka :)

Je fakt, ze Seznam aspon aktivne resi pripominky na abuse, zatimco Atlas je totalni diletant... - jednak abuse konci vite kde, dokonce jednu dobu byla schranka preplnena (aktualni stav nevim a neresim, Atlas jsem zablokoval zcela), jednak mozna do dnes je jako OR nejaky z jeho slavnych killbillu... tak na co si to panove vlastne hraji?

Pokud vim tak Atlas tyto pripominky resi a resil, to co pises o abuse@domena.cz je nesmysl pri takto velkych objemech co tam chodi je tezke cemukoli predchazet touto cestou.. Na spamlist se dotanes i kdyby jsi se stavel treba na hlavu..

Kdybys tolik nekecal, byl bys verohodnejsi... - jak to, ze jini i mnohonasobne velci ISP a ASP nez je nas maloucky Atlas to jsou schopni touto stanadrdizovanou cestou (dokonce via RFC) resit? Jo jenze to by Atlas se musel chovat slusne a penize investovat potrebnym zpusobem a ne do trapne blondyny a jeste trapnejsi reklamy na ten udajne nejlepsi Seznam firem...

Kdyby z Vás tolik nečišel subjektivismus a alergie na atlas, byl byste verohodnější ...

Overte si me technicke argumenty a pak pokracujte....

Nevim, kdo tady keca nesmysly.

http://www.rfc-ignorant.org/tools/lookup.php?domain=atlas.cz

http://www.rfc-ignorant.org/tools/lookup.php?domain=seznam.cz

HB: "U odchozí pošty publikujeme SPF záznamy. Pro poštu příchozí nebereme zřetel na to, zda jsou SPF záznamy publikovány. Statistiky totiž ukazují, že více než 85 procent pošty pocházející ze serverů publikující SPF záznamy spadá pod označení SPAM."

HB nevie, o com hovori. SPF nie je o spamoch. SPF je o falsovanych adresach, a ja si dovolujem povedat ze 99% mailov ktore neprejdu kontrolou SPF, su spamy. Takze neimplementovat SPF na strane MX servera znamena zavrhnut velmi ucinnu zbran, na zaklade statistiky ktora s jej efektivitou nema nic spolocne.

Pokud 99% jsou spamy a zbylé 1% false positives, není to zrovna lichotivá statistika :)