Budou vznikat "technologické" blacklisty?

Před několika dny jsem dostal tenhle email:

Mozna je to zpusobeno moji averzi k Micro$oftu, mozna je chyba na moji strane, ale i tak vas chci seznamit z jednou negativni zkusenosti. Rekl bych, ze ze vetsina internetove zalozenych lidi vi o existenci Strahova a jeho pocitacove site. Nase sit se vyznacuje velkou svobodou a malymi naklady za pripojeni. Proto se na Strahove delaji ruzne veci o kterych se pak povidaji jeste ruznejsi zkazky.

O tom ale nechci psat. To, o cem chci psat, je postoj nekterych velkych firem k internetu a jeho sluzbam vubec.

To, ze si Micro$oft, kdyz neco programuje, precte RFC jen velice zbezne, asi nikoho neprekvapuje. To ze z Micro$oftiho produktu obvykle nedostanete ani poradny log, natoz podrobnou informaci o pripadne chybe, take nikoho uz moc nevzrusuje.

Kazdopadne – na Strahove je pomerne prisne omezeno dorucovani a odesilani posty. Uzivatele mohou psat postu pouze se strahovskou adresou a podobne. Na Strahove vsak bezi nekolik mailing listu, ktere na sebe stahuji hodne mailu (gsm@sh.cvut.cz, program@logout.sh.cvut.cz, gaming@logout.ch.cvut.cz, …). Nekdy se stava, ze nas mailer je unaveny a nedokaze mail prijmout. At uz proto, ze nema misto na disku, nebo proto, ze nedokaze o adrese rozhodnout, jestli je, nebo neni korektni. V takovem pripade vrati chybu:

4XX – Zkus to pozdeji.

Normalni mail server tedy pocka a treba za pul hodiny udela novy pokus. Bohuzel, servery programovame u Micro$oftu se tak nechovaji. Ve snaze dorucit mail co nejdrive se ho snazi poslat nejlepe behem stejne relace, pripadne si ihned otevrou relaci novou. Protoze si prochazejici postu loguji, tak behem kratke doby zaplacaji vsechen prostor na disku /var/log a vetsina aplikaci zastavi svou cinost. Protoze si v tom nektere servery opravdu libuji, primely Strahov k bezpecnostnimu opatreni. Na strahove vznikl Black List. Na tomto seznamu je umisten server relay.atlas.cz, protoze mel potrebu alespon jednou do mesice vygenerovat mail ktery zrusil nase mailery. Na prechodnou dobu se na nej dostal napriklad www.mania.cz – stejny software, podobne problemy.

Pokud tedy pouzivate relay na server relay.atlas.cz – nedivte se, ze nemuzete nic odeslat na Strahov. Pokud se nemuzete domailovat z jineho stroje, prectete si http://www.sh­.cvut.cz/blac­klist.html, jestli jeho jmeno nebylo z nejakeho duvodu pripsano. Pochopitelne nepiseme na seznam lidi jen tak, z dlouhe chvile, ale nejprve se s nima snazime domluvit.

Jindra Fucik

Hodně lidí si teď možná řekne, že Jindra je zaměřený proti M$, nebo že je to jeho chyba. Má mít větší disk nebo rychlejší počítač, namítnou. Celá věc ale dostává jiný nádech, když se podíváte na jednu část debaty z mailové konference Bugtraq. Krátká citace (volný překlad):

„Potvrzujeme, že toto je problém služby Microsoft SMTP, dodávané s Win NT 4 Service Pack 4. Pracujeme na opravě a již brzy dokončíme testování.“

Datum 17. 3. 1999, podpis David Lemson, Microsoft SMTP Service Program Manager (dlemson@microsoft.com).

Bohužel mi není známo, jestli M$ opravdu opravu dokončil, nicméně bezmála rok poté se chová MTA na relay.atlas.cz tak, jak bylo v emailu popsáno. Problémy všelikého rázu s tímto serverem vám opravdu potvrdí asi každý, kdo provozuje nějakou větší emailovou konferenci. Já sám jsem díky jeho podivnému chování jakožto postmaster během předvčerejška a včerejška obdržel něco okolo 500 (!) chybových emailů. Server relay.atlas.cz totiž občas začne zuřivě odpovídat na adresu konference, která zprávu odmítne (neboť je poslána z nepřihlášené adresy) a už to lítá.

Znám několik lidí, kteří se z administrátory Atlasu zkoušeli domluvit a k ničemu to nevedlo. A tak chybná implementace a neochota lidské obsluhy staví zbytečné zdi mezi uživatele Internetu. Teď se například uživatelé jednoho serveru nedomailují na Strahov, aniž by nesli jakoukoliv vinu na stávající situaci. A to je docela na pováženou, nemyslíte?