Vlákno názorů k článku Nová služba veřejnosti, či degradace Internetu? od J.Kastl - Mohu se jk zeptat. proč k onomu blábolu...

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.

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.

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.

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

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

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

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

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.

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í?

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

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.

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 vite, nejtezsi stredni skola v CR (VSE) musi ukazat, ze ste LAMERI. <P>
A nevic nepouzivate BITNET (II).

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

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

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.

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

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.

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.

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.

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

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.

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

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

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

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.

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 ?

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.

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.

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

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.

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?

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.

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.

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?

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.

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

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

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

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

Pri neexistenci MX zaznamu se dorucuje na prvni A zaznam.

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

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