Názory k článku Nová služba veřejnosti, či degradace Internetu?

Nastesti se provozovatele nameserveru mohou branit:

http://www.isc.org/products/BIND/delegation-only.html

S timto patchem pro BIND je mozne vybrane zony (asi .com a .org) oznacit jako delegation-only, cimz se zajisti, ze se budou brat v uvahu pouze NS recordy a nic jineho.
V idealnim pripade by tuto konfiguraci meli zavest vsichni ISP na svych serverech a prakticky tak Verisignu udelat caru pres rozpocet. Ale to se bohuzel asi nestane :-/

Nova verzia patchu umoznuje bloknut ne-NS zaznamy v TLD globalne, a samozrejme uviest vynimky.

Tak ja nevim .. asi sem blbej .. ale at se snazim, jak se snazim, tak verisign na neexistujici domenu vraci pouze A zaznamy, ale ne MX, ktere jsou, jak jiste vsichni vite, autoritativni pro SMTP.
Takze .. co je to za nesmyslnej clanek??
Lupooo? Autoreeee??

samozrejme, ze je to svinarna, ale ne zas az takova, aby si cetli cizi maily, proboha ...

;; QUERY SECTION:
;; www.lupajebandalameru.com, type = MX, class = IN

;; AUTHORITY SECTION:
com. 2h57m47s IN SOA a.gtld-servers.net. nstld.verisign-grs.com. ( 2003091801 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum

Tak nejak. Navic me dostala ta uplne zbytecna story o nakupu ropy via e-mail :-)

Pri neexistenci MX zaznamu se dorucuje na prvni A zaznam.

A kdyby clobrda s prezdivkou "cz" zkusil poslat mail treba na magor@neexistujicidomenaa213214215.net, mohl si to overit i prakticky.

Trying 64.94.110.11...
Connected to sitefinder-idn.verisign.com.
Escape character is '^]'.
220 Snubby Mail Rejector Daemon v1.5 ready
HELO vole
250 snubby
MAIL FROM: a@a
250 Ok
RCPT TO: aa@aaaaaaaaaaaa.com
550 <unknown[moje.ip]>: Client host rejected: The domain you are trying to send mail to does not exist.

tralalalala

To jsem přesně zkusil a e-mail se mi vrátil proto, že doména neexistuje. Tedy podle mého názoru má člobrda "cz" pravdu a hlavní část článku opravdu postrádá smysl. Mohl by se k tomu vyjádřit nějaký expert? Michale?

Verisign průběžně měnil "mailer" který tam na portu 25 visí (to si můžete ověřit i různě na webu, stačí vyhledat "Snubby Mail Rejector"). Je možné, že zatímco mě vrátil ráno "5.1.1 User unknown", mezitím ho Verisign upravil a teď už vrací jinou chybovou zprávu.

Nevím, jestli jsem ten správný expert, ale zkusím se vyjádřit. Konstrukce v článku je IMHO trochu mimo, protože předpokládá překlep v MX záznamu, což je podstatně méně pravděpodobná situace než překlep v adrese příjemce. V daném případě ale skutečně k problému dochází - při současném nastavení je mail odmítnut, zatímco bez něj by se automaticky poslal na záložní MX záznam. Těžko ale hodnotit, zda je to opravdu na škodu věci - aspoň se na chybu přijde rychleji.

Při překlepu v adrese se MX záznamy nenajdou, takže se pravá část adresy resolvuje na příslušnou IP adresu sběrače. Tam sedí triviální MTA, který mail odmítne. Takže výskledek je v pořádku - mail nedoručitelný.

Problém ale vidím v tom, že k odmítnutí dojde až po příkazu RCPT, tedy ve chvíli, kdy už odesílatel poslal obě adresy - chynou adresu příjemce a správnou adresu odesílatele. Takže ideální pomůcka ke sběre adres pro spam.

A konečně, hodně problematické je i chování vůči ostatním službám. Na ICMP echo sběrač nereaguje, na UDP odpovídá ICMP zprávou destination unreachable. V případě TCP spojení ale k odmítnutí dochází na úrovni TCP, takže to v klientovi vzbuzuje mylný dojem, že adresa je správně, pouze služba (dočasně) nefunguje. V každém případě se jedná o zcela nežádoucí zneužití postavení ze strany VeriSign. U provozovatele významné certifikační autority, jehož nejdůležitějším aktivem by měla být důvěra zákazníků, se jedná o nepochopitelný krok.

Sice jsem myslel jiného Michala, ale díky za odpověď :-).

Nastane vůbec ten problém, když bude překlep v MX záznamu? Nevrátí Verisign jenom A (moc se v tom nevyznám, ale podle toho, co tady někdo zmiňoval, je to něco jiného než MX) a tak se stejně použije záložní záznam? Z diskuse to není patrné, jeden tvrdí to a druhý zase ono.

Neboli - když pošlu mail na existující doménu, jejíž poštu ale zpracovává doména s překlepem a záložní bez překlepu, komu ten mail dojde?

Odesílatel dostane dva MX záznamy. První bude zkoušet ten, který má nižší prioritu. V našem příkladu je to ten s překlepem, takže jeho jméno se přeloží (kvůli wildcard záznamu u VeriSign) na 64.94.110.11. Tam je MTA, který vrátí permanentní chybu 550, takže odesílatel bude mail považovat za nedoručitelný. Kdyby cílový MTA vrátil dočasnou chybu nebo by vůbec na pokus o spojení nereagoval, zkusil by se druhý MX záznam.

Aspoň podle toho, jak jsem pochopil RFC 2821, by to tak mělo probíhat. Je možné, že některý MTA zkusí další příjemce i po přijetí kódu 550.

Hosi vy stale nechapete, ze teraz ten e-mail vracia verisign, a nie vase MTA preto, ze domena neexistuje.

Az si verisign zmysli, ze si tie maily chce citat, tak si ich citat bude ...

Jestli vám z mého popisu připadá, že to nechápu, máte asi problémy s porozuměním čtenému textu. Proč bych asi jinak upozorňoval na to, že sběrač mail odmítne až poté, co dostane obě adresy? Popisoval jsem současný stav a ten je takový, že Verisign si žádné maily nepřečte, protože je nedostane - jsou odmítnuty ještě před příkazem DATA. Samozřejmě se to může kdykoli změnit, ale ne tak, aby to ostatní nepoznali.

Ja se omlouvam za zrejme spatne zarazeni me odpovedi do textu, nebyla primo mirena na Vas ale na celou diskusi predtim - meditovani nad necim spatnym.

Jinak soucasny stav JE takovy ze si maily neprecte - jenze verisign jej muze kdykoliv zmenit...

Na dorucovani je rozumne juknout se do RFC 974. Mimochodem, clanek zdale se mi spise popisovati variantu, ze je vice MX s nejnizsti prioritou, pricemz v jednom je preklep.

Autor článku se vlastně o MX záznamech a prioritách výslovně nezmiňuje, ale protože píše: "První server, jenž se použije, pokud je vše v pořádku, a druhý server, který se použije, pokud je server první nedostupný.", předpokládám, že má na mysli situaci, kdy jsou dva MX záznamy s různou prioritou.

Pak je to cele zmatecne, protoze pri takove konfiguraci nas zajima jedine az ten finalni MX (s nejnizsi prioritou) - protoze ten pripadne kontaktovany jiny stejne bude nakonec dorucovat postu na nej. Neboli - ve svem prikladu zadny "druhy" MX nepotreboval, protoze i bez nej by dosahl identickych vysledku. Protoze jsem veril, ze autor tam nejaky smysl mel, nezbylo nez predpokladat, ze to myslel tak, jak jsem napsal. Ale jiste to, samozrejme, neni ...

Ten záložní nemusí posílat dál podle MX záznamu, může mít posílání pošty pro příslušnou doménu nastaveno natvrdo, např. u sendmailu v mailertable.

Takze on by si myslel, ze je finalnim mailerem (protoze jen tehdy se pouzije mailertable), ale pritom by jeho MX nemelo nejnizsi prioritu ? Nu coz, i takova konfigurace je pochopitelne mozna, i kdyz by me zajimalo, v kolika exemplarich je to na svete k videni (chyby konfigurace nepocitam) ...

Naopak, mailertable se použije, pokud sendmail není finální mailer. Používá se pro odcházející maily, ať už lokálně vzniklé, nebo přijaté pro některou z domén v relay-domains.

Nechapu, trochu myslenkovy zkrat - MX+prority jsou obecny zpusob, jak neco zazalohovat. Nerika naprosto nic o tom, co maji dalsi MX s postou delat. Muzou ji zkouset dorucit pomoci SMTP na MX vytazene z dns. Muzou ji dorucovat na nejaky natvrdo nastaveny pocitac. Muzou ji dorucovat nejakym uplne jinym protokolem. SMTP servery mohou byt jen frontendem pred nejakou databazi ukladajici postu. Mohou postu dorucovat lokalne. Ukladat do souboru, at si s tim pak nekdo poradi. Cokoli.

Dokonce by se dalo vymyslet stovky prikladu, kde je to vhodne reseni. Sam jsem takovou konfiguraci dvakrat trikrat nastavoval :)

Na svete takove konfigurace urcite v tisicich pripadu bezi.

MX + priority jsou zpusob jak popsat jak ma byt dorucovan email adresovany na nejakou adresu. To jak je je OBVYKLE interpretovat je popsane v RFC na ktere jsem tu uz odkazoval. Existenci deviaci samozrejme nevylucuju. Ale mam dojem, ze se v uvahach opravdu totalne mijime a ja se navic mijim s tim, co zrejme mel na mysli autor clanku a v marnem pokusu to pochopit se do toho jen vic zamotavam. To je odpoved i pro Michala Kubecka, ktery ma samozrejme se svoji poznamkou pravdu.

Hmmm, mno to je IMHO problem te domeny, ze nema MX zaznamy ;)

Jaké domény? Té, která není nikde registrovaná, protože se jedná o překlep?

Už jsem to pochopil!
To zase autor vůbec netuší, že kadrnozka@velkafirma.com a kadrnozka@mail.poskytovatelinternetu.com by mohli být dva úplně jiní uživatelé (třeba správci) na dvou zcela odlišných počítačích.
Jinak je totiž onen příklad úplná blbost, protože by tento "překlep" musel udělat programová komponenta spolupracující s DNS.

To bych se autora (ackoliv se misty opravdu zda, ze s DNS neni kamarad dokonale) musel zastat. IMHO konstruuje situaci tuto:
velkafirma.com MX 0 mz1.velkafirma.com
velkafirma.com MX 0 mx2.velkafirma.com
mx1.velkafirma.com A 0.0.0.1
mx2.velkafirma.com A 0.0.0.2
Tedy, prvni MX zaznam ma na prave strane preklep, kvuli kteremu byl (drive) nezresolvitelny na finalni IP - a jelikoz existoval jiny zaznam se stejnou prioritou, pouzil se ten. Jde o lidskou chybu, nikoli chybu nejake softwarove komponenty. Nebo nepochopil ja Vas ?

Ano, máte pravdu.
Nějak jsem si představoval, že překlepy se týkají jen typování uživatele, který chce někomu posílat poštu. Proto jsem netušil, proč by uživatel typoval něco podle MX-rekordu.
Ale pokud správce při vytváření MX-rekordu udělal chybu - a potom se to dlouhou dobu táhne (jako na MFF).
A možná v tomto případě postmaster na verisign si toho všimne a zajistí opravu.
Ale ono to jako kontrola postmasterů nemusí být taková blbost, jak dokazuje skutečný příklad MX-rekordu pro MS.MFF.CUNI.CZ . Možná právě naopak, kéž by byl někdo, kdo by to po nich někdy kontroloval (když to tam studenty neučí, jak jsem před hodinou zjistil - ti by si toho určitě na cvičeních první všimli.)

Kontrola nikdy neni blbost. Nicmene, kdyz uz se pomalu, ale jiste, dostavame off-topic - co je na tom zminem MX spatne ? Ted jsem se na nej dival a celkem nic divneho nenachazim ...

Já pořád dostávám pro sekundární Mail-exchanger adresu smtp.kolej.cuni.cz ( asi místo smtp.kolej.mff.cuni.cz )
Náhodou jsem si toho všiml, když jsem se díval, zda-li již opravili cyklení mezi 2. a 3. mail-serverem (při výpadku primárního).
P.S.
To když za mnou nějaký student přijde a chce uznat síťový předmět z Matfyzu, tak já mu pak řeknu dobře, ale když na MFF zajistíte opravu. - Ale většinou si ho takto chudáci studenti musí znovu zapsat.

hezke, nebylo by ovsem efektivnejsi upozornit hostmastera a postmastera dotycne domeny na ten problem primo?

Povazoval jsem za obvykle, ze ten, kdo na siti zjisti problem o nem informuje (nebo se alepon pokusi informovat) prislusneho spravce. Povazuji za neobvykle resit problem tak, ze ho vykladam nejakym nestastnym studentum, kteri s nicim takovym nemaji nic spolecneho - a jeste je trestat za to, ze vec, se kterou nic do cineni nemaji nezaridi. Nicmene, jiny kraj, jiny mrav, zrejme. Jak muzete videt, chyba je odstranena - hned, jak jste byl tak neskutecne laskav, ze jste se rozhodl o ni dat vedet. Trvalo to jen malou chvilinku. Neni sice jasne, jestli je nutne tyto veci resit verejne, nicmene, me to nevadi (ano, byla to moje chyba, ale ja na verejnosti nepredstiram, ze zadne nedelam) a pokud je to jediny zpusob, jak muzete napomoci funkcnosit Internetu ...

Za upozorneni dekuji.

Dan Lukes, spravce site, SISAL, MFF UK

To vite, nejtezsi stredni skola v CR (VSE) musi ukazat, ze ste LAMERI. <P>
A nevic nepouzivate BITNET (II).

Pro me je podstatne, ze me na to nekdo upozornil a ja to mohl opravit. Kdyz to neslo driv a jinak, tak takhle je to nejlepe a nejdriv jak to slo. Porad lepsi (pro me, pro MFF UK a Internet vubec) tady a ted nez vubec.

To jsem se před několika lety snažil udělat, když mi ob týden přišel zacyklený mail z diskuse v listserveru.
(Jinak to krásná chyba. Vypadne primární mailserver, pošta se posílá na 2.adresu. Tam ale věc nijak neošetří, ale snaží se ji předat opět na primární. Ten ale stále nejde. I vezme s 3.mailserver. Ten ale postupuje stejně. První stále nejde, tak ji dá na druhý, atd.)
Neřešitelný problém. Dokonce to šlo tak daleko, že jsem přes svou vzdálenou příbuznou, která studovala MFF, se to snažil vyřídit správcům ústně. - Ale na MFF se správci s někým takovým nebaví.
Nakonec jsem poštu násilím nechal gateway-ovat přes rektorát UK. Tak mi prosím Vás nevykládejte, že se správcům na MFF dá něco normálně napsat. (Zvláště když píšete z adresy, kterou na MFF skutečně všichni považují za vyšší střední školu.)
A s těmi studenty je to trochu jinak. Těžko mohu doporučit uznání předmětu, když na MFF sítě stále učí jako v roce 1996. Samozřejmě to jde to, pokud se ovšem student sám něco doučí navíc - což třeba s http-protokolem na MFF něudělali asi ani někteří vyučující sítí. Tak to potom prostě nelze ani formálně uznat předmět s osnovou, podle které se na VSE učilo do roku 1996.

Priznam se, ze tomu nerozumim. Dost casto prijdu do styku s ruznymi chybami v konfiguraci v cizich sitich. Asi mam stesti, protoze se mi zatim nestalo, aby me nekdo vyflegmoval nebo odmitl. Podotykam, ze se nabavim pouze nasem malem rybnice. I kdyz nepisu z adresy "vyssi stredni skoly", nemyslim, ze by treba Telstra rozlisovala mezi postou z domeny krsek.cz a vse.cz :-)

Poslu postu jednak na adresy, ktere jsou v databazi k prislusne domene, IP adresam ci autonomnimu systemu a jednak na generickou adresu prislusnou k danemu problemu noc@, abuse@, postmaster@, hostmaster@ ...

Copak v zahraničí. Tam Vám za to ještě poděkují.
Asi před rokem jsem psal na Google, že jim jejich robot po požadavku na stranka.htm chce vždy ještě stranka.ht . Dokonce po mně chtěli log a pak psali, že jsem jim skutečně pomohl.
Ale u nás nestačí ani správci přesně napsat, co a proč má opravit - schválně, zda-li pak si už na portal.gov.cz opravili chybné kódování?

Vzhledem k tomu,ze portal.gov.cz bezi v betaprovozu, kdy sbiraji chyby, necekam, ze je budou okamzite prubezne opravovat.

Myslim, ze i na VSE se lide zabyvaji velkymi IS a vedi, jakym zpusobem funguje betaprovoz :-) Zkuste se jich optat.

Někteří lidé mají u systémů beta-provoz léta, jiní udělají drobné opravy i ve zkušební provozu ještě dříve, než dojdu od nich do posledního patra.
Přepsat tři čísla na stránce, kterou jsme ke všemu ještě inzerovali v televizi, vůbec nesouvisí s beta, alfa či gama-provozem, ale s tím, zda příslušní lidé mají (obrazně řečeno) k práci "východoevropský" anebo "západoevropský" vztah. ( A jak se vedle v diskusi hovořilo o financích, tak pracovat východoevropsky a být placeni západoevropsky - to je asi to, co nám hlavně přineslo vytvoření Ministerstva informatiky.)

Obavam se, ze pres veskerou vasi laskavou snahu se mi nedari zachytit podstatu problemu, ktery jste se mi pokusil sdelit. Nepochybuji, ze problem je na me strane, nicmene se mi zda, ze by ode me bylo bezohledne, kdybych Vas kvuli sve hlouposti nadale okradal o Vas cas - zrejme se budu muset smirit s tim, ze je to jedna z dalsich mezi mnoha vecmi, ktere nepochopim. Kazdopadne Vam dekuji za snahu i cenne informace.

A na jakou adresu jste jim psal? Rad bych jim take pomohl :-)

Mam za to, ze jsem nasel docela dobre zdokumentovanou chybu v googlebotu. Uz jsou to skoro dva mesice a dostalo se mi jen automatizovane odpovedi nejakeho robota.

Ta chyba je v tom, ze prestoze existuji desitky backlinku na example.NET/stranka tak mi jejich robot usilovne indexuje pouze example.CZ/stranka (ktera neexistuje a nikdy neexistovala). Deje se tak prakticky denne uz nekolik mesicu. Rad bych Googlu pomohl, ale jaksi vykazuje ponekud mrtvolnou reakci. Pocitam, ze opravit takovehle bugy by mohlo byt v jejich zajmu.

Bud je vas popis problemu nesrozumitelny, nebo se nejednalo o SMTP. Tak jak popisujete se SMTP servery nechovaji. Server priority dva nikdy, a to ani pri nedostupnosti serveru priority jedna neposle postu na server priority tri.

Jak "jinak" je to se studenty, to nevim. Predpokladal jsem, ze je to tak, jak jste to napsal a na to jsem take reagoval. Ted pisete, ze je to uplne jinak - no, tak to asi bude uplne jinak. Asi to bude ale jeste nejak uplne jinak. Pokud vim, na MFF neexistuje zadny predmet, ve kterem by se vyucovaly konkretni aplikacni protokoly a to vcetne HTTP (SMTP, FTP, ...). Zrejme vam tedy vesi nejake buliky na nos, abyste jim ty predmety uznal a je jedine dobre, ze jste jim nenaletel. Jinak ale ja neshledavam nic pozoruhodneho na tom, ze i predmet se stejnym nazvem na jinou napln - obzvlaste, kdyz jde o skoly dost odlisneho typu a zamereni. A za teto situace je samozreme (a nikoli tedy hodne zvlastni pozornosti), ze vystudovany predmet na jedne skole nemuze byt na druhe uznan jako absolvovany i kdyz maji, nahodou, shodne nazvy. Nenapadlo by me, ze nad takovou samozrejmosti se muze vubec nekdo pozastavovat nerkuli pohorsovat ...

Odpovím vše dohromady:
1. Nebyl to Google, to jsem se uspal, bylo to z Altavisty. Presna adresa byla: crawl-support@av.com
2. Přinesli mi osnovu předmětu SWI045 a tady čtu: ... Telnet - základní principy,.. protokol FTP,.. přenos zpráv protokolem SMTP. protokol POP (a konec)
3. Ty další mailery si to skutečně předávaly dokola, protože myslím měly přitom oba stejnou prioritu. (A samy sebe "chytře" vynechaly.)

Tak si říkám, neomylný člověk, to se jen tak nevidí. Velmi moderní přednáška a zcela bez chyb - tam budu chodit. A z Googlu na mě něco vypadne...

Tak snad jen pár poznámek k 1-2 lekcím

- V české typografii se závorky sází bez mezer (takto). To, co zpravidla provádí SSH, se v češtině zpravidla nazývá šifrováním. Kódovát lze třeba morseovkou.

- Pozornost věnovaná jednotlivým tématům - to je opravdu příklad hypermoderní koncepce. Zdá se například, že DNS je téma asi tak stejně důležité jako síť BITNET/EARN. Obsesí autora je zjevně služba Gopher, dnes už obskurní vykopávka.

- Prospělo by vypustit "bezpečnostní" bláboly stylu: "Důvodem je hlavně obava před zneužitím ( možná někomu známých ) slabých míst aktivovaného programového vybavení, kudy by bylo možno proniknout k vlastním neveřejným datům." (vysvětlení nasazení firewallu)

Přdstavuju si, co musí umět takový student na zkoušku...
-zasvěceně pohovořit o síti BITNET
-zasvěceně pohovořit o výhodách Gopheru oproti WWW
-5 minut nadávat na MFF UK

Mohu se jk zeptat. proč k onomu blábolu o firewallech neopsal ještě další větu? - Asi proto, že se jedná o nějakého typického správce, který ani netuší, co kde povoluje a zakazuje (a proč)?
Jinak opravdu nevím, proč některým lidem vadí se cokoliv dozvědět třeba o Gopheru, když ten právě přinesl myšlenku nespojované (non-persistence) spolupráce. Já jsem přesvědčen, že kdo nepochopí odlišnost Gopheru od FTP (či Telnetu), nemůže pochopit ani problém SessionID na WWW-serverech.

No vidite, to jsem nevedel. To ale na veci nic nemeni. Stejne nechapu nad cim se pozastavujete. Jestli ma nejaky predmet v osnove napsano, ze je jeho naplni Telnet, FTP, SMTP a POP, pak patrne budou jeho naplni tyto protokoly, na rozdil od NTP, NNTP, SSL, SSH, HTTP, NFS a dalsich, ktere jeho naplni nebudou. A to, ze zkousku z takoveho predmetu na jedne skole nelze uznat jako splneni podminek predmetu na jine skole, predmetu, jehoz napln je sirsi, je tak naprosto samozrejme, ze jsem si jist, ze Vam proste jen nerozumim, kdyz mam dojem, ze se prave nad touto samozrejmosti pozastavujete. Stejne tak nepredpokladam, ze se pozastavujete nad samotnou skutecnosti, ze dva predmety s ruznou naplni - maji ruznou napln. Obavam se, ze pres veskerou vasi laskavou snahu se mi stale nedari zachytit podstatu problemu, ktery jste se mi (nam) pokusil sdelit. Nepochybuji, ze problem je na me strane, nicmene se mi zda, ze by ode me bylo bezohledne, kdybych Vas kvuli sve hlouposti nadale okradal o Vas cas - zrejme se budu muset smirit s tim, ze je to jedna z dalsich mezi mnoha vecmi, ktere nepochopim. Kazdopadne Vam dekuji za snahu i cenne informace.

Nicmene musim konstatovat, ze je blbost, co VeriSign vymyslel a nejak mi unika k cemu by to jako melo byt dobre ...

K cemu? To je preci jasne, k vydelavani penez.

Ty vole k cemu dobre ? Ziskani neuveritelne kvalitni statistikt prejlepu, co lidi hledaji, jak se chovaji...

Ve windows to same smirovani dela MS kdy pokud nedostane odpoved od NS vcas ci dostane odpoved "destination unreachable" tak automaticky presmeruje na neco.msn.com/neco?co_bylo_v_adresnim_radku. Bud primo presmerovava na msn nebo na nektereho ze svych lokalnich partneru.

Takze MS je IMHO Jezevec momentalne ten, kdo musi byt nasrany nejvic, protoze byl odstrihnut od zajimaveho zdroje informaci. Takze sice krok Verisignu je svinarna ale tak trosku mam radost, jak to musi srat MS...

Jo a mimochodem netmag.cz zase jede, takze netmag.cz/registrace.html se registrujte a nove kvalitni clanky piste na netmag.cz/add.html. Za kazdy novy clanek 1 korunu za ctenare splatne v okamziku kdy netmag.cz emituje akcie ;)

Jsem si v tom hledacim okne u Verisign zadal k hledani "fuck verisign" a vypada, ze internetova komunita to moc nadsene nevita tento krok...

Dokonce uz maji domenu:www.fuck-verisign.co.uk

S tim presmerovanim na MSN je to jinak, protoze se da v IE snadno zrusit, pripadne nastavit jinam.

Jednoduse ? Kolik procent lidi to zvladne ? A kolik procent lidi to vubec napadne ? 1%, 2% ? Ve vysledku je to to same, jako by to neslo aneb "po ovoci je poznas" jak rikaval jeden muj kamos...

ok, ale branit se da

navic je to docela dobra sluzba, hodi vas to totiz na vyhledavac, kterej se pokusi najit tu spatne zadanou adresu nekde v indexu, takze i s preklepem se da na tu sajtu doklikat, coz je pro bfu fajn

Ale to chce/robi aj VeriSign. Problem je v tom ze v pripade M$ explorera sa to bloknut DA, v pripade verisignu sa to zrusit NEDA. Zo strany zakaznika, samozrejme. A to je principialny rozdiel.

ked uz o tom hovorime, hodit cloveka automaticky na vyhladavac je podla mna tiez dost drza vec. Zneuzitie monopolu, ci M$ alebo VeriSign.

Na to je jednoducha odpoved:

Nepouzivejte Internet Explorer!!!

Staci si nainstalovat jiny prohlizec, ve kterem se spatne napsana adresa zachova i po hlaseni, ze hledanou stranku nelze zobrazit, protoze neexistuje !!!

Nechapu vubec lidi, jak jeste muzou pouzivat IE? Vzdyt ten program je 100 let za opicema? o proti jinym neumi vubec nic, ma daleko vic chyb! Bohuzel protoze ma MS monopol tak lidi neznaji nic jineho a ani nechteji nic jineho zkusit, i kdyz je to neco jineho daleko lepsi!

Ja ho nepouzivam vy idiot!!!

Ja zase pre zmenu nedokazem pochopit ludi, ktory si z toho ze kritizujem chyby alebo vlastnosti niektoreho programu odvodia ze ho pouzivam a zacnu mi radit aby som to nerobil.

jak se to da zrusit? Neskutecne me to sere kdyz pri nezadani www u nekterych domen musim diky presmerovani na MSN zadavat cely nazev znova.

Hledat->Vlastni

Na to je jednoducha odpoved:

Nepouzivejte Internet Explorer!!!

Staci si nainstalovat jiny prohlizec, ve kterem se spatne napsana adresa zachova i po hlaseni, ze hledanou stranku nelze zobrazit, protoze neexistuje !!!

Nechapu vubec lidi, jak jeste muzou pouzivat IE? Vzdyt ten program je 100 let za opicema? o proti jinym neumi vubec nic, ma daleko vic chyb! Bohuzel protoze ma MS monopol tak lidi neznaji nic jineho a ani nechteji nic jineho zkusit, i kdyz je to neco jineho daleko lepsi!

Jasně, nainstalujte si něco jiného a uvidíte úplně jiný Internet - tedy jeho zobrazovanou půlku. :-)))
Není lepší se naučit ten IE ovládat? A prostě si zachování špatně napsané adresy zapnout! :-]

me spis zarazi PROC vubec je na te verisigni masine otevren jinej port nez 80 ?? Domnivam se ze zamer byl pomoci prumernym uzivatelum najit pomoci prohlizece stranky ktere hledali a nebyli si jisti URL ci se jen preklepli.

Timto by se to naprosto nedotykalo jakekoli jine sluzby nez http a spokojenost by snad byla vyssi na vsech stranach (krome MSN :). Spis me zajima jak se to bude vyvijet, zda dokonce nebude casem onen prohledavaci portal zpoplatnen ci zda nedojde ke spatnemu presmerovani i pro platne domeny .. ??!

Dobry den,
nejen webem ziv je Internet.

Pokud by na te masine nemel otevreny port 25, pak by se Vase lokalni MTA snazilo dorucit dotycny e-mail nekolik dni (dle konfigurace). A Vy byste cekal a cekal a cekal ... Takhle dostanete odpoved rovnou.

Podotykam, ze uvedenou praktiku povazuji za veskrze spatnou, nicmene se neda poprit, ze nejakou uvahu nad jejim zavedenim Verisign udelal :-)

Diky tomu opet bude vice spamu v mailboxech. Drive bylo mozne odmitat e-maily z neexistujicich domen, nyni "existuji" vsechny domeny com i net. Jen pro informaci, server prez ktery projde tydne kolem 14 tisic e-mailu odmitne v prumeru 500 spamu na zaklade neexistujici domeny (com a net) v adrese odesilatele. Muzeme podekovat VeriSignu za onech 500 spamu ktere dorazi do schranek v pripade, ze server nema antispam (treba spamassassin) nebo antispam nerozpozna spam.

Ach jo...

Stejne bylo rozumne odmitat nejen neexistujici domeny, ale take ty kde IP finalniho MTA bylo "nepekne" (treba 127/8, 0/8, 10/8, 172.16/12, 192.168/16, 169.254/16, 224/3 a nektere dalsi). V sendmailu to obnaselo 12 radek testu v ".mc" souboru. A kdyz uz to clovek ma takhle, tak pridat tam jednu "zakazanou" adresu navic je ten nejmensi problem ...

Ne, ze bych tim chtel nejak snizovat prasackost konani Verisignu ...

To zakazani privatnich IPcek ma smysl jen v pripade ze mate server za NATkou a forwardujete na nej data smerujici na port 25 z verejne adresy. Potom se zakazuje RCPT TO na vnitrni IP adresu/adresy toho MTAcka. Server by mel ale automaticky odmitat vsechny e-maily ktere nemaji v domenove casti prijemce jeho domeny nebo IPcka, jinak se z toho serveru stava open-relay.

Zaroven asi nechapu co myslite tim jednu adresu navic... To co diky VeriSignu nelze nyni kontrolovat je domenova cast adresy v MAIL FROM. Spammer ted muze pouzit cokoliv (neexistujici.com, jina-neexistujici.com atd.) a jelikoz se to zresolvuje jako existujici domena mailserver to prijme. Prestoze tu domenu nema nikdo zaregistrovanou = mail z takove domeny je nesmysl.

Myslim ze VeriSign je zalovatelny za to ze toto urobil, a to prave tak ze vdaka nemu dostavate viac spamu. Staci pozbierat spamy ktore ste dostali a vycislit hodnotu kazdeho jedneho. Ak by to urobil cely svet, myslim ze by VeriSignu chytro peniaze na konte ubudli.

Tak si tu silenost prectu, vyzkousim - a ono tak funguje. Jen se clovek pta, jak si nekdo takove svinstvo muze dovolit?

Adekvatni reakce by byla "internetova demonstrace" - kazdy den v urcitou hodinu zlikvidovat servery Verisignu dos utokem. A ne na dns, ale jejich CA sluzby. Rekneme kazdy den hodinu nedostupny CRL.

Při zjišťování IP adresy se prohlížeč zeptá svého serveru doménových jmen, ten se zeptá svého nadřazeného serveru a nakonec dotaz končí u serverů autoritativních pro danou doménu nejvyšší úrovně.