Ani s poštou nemusíte mít smůlu !!

Většina oblíbených internetových služeb, s výjimkou elektronické pošty a síťových news, má interaktivní charakter, a vyžaduje tudíž existenci odpovídající „živé" přípojky k Internetu (schopné přenášet všechny potřebné protokoly TCP/IP). Na druhé straně však dnes stále ještě existuje dost uživatelů, kteří sice mají přístup k Internetu, ale jen na úrovni elektronické pošty. Mají tito uživatelé smůlu, a přichází o celé to obrovské bohatství dnešního Internetu? Naštěstí ne tak docela, protože k mnoha zajímavým službám se lze dostat i prostřednictvím elektronické pošty. Dnes si to ukážeme na příkladu „poštovního" přístupu k FTP archivům.

Na úvod ještě malé upřesnění: koho všeho se týká „poštovní" přístup do Internetu? V zásadě každého, kdo má možnost vyslat do Internetu zprávu elektronickou poštou, a stejně tak i nějakou zprávu z Internetu přijmout. Nemusí to ale nutně znamenat, že by takovýto uživatel musel používat takový druh elektronické pošty, jaký se používá právě v Internetu (a který se obecně označuje jako pošta na bázi protokolu SMTP, či zkráceně jen jako SMTP-pošta). Stačí totiž, aby mezi uživatelovým systémem a Internetem existovala vhodná poštovní brána, schopná správně konvertovat jednotlivé zprávy, přenášené mezi oběma „světy". Takovéto „SMTP brány" dnes existují snad pro všechny význačné ne-SMTP pošty, mj. pro MS Mail, cc:Mail, a z tuzemských například Mail602. Takže v praxi jde spíše o to, zda je takováto brána mezi vaším systémem elektronické pošty a Internetem nainstalována a provozována.

Nyní ale již zpět k dnešnímu tématu, tedy k přenosu souborů z FTP archivů prostřednictvím elektronické pošty. Je poněkud paradoxní, že právě přenos souborů bývá uváděn jako typický příklad operace dávkového, a nikoli interaktivního charakteru. Například ještě v síti Earn/BITNET, kterou si mnozí akademičtí uživatelé jistě budou dobře pamatovat, byl přenos souborů skutečně implementován jako neinteraktivní služba (jistě i proto, že síť Earn/BITNET interaktivní způsob práce vůbec nepodporovala). Nicméně v Internetu je přenos souborů standardně realizován protokolem FTP (File Transfer Protocol), který funguje interaktivně. Předpokládá tedy, že uživatel bude průběžně zadávat své požadavky, a FTP server je bude průběžně plnit - když přijme požadavek k provedení určité akce, okamžitě ji provede, pošle odpověď, a pak bude čekat na další příkaz. Nepočítá naopak s tím, že by mu bylo možné předem zaslat celou skupinu příkazů, které by nejprve všechny provedl, a teprve pak odeslal zpět výsledek. Proto není možné možné využívat protokol FTP bez možnosti interaktivního přístupu k příslušnému serveru. Nebo by se snad našla nějaká skulinka?

Naštěstí našla. Je založena na velmi jednoduché myšlence: nemáte-li možnost interaktivního přístupu vy, můžete se s domluvit s někým, kdo tuto možnost má. Jemu pak najednou zašlete všechny své požadavky (typu co a odkud chcete stáhnout), on se vaším jménem obrátí na příslušný FTP server, a v interaktivním režimu si s ním vykoresponduje vše potřebné.

Na stejném principu může fungovat „poštovní" přístup k většině interaktivních internetových služeb. V konkrétním případě přenosu souborů z FTP archivů se zmíněný „zprostředkovatel" obvykle označuje jako FTPMAIL server. Je to ve své podstatě trvale běžící program, s vlastní poštovní adresu, kterému můžete své požadavky poslat prostřednictvím elektronické pošty. On se pak za vás přihlásí k takovému FTP serveru, který jste mu určili, sám si k sobě „stáhne" soubory (prostřednictvím protokolu FTP), a obratem je zase pošle vám - tentokráte ale již prostřednictvím elektronické pošty.

Chcete-li si to vyzkoušet, musite nejprve zjistit adresu vhodného FTPMAIL serveru. Doporučuji vám tuzemský FTPMAIL server, který provozují v Liberci. Jeho adresa je: ftpmail@ftp.vslib.cz. Když mu pošlete zprávu, a v jejím těle kouzelné slovíčko help, pošle vám stručný návod k použití. Ten vidíte na dnešním prvním obrázku [GIF1] (spolu s žádostí o jeho zaslání, v horním okénku)). Způsob komunikace se serverem FTPMAIL je poměrně jednoduchý, a zmíněný návod i s příklady na dnešním druhém [GIF2] a třetím [GIF3] obrázku vám snad postačí k úspěšné domluvě s tímto serverem.

Přesto bych se ale rád zastavil u jedné velmi podstatné skutečnosti, která nemusí být na první pohled zřejmá. Snad již tušíte, že systém elektronické pošty, používaný v Internetu, není obecně schopen přenášet cokoli jiného, než jen čisté ASCII texty (neboli posloupnosti pouze sedmibitových znaků). Tedy žádné texty s háčky a čárkami, žádné binární soubory apod. Jedinou možností je takovéto ne-ASCII data převést do podoby posloupnosti čistých (sedmibitových) ASCII znaků, přenést je, a na druhé straně je zase vrátit zpět do jejich původní podoby.

Existuje samozřejmě více možností, jak toho dosáhnout - jedním z nich je tzv. uuencodeování, pocházející ještě z ranných dob Unixových komunikací a vlády protokolů UUCP. A právě tuto možnost používá většina serverů FTPMAIL (včetně Libereckého). Pokud si tedy necháte „stáhnout" nějaký soubor, který bude FTPMAIL server považovat za binární, sám jej automaticky „za-uuencoduje", čímž z něj vyrobí elektronickou poštou přenositelný text, a teprve pak vám jej pošle (to je také důvod, proč mu musíte explicitně říci, zda je požadovaný soubor čistě textový, nebo binární). Pokud na své straně používáte nějaký alespoň trochu inteligentní program pro práci s elektronickou poštou (poštovní klient), měl by být schopen sám poznat, že v přijaté zprávě je jako příloha obsažen nějaký „za-uuencodeovaný" soubor, a měl by vám zprostředkovat jeho snadné „vybalení". Konkrétní příklad (s využitím volně šiřitelného programu Pegasus Mail) vidíte na dnešním třetím obrázku [GIF3]- v okénku nejvýše nahoře je původní žádost k serveru, v prostředním okénku je odpověď, obsahující vložený soubor, a v nejspodnějším okénku je nabídka poštovního klienta k „vybalení" tohoto souboru.

Co ale dělat v případě, kdy vás poštovní klient nepatří mezi ty dostatečně inteligentní, schopné správně detekovat a oddekódovat zakódované soubory? V takovém případě vám nezbývá, než vzít zakódovaný text („vyexportovat" jej do vhodného textového souboru), a svěřit jeho dekódování jinému, nejspíše samostatnému programu. To ale může narazit na drobný problém - kde tento dekódovací program vzít? Jedno možné řešení ukazuje dnešní třetí obrázek [GIF3] - nechte si takovýto program poslat! Všechny potřebné údaje i vzor požadavku na FTPMAIL server najdete na zmíněném obrázku.

Že vám je tato rada k ničemu, když váš poštovní klient neumí provést potřebné dekódování? Máte pravdu. V tom případě se raději pozeptejte u správce své sítě, nebo u kolegů, zda vhodný dekódovací program pro „uu-dekódování" nemají po ruce. Ale i když neuspějete, neházejte ještě flintu do žita. Ještě je zde jedna možnost, byť poněkud náročnější. Můžete si totiž nechat poslat zdrojový tvar jednoduchého dokódovací programu (na dnešním druhém obrázku [GIF2] vidíte výpis adresáře FTP archivu na pražské VŠE, kde takovéto věci najdete - k dispozici je zde zdrojový tvar v jazyku C, v Turbo Pascalu a v Basicu). Podstatné je přitom to, že zdrojový tvar je čistým ASCII textem, s jehož přenosem problémy nejsou. Pak již jen zbývá sehnat vhodný překladač, a umět zadat překlad ....

Na závěr ale ještě jedno varování, které nevyzní příliš optimisticky. Co se stane v případě, kdy si od FTPMAIL serveru necháte poslat nějaký větší binární soubor? Tam totiž vstupuje do hry skutečnost, že různé systémy elektronické pošty kladou různá omezení na maximální možnou velikost jednotlivých zpráv. Pokud by vám měl FTPMAIL server poslat nějaký soubor, jehož zakódovaný tvar se do tohoto velikostního limitu nevejde, musí jej server nutně rozdělit na několik menších částí, a poslat vám jej „per partes", v samostatných zprávách. Konkrétní příklad vidíte na dnešním čtvrtém obrázku [GIF4]. Jak ale správně „vybalit" takto roztrhaný binární soubor?

Nejprve je třeba přesně vědět, co a jak odesilatel udělal, když odesílaný soubor rozděloval. Jak jsem měl možnost si sám ověřit, Liberecký server nejprve vezme celý soubor, a zakóduje jej (pomocí tzv. uuencodeování). Teprve pak se dívá, jestli je výsledný tvar příliš veliký, než aby jej bylo možné poslat celý najednou (větší než cca 64 kB). Pokud je příliš veliký, server jej mechanicky „rozřeže" na vhodně velké části, a ty pak skutečně odešle v samostatných zprávách. Praktickým důsledkem tohoto postupu je skutečnost, že v první zprávě bude hlavička, obsahující mj. jméno původního souboru, a v poslední zprávě bude zase nezbytná koncovka (klíčové slovo end). I velmi chytrý poštovní klient, za jaký považuji můj oblíbený program Pegasus Mail, si na tom vylámal zuby - u první zprávy sice podle hlavičky rozpoznal zakódovanou přílohu, ale kvůli chybějící koncovce ji nedokázal úspěšně „vybalit". U ostatních dílčích zpráv pak Pegasus vůbec nepoznal, že mají nějakou přílohu. Jediným řešením, na které jsem přišel, bylo vzít vhodný textový editor, a s jeho pomocí poskládat jednotlivé části zakódované přílohy do jednoho kusu tak, aby je bylo možné úspěšně dekódovat. Je to ale řešení, před kterým bych spíše varoval, a ne jej doporučoval - rozhodně se o něj nepokoušejte, pokud si nejste dostatečně „jisti v kramflecích". Pokud vás napadne nějaké vhodnější řešení, napište mi o něm.

No a úplně na závěr ještě jeden příslib do budoucna - jak jsem již naznačil výše, čistě „poštovní" přístup je možný i k dalším službám, než jen k FTP archivům. Časem si o těchto možnostech také něco řekneme. Pokud jste ale nedočkaví, můžete si vše potřebné zjistit už teď. V Internetu totiž existuje jeden zajímavý dokument, věnovaný právě problematice „poštovního" přístupu k nejrůznějším službám. Navíc tento dokument patří mezi těch několik málo volně šiřitelných dokumentů zahraniční provenience, které byly přeloženy i do češtiny. Návod k získání této české verze ukazuje dnešní pátý obrázek [GIF5]. Jak mne ale informovali moji kolegové, zdaleka ne všechny možnosti, popisované v tomto dokumentu, jsou v současnosti dostupné, resp. provozované.

Seznam obrázků:

předchozí část | první část | další část