Elektronická pošta představuje jedno z nejvýznamnijších využití Síťových služeb od doby, kdy byla Síť vynalezena. Původně to byla jednoduchá služba, která kopírovala soubor z jednoho počítače do druhého, kde ho připojila k souboru poštovní schránky příjemce. V zásadě tento proces představuje podstatu elektronické pošty, i když stále rostoucí Síť vedla se svými složitými směrovacími požadavky a se svým stále se zvyšujícím počtem zpráv k nutnosti vynalezení propracovanějšího schématu.
Byly vynalezeny různé standardy výměny elektronické pošty. Systémy v síti Internet se drží standardu, který byl uveden v dokumentu RFC 822 a který byl doplněn několika dalšími dokumenty RFC. Tyto dokumenty RFC popisovaly způsob přenášení speciálních znaků apod., který není závislý na počítačové platformě. Mnoho nových nápadů bylo doplněno teprve nedávno a vznikla tzv. "multimediální poštaim, kdy mohou být v poštovních zprávách obsaženy i obrázky a zvuky. Další standard definovala společnost CCITT a nazývá se X.400.
Na platformu Unixu byl přenesen poměrně velký počet programů pro přenos pošty. Jedním z nejznámějších programů je sendmail. Byl vyvinut na univerzitě v Berkeley a nyní se používá na velkém počtu platforem. Původním autorem tohoto programu je Eric Allman, který v současné době opět aktivně spolupracuje s týmem, který program sendmail vytvořil.
V Linuxu jsou dostupné dvě implementace programu sendmail, jedna z těchto implementací bude popsána v 15. kapitole. V současnosti se vyvíjí verze 8.9.
Nejvíce používaným poštovním agentem v Linuxu je program smail-3.1.28, který napsali Curt Landon Noll a Ronald S. Karr. Tento program je součástí většiny distribucí Linuxu. V následujícím výkladu ho budeme zjednodušeně označovat jako smail, i když existují i jiné verze tohoto programu, které jsou naprosto odlišné, ale jimi se zde nebudeme zabývat.
Ve srovnání s programem sendmail je program smail poměrně mladý. Mají-li se oba programy starat o poštu v malém systému, kde neexistují složité směrovací požadavky, jsou jejich možnosti přibližně stejné. Ovšem u velkých systémů vždy vyhrává program sendmail, protože má mnohem pružnější konfigurační schéma.
Oba programy sendmail a smail podporují skupinu konfiguračních souborů, které si musíte přizpůsobit. Kromě informací, které je nutné zadat, aby vůbec mohl poštovní subsystém běžet (například název místního hostitele), lze nastavovat i množství dalších parametrů. Konfiguračnímu souboru programu sendmail je zprvu velmi těžké porozumět. Vypadá podobně, jako kdyby si vaše kočka zdřímla na klávesnici, a packu měla položenou na klávese s.
Konfigurační soubory programu smail jsou strukturovanější a lze jim lépe porozumět než konfiguračnímu souboru programu sendmail, ale na druhou stranu nabízí uživateli menší volnost při nastavování chování maileru. U malých systémů UUCP nebo u malých systémů v síti Internet je však práce strávená nastavováním obou programů zhruba rovnocenná.
V této kapitole se budeme zabývat pojmem elektronické pošty a jaké problémy budete muset jako správce řešit. Kapitoly 14 a 15 vám poskytnou instrukce, jak poprvé nastavit programy smail a sendmail. Informace získané v těchto kapitolách by vám měly stačit ke zprovoznění malých systémů, avšak tyto programy nabízejí mnohem více voleb, takže při konfiguraci nejrůznějších vlastností možná strávíte spoustu hodin.
Na konci této kapitoly si ve zkratce probereme nastavení programu elm, což je na mnoha unixových systémem, včetně Linuxu, nejčastěji používaný poštovní agent.
Chcete-li získat více informací o problémech, které se týkají elektronické pošty v Linuxu, nahlédněte prosím do dokumentu Vince Skahana Electronic Mail HOWTO, který je pravidelně posílán na adresu comp.os.linux.announce.
Zdrojové distribuce programů elm, sendmail a smail také obsahují velmi rozsáhlou dokumentaci, kde byste měli najít odpovědi na většinu otázek týkajících se jejich nastavení. Hledáte-li obecné informace o elektronické poště, existuje spousta dokumentů RFC, které se tímto tématem zabývají. Dokumenty RFC jsou uvedeny v seznamu literatury na konci této knihy.
Poštovní zpráva se zpravidla skládá z textu zprávy, což je text napsaný odesílatelem, a z dat, které označují příjemce, transportní médium atd. a podobají se adrese na dopisní obálce.
Tato administrativní data spadají do dvou kategorší; v první kategoriš jsou zastoupena všechna data vztahující se k transportnímu médiu, jako je adresa zasilatele a adresa příjemce. Z tohoto důvodu se tato kategorie nazývá obálka. V závislosti na tom, kudy prochází daná zpráva, mohou být data z této kategorie transportním softwarem pozměněna.
Druhou kategoriš představují všechna data, která jsou nutná pro manipulaci s poštovní zprávou a která se nevztahují k žádnému transportnímu mechanismu. Příkladem může být řádka s předmětem zprávy, seznam všech příjemců nebo datum zaslání dané zprávy. V mnoha sítích se stalo standardem, že tato kategorie dat je uvedena před vlastní poštovní zprávou a tvoří tzv. poštovní hlavičku. Od textu zprávy je oddělena prázdným řádkem.
Ve světě Unixu používá většina transportních softwarů formát hlavičky, který byl definován v dokumentu RFC 822. Jeho původním záměrem bylo vytvořit standard pro použití v sítích ARPANET, ale protože byl navržen jako nezávislý na prostředí, byl jednoduše upraven pro použití v dalších sítích, včetně mnoha sítí založených na protokolu UUCP.
Nicméně dokument RFC 822 je pouze největším obecným standardem. Vznikly i novější standardy, a to z důvodu zvyšujících se potřeb, jako je šifrování dat, podpora mezinárodní znakové sady a podpora multimediálního rozšíření pošty (MIME).
Ve všech těchto standardech se hlavička zprávy skládá z několika řádek, které jsou odděleny znakem nový řádek. Řádku tvoří název pole, které začíná ve sloupci jedna, a vlastní pole, které je odděleno dvojtečkou a bílým místem. Formát a sémantika každého pole jsou odlišné a závisí na názvu daného pole. Pole hlavičky může pokračovat i na novém řádku v případě, že následující řádek začíná znakem TAB. Pole mohou být uspořádána v libovolném pořadí.
Typická hlavička poštovní zprávy vypadá asi takto:
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path:
Received: from brewhq.swb.de by monad.swb.de with uucp
(Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17
Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
(Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 2
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94
Date: Tue, 12 Apr 1994 15:56:49 -0400
Message-Id:
From: andyo@ora.com (Andy Oram)
To: okir@monad.swb.de
Subject: Re: Your RPC section
Všechna potřebná pole hlavičky jsou obvykle vygenerována používaným rozhraním maileru, což může být například elm, pine, mush nebo mailx. Avšak některá pole jsou volitelná a může je přidat sám uživatel. Například mailer elm vám umožní upravit část hlavičky zprávy. Další pole jsou přidána poštovním transportním softwarem. Následuje seznam obecných polí hlavičky a jejich význam:
V sítích na bázi protokolu UUCP nebývá obvykle pošta doručována přímo, ale je doručena požadovanému hostiteli přes několik zprostředkujících systémů. Posílá-li se zpráva pomocí spojení na bázi protokolu UUCP, spustí agent MTA odesílatele obvykle pomocí příkazu uux na doručujících systémech program rmail a pošle mu na standardní vstup danou zprávu.
Protože se tento proces provádí samostatně pro každou zprávu, může způsobit jak značné pracovní zatížení na hlavním poštovním serveru, tak i přeplnění dočasné fronty protokolu UUCP se stovkami malých souborů, které zabírají neúměrné množství místa na disku.
Proto vám někteří agenti MTA umožní seskupit několik zpráv pro vzdálený systém do jednoho dávkového souboru. Dávkový soubor obsahuje příkazy protokolu SMTP, které by za normálních okolností spustil místní hostitel, kdyby se použilo přímé spojení. Tento postup se označuje jako tzv. protokol BSMTP neboli dávkový protokol SMTP. Dávka je potom předána programům tsmtp nebo bsmtp na vzdáleném systému, které zpracují vstup stejným způsobem, jako kdyby došlo k normálnímu spojení.
U elektronické pošty se adresa skládá přinejmenším z názvu počítače, na kterém je uložena pošta dané osoby, a z identifikace uživatele. Tou může být buď přihlašovací jméno příjemce, nebo cokoliv jiného. Jiná poštovní adresní schémata, jako je X.400, používají obecnější množinu "atributů", které slouží k vyhledání hostitele příjemce na adresářovém serveru X.500.
Způsob, jakým je interpretován název počítače, tj. na jakém systému nakonec skončí vaše zpráva a jak se zkombinuje tento název se jménem uživatele příjemce, značně závisí na typu sítě, jíž jste účastníkem.
Systémy v síti Internet dodržují standard popsaný v RFC 822, který vyžaduje notaci user@host.domain, kde host.domain je plně kvalifikované doménové jméno daného hostitele. Spojovacím členem je znak "zavináčim (@). Protože tato notace neobsahuje směrování na cílového hostitele, ale (jedinečný) název hostitele, nazývá se tento typ notace absolutní adresa.
V původním prostředí protokolu UUCP se běžně používá forma path!host!user, kde cesta path popisuje pořadí hostitelů, kterými musí zpráva projít, než dorazí k cílovému hostiteli host. Tato forma zápisu se nazývá vykřičníková notace podle znaku vykřičníku, který se používá v jejím zápisu. Dnes již mnoho sítí založených na protokolu UUCP adoptovalo standard z dokumentu RFC 822 a tudíž bude rozumět i absolutní adrese.
Tyto dva typy adres se příliš dobře neslučují. Předpokládejme adresu ve tvaru hostA!user@hostB. Není zcela jasné, zda znak "@" bude mít přednost před cestou nebo tomu bude naopak. Pošleme zprávu hostiteli hostB, který ji pošle uživateli na adrese hostA!user, nebo pošleme zprávu hostiteli hostA, který ji doručí uživateli na adrese user@hostB?
Adresy, v nichž jsou zastoupeny různé typy operátorů adres, se nazývají hybridní adresy. Nejznámější z nich vidíte ve Výše uvedeném příkladu. Tato adresa je obvykle vyřešena tak, že operátor "@ir dostane přednost před cestou. Ve Výše uvedeném příkladu to znamená, že zpráva bude odeslána nejdříve hostiteli hostB.
Existuje však způsob, jak zadat směrování, které by vyhovovalo standardu uvedenému v dokumentu RFC 822: zápis <@hostA,@hostB:user@hostC> určuje adresu uživatele user na hostiteli hostC, kde hostitel hostC je dosažitelný přes hostitele hostA a hostB (v uvedeném pořadí). Tento typ adresy se často označuje jako tzv. směrovací adresa.
Dále existuje ještě adresový operátor "%": U adresy user%hostB@hostA bude zpráva nejprve poslána hostiteli hostA, který nahradí znak procenta vpravo (pouze v našem případě) znakem "@". Takže nyní budeme mít adresu user@hostB a mailer šťastně doručí vaši zprávu hostiteli hostB, který ji doručí uživateli user. Tento typ adresy se někdy označuje jako tzv. "Ye Olde ARPANET Kludge" a jeho používání se v současné době snažíme zabránit. Přesto však tento typ adresy i nadále generuje mnoho poštovních přenosových agentů.
Ostatní sítě stále ještě používají odlišné způsoby adresování. Například sítě na bázi DEC používají jako adresový operátor dvě dvojtečky, takže adresa má tvar host::user.
A konečně standard X.400 používá zcela odlišné schéma, které popisuje příjemce pomocí skupiny párů atribut-hodnota, například pár země a organizace.
V sítích FidoNet je každý uživatel identifikován kódem, například 2:320/204.9, který se skládá ze čtyř znaků označujících zónu (2 je pro Evropu), Síť (320 označuje Paříž a Banlieue), uzel (což je místní hub) a koncový bod (počítač PC individuálního uživatele). Adresy sítě FidoNet mohou být namapovány na standard definovaný v dokumentu RFC 822; výše uvedená adresa může být zapsána jako Thomas.Qušnot@p9.f204.n320.z2.fidonet.org.
Neříkal jsem náhodou, že názvy domén se dají lehce zapamatovat?
Použití odlišných typů adres má určité důsledky, které si popíšeme dále. Avšak v prostředí, kde platí standard definovaný v dokumentu RFC 822, budete používat jen velmi zřídka nějaké jiné typy adres, než je typ absolutních adres, jako je user@host.domain.
Proces doručování zprávy hostiteli příjemce se nazývá směrování. Kromě nalezení cesty ze systému odesilatele do cílového systému v sobě tento proces zahrnuje i kontrolu chyb a optimalizaci rychlosti a nákladů.
Existuje obrovský rozdíl ve způsobu, jakým se stará o poštu systém na bázi protokolu UUCP a systém v Internetu. V Internetu provede hlavní práci související se směrováním dat na hostitele příjemce (který je známý pomocí své IP-adresy) Síťová hladina IP, zatímco v zóně protokolu UUCP musí být směrování provedeno uživatelem nebo ho musí vygenerovat poštovní přenosový agent.
V Internetu záleží pouze na cílovém hostiteli, zda se vůbec uskuteční nějaké konkrétní směrování pošty. Implicitně je nastaveno přímé doručení zprávy cílovému hostiteli. To se provede tak, že systém vyhledá jeho IP-adresu a skutečné směrování dat ponechá na transportní hladině IP.
Většina systémů bude obvykle chtít směrovat veškerou příchozí poštu na dostupný poštovní server, který je schopen postarat se o veškerou dopravu pošty a který ji potom předá místním hostitelům. Pro svoji místní doménu oznámí systém tuto službu v databázi systému DNS pomocí tzv. záznamu MX. Zkratka MX znamená poštovní server (Mail Exchanger) a obvykle je v tomto záznamu uvedeno, že si hostitel serveru přeje pracovat jako doručovatel pošty pro všechny počítače v rámci příslušné domény. Záznamy MX lze také použít při správě pošty určené pro hostitele, kteří nejsou připojeni k Internetu, příkladem budiž sítě na bázi protokolu UUCP nebo hostitelé v sítích společností, kteří obsahují důvěrná data.
Záznamy MX mají přiřazenu tzv. prioritu. Priorita je udávána celým číslem. Má-li některý hostitel několik poštovních serverů, pokusí se poštovní přenosový agent přenést zprávu na ten poštovní server, který má nejnižší prioritu, a pouze v případě, že na tomto serveru neuspěje, se bude snažit spojit s hostitelem, který má vyšší prioritu. Je-li místní hostitel zároveň poštovním serverem pro cílovou adresu, nesmí doručit zprávu na žádného hostitele uvedeného v záznamu MX, který má vyšší prioritu než má on sám; toto je bezpečný způsob, jak zabránit vytváření poštovních smyček.
Předpokládejme, že například organizace Foobar Inc. chce veškerou poštu spravovat na svém počítači s názvem mailhub. Potom bude mít v databázi DNS přibližně následující záznam MX:
foobar.com IN MX 5 mailhub.foobar.com
Tento záznam říká, že na adrese mailhub.foobar.com bude poštovní server pro doménu foobar.com s prioritou 5. Hostitel, který chce doručit zprávu na adresu joe@greenhouse.foobar.com, vyhledá pomocí systému DNS doménu foobar.com a zjistí, že záznam MX ukazuje na hostitele mailhub. Pokud neexistuje žádný záznam MX s prioritou menší než 5, bude zpráva doručena poštovnímu serveru mailhub, který ji posléze odešle na hostitele greenhouse.
Výše uvedený příklad je skutečně pouze náčrt toho, jak pracují záznamy MX. Chcete-li více informací o směrování v síti Internet, nahlédněte prosím do dokumentu RFC 974.
Směrování pošty v sítích na bázi protokolu UUCP je mnohem komplikovanější než v síti Internet, protože vlastní transportní software neprovádí žádné směrování. Dříve musela být veškerá pošta adresována pomocí vykřičníkové notace, která uváděla seznam hostitelů, pomocí kterých se doručovala pošta. Jednotliví hostitelé byli odděleni vykřičníkem, za kterým následovalo jméno uživatele. Pokud jste chtěli adresovat dopis uživateli Janet na počítač s názvem moria, museli jste zadat cestu eek!swim!moria!janet. Tato formule poslala poštu z vašeho hostitele na hostitele eek, z něj pak na hostitele swim a nakonec dorazila pošta z hostitele swim na hostitele moria.
Zcela zřejmá nevýhoda této techniky spočívá v tom, že si musíte pamatovat Síťovou topologiš, rychlá spojení atd. Ale ještě horší věcí je, že změna v uspořádání Síťové topologie - například odstranění některých spojení nebo odstranění nějakého hostitele - může způsobit nedoručení zprávy, protože jste nebyli obeznámeni s provedenými změnami. A konečně v případě, že změníte místo svého působení, budete pravděpodobně muset aktualizovat veškerá směrování.
Z jednoho důvodu bylo nutné používat směrování od zdroje. Tím důvodem byla přítomnost nejednoznačných názvů hostitelů. Předpokládejme, že existují dva systémy s názvem hostitele moria, jeden systém se nachází ve Spojených státech amerických a druhý ve Francii.
Na který systém ale adresa moria!janet odkazuje? To bude jasné pouze až tehdy, uvedete-li cestu, pomocí které se lze spojit s hostitelem moria.
Prvním krokem, který vedl k odstraňování nejednoznačných názvů hostitelů, bylo založení projektu mapování názvů pro protokol UUCP (The UUCP Mapping Project). Tento projekt je umístěn na Rutgers University a registruje všechny oficiální názvy protokolu UUCP společně se sousedy UUCP a s jejich geografickým umístěním. Projekt zajiššuje, aby nebyl žádný název hostitele použit dvakrát. Informace získané projektem mapování názvů jsou zveřejňovány jako tzv. Usenetové mapy (Usenet Maps), které jsou pravidelně distribuovány pomocí Usenetu.
Typická položka systému v mapě vypadá (po odstranění komentářů) následovně:
moria
bert(DAILY/2)
swim(WEEKLY)
Tato položka uvádí, že hostitel moria má spojení s hostitelem bert, se kterým se spojuje dvakrát denně. Dále má spojení s hostitelem swim, s nímž se spojuje každý týden. K formátu souboru s mapami se dále ještě vrátíme.
Pomocí informací o jednotlivých spojeních, které jsou uvedeny v souborech s mapami, je možné automaticky vygenerovat celou cestu z vašeho hostitele k libovolnému cílovému systému. Tyto informace se obvykle ukládají v souboru paths, někdy se tento soubor také nazývá databáze cest. Předpokládejme, že v souboru map stojí, že s hostitelem bert se můžete spojit přes hostitele ernie. V tom případě by položka pro hostitele moria v souboru paths, který byl vygenerován z části mapy, mohla vypadat asi takto:
moria ernie!bert!moria!%s
Pokud nyní zadáte cílovou adresu janet@moria.uucp, vybere agent MTA Výše uvedené směrování a pošle zprávu na hostitele ernie a jako adresu na obálce uvede bert!moria!janet.
Není ovšem vhodné vytvářet soubor paths ze všech usenetových map. V nich jsou obvykle informace poměrně zkreslené a často i zastaralé. Z tohoto důvodu se vytváří soubor paths ze všech světových map protokolu UUCP pouze na několika hlavních hostitelích. Většina systémů spravuje pouze informace o systémech, které jsou v jejich okolí, a poštu pro hostitele, které nenajdou ve své databázi, pošlou chytřejším hostitelům, jež mají kompletnější směrovací informace. Toto schéma se nazývá směrování na chytřejší hostitele (smart-host routing). Hostitelé, kteří udržují pouze jediné poštovní spojení pomocí protokolu UUCP (takoví hostitelé se též nazývají koncové systémy (leaf sites)), sami neprovádí žádné směrování; plně se spoléhají na svého chytřejšího hostitele.
Zatím je nejlepším lékem na problémy se směrováním pošty v sítích na bázi protokolu UUCP převzetí systému DNS do sítí UUCP. Samozřejmě, že pomocí protokolu UUCP se nemůžete dotazovat jmenného serveru. Některé systémy UUCP však vytvořily malé domény, které vnitřně koordinují směrování pošty. V mapách tyto domény zveřejní pouze jednoho nebo dva hostitele, kteří budou označení jako poštovní brány. Tím pádem nemusí v mapách existovat položka pro každého hostitele, který se nachází v příslušné doméně. Brány se starají o veškerou poštu, která přichází do domény nebo která z dané domény odchází. Směrovací schéma uvnitř domény je pro okolní svět neviditelné.
Tento princip funguje velmi dobře se směrováním na chytřejší hostitele, které jsme si popsali Výše. O globální směrovací informace se starají pouze brány; vedlejší hostitelé příslušné domény vystačí pouze s ručně vytvořeným souborem paths, který uvádí směrování uvnitř jejich domény a směrování na poštovní server. Dokonce ani poštovní brány nemusí mít informace o směrování na každého hostitele protokolu UUCP, které ve světě existují. Kromě kompletních informací o směrování uvnitř jimi obsluhované domény potřebují mít ve svých databázích pouze směrování na všechny domény. Například níže uvedená položka cesty bude směrovat veškerou poštu určenou pro systémy v doméně sub.org na hostitele smurf:
.sub.org swim!smurf!%s
Veškerá pošta směřující na adresu claire@jones.sub.org bude poslána na hostitele swim s adresou smurf!jones!claire.
Hierarchické uspořádání prostoru s názvy domén umožňuje poštovním serverům kombinovat přesnější směrování s méně přesným směrováním. Například systém ve Franciš může mít přesné směrování pro subdomény v rámci domény fr, ale veškerou poštu určenou pro hostitele v doméně us bude směrovat na nějaký systém ve Spojených státech amerických.
V tomto případě směrování na základě domén (takto se tato technika označuje) značně redukuje velikost směrovacích databází a stejně tak i potřebnou administrativní režie.
Avšak hlavním přínosem použití názvu domén v prostředí sítí UUCP je, že shoda se standardem uvedeným v dokumentu RFC 822 umožňuje mezi sítěmi na bázi protokolu UUCP a sítí Internet jednoduchou průchodnost dat. V dnešní době má spousta domén UUCP spojení s internetovou bránou, která se chová jako jejich chytřejší hostitel. Posílání zpráv po Internetu je rychlejší a směrování informací je mnohem spolehlivější, protože hostitelé v Internetu mohou používat místo usenetových map systém DNS.
Aby mohl být systém na bázi protokolu UUCP dosažitelný z Internetu, uvádí obvykle internetové brány záznam MX pro domény na bázi protokolu UUCP (záznamy MX byly popsány Výše). Předpokládejme třeba, že hostitel moria patří do domény orcnet.org. Hostitel gcc2.groucho.edu se chová vůči této doméně jako internetová brána. Z toho důvodu použije hostitel moria jako svého chytřejšího hostitele adresu hostitele gcc2, takže veškeré zprávy pro cizí domény budou doručovány pomocí Internetu. Na druhou stranu hostitel gcc2 uvede záznam MX pro doménu orcnet.org a tím pádem může doručit veškerou příchozí poštu určenou pro systémy v doméně orcnet na hostitele moria.
Nyní zůstal už jen poslední problém, totiž že transportní programy protokolu UUCP neumí obsloužit plně kvalifikovaná doménová jména. Většina balíků UUCP byla navržena tak, aby zvládla názvy systémů do délky osmi znaků, některé dokonce i méně, a použití nealfanumerických kláves, jako jsou tečky, je u většiny z nich absolutně nepřípustné.
Proto je nutná existence určitého převodu mezi názvy odpovídajícími standardu, který byl definován v dokumentu RFC 822, a názvy hostitelů protokolu UUCP. Způsob, jakým je tento převod prováděn, zcela závisí na typu implementace. Obecný způsob, jak namapovat názvy FQDN na názvy protokolu UUCP, spočívá v použití mapování přímo v souboru cest:
moria.orcnet.org ernie!bert!moria!%s
Tato formule vytvoří z adresy, která udává plně kvalifikovaný název domény, čistokrevnou vykřičníkovou notaci pro použití v protokolu UUCP. Některé mailery k tomuto účelu poskytují speciální soubory; například program sendmail používá soubor uucpxtable.
Někdy se při posílání pošty ze sítě na bázi protokolu UUCP do Internetu vyžaduje zpětná transformace (která se hovorově označuje jako tzv. přiřazení domény). Pokud odesilatel pošty použije jako cílovou adresu plně kvalifikované doménové jméno, lze se tomuto problému vyhnout tak, že se při doručování zprávy chytřejšímu hostiteli neodstraní název domény z adresy na obálce. Nicméně stále ještě existují systémy, které nejsou součástí žádné domény. I takovéto systémy lze rozčlenit do domén, což se provede tak, že se k nim připojí fiktivní doména uucp.
Databáze cest poskytuje v sítích na bázi protokolu UUCP hlavní informace o směrování. Typická položka vypadá asi takto (název systému je od cesty oddělen tabulátory):
moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s
Tento záznam uvádí, že každá zpráva určená pro hostitele moria bude doručena přes hostitele ernie a bert. Je zde zadán jak plně kvalifikovaný název, tak i název pro protokol UUCP.
Oba názvy jsou zde uvedeny pro případ, že by mailer neměl samostatný způsob pro mapování mezi těmito dvěma jmennými prostory.
Pokud chcete směrovat všechny zprávy určené pro hostitele v rámci nějaké domény na jejich poštovní brány, můžete v databázi cest zadat také cestu, která bude mít jako cíl název domény, před nímž bude uvedena tečka. Pokud mohou být například hostitelé v doméně sub.org dosažitelní přes poštovní bránu swim!smurf, mohla by položka v databázi cest vypadat následovně:
.sub.org swim!smurf!%s
Vytvoření souboru cest je přijatelné pouze v případě, že provozujete systém, který neobsahuje příliš mnoho informací o směrování. Provádíte-li směrování pro velké množství hostitelů, bude lepší k tomuto účelu použít příkaz pathalias, který umí vytvořit soubor cest ze souborů map. Mapy lze spravovat daleko lépe, protože konkrétní systém lze přidat nebo odstranit tak, že v mapě upravíte jeho položku a necháte znovu vytvořit soubor map. I když se mapy zveřejňované usenetovým projektem mapování názvů zatím ke směrování moc nepoužívají, mohou menší sítě na bázi protokolu UUCP poskytovat informace o směrování pomocí svých vlastních skupin map.
Soubor map se skládá především ze seznamu systémů, ve kterém má každý systém uveden seznam systémů, s nimiž se může spojit nebo které se mohou spojit s ním. Název systému začíná ve sloupci jedna a za ním následuje seznam jednotlivých spojení, která jsou vzájemně oddělena čárkami. Seznam může pokračovat i na dalších řádcích v případě, že následující řádek začíná znakem tabulátor. Každý záznam o spojení je tvořen názvem systému, za kterým je v hranatých závorkách uvedena jeho režie. Režie představuje aritmetický výraz složený z čísel a symbolické režie. Řádky, začínající znakem (#), jsou ignorovány.
Jako příklad uvažujme hostitele moria, který se spojuje dvakrát denně s hostitelem swim.twobirds.com a jedenkrát týdně s hostitelem bert.sesame.com. Kromě toho pro spojení s hostitelem bert používá pouze pomalý modem s rychlostí 2 400 bps. Hostitel moria by měl v souboru map zveřejnit následující položku:
moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria
Poslední řádek říká, že hostitel moria může být rozpoznán i na základě svého názvu pro protokol UUCP. Všimněte si, že musí být uvedena režie DAILY/2, protože volání dvakrát denně ve skutečnosti snižuje režiš tohoto spojení na polovinu.
Při použití takovýchto souborů map je schopen příkaz pathalias vypočítat optimální směrování na libovolný cílový systém, který je uveden v souboru cest. Dále je schopen z těchto souborů vytvořit databázi cest, která může být poté používána pro směrování do těchto systémů.
Příkaz pathalias poskytuje množství dalších vlastností, například skrytí systému (tj. že systémy mohou být přístupné pouze pomocí brány) atd. Viz manuálové stránky příkazu pathalias, kde naleznete více detailů a dále i kompletní seznam režší jednotlivých spojení.
Komentáře v souboru map obvykle obsahují doplňkové informace o systémech, které jsou v tomto souboru popsány. Tyto komentáře musí odpovídat pevně stanovenému formátu, takže je lze získat z map. Například program uuwho používá k zobrazení těchto informací, které jsou mimochodem naformátovány moc hezky, databázi vytvořenou ze souborů map.
Pokud svůj systém zaregistrujete u organizace, která distribuuje svým členům soubory map, budete obvykle muset v mapě vyplnit přibližně takovýto záznam.
Následuje vzorová položka mapy (de facto jde o položku, která popisuje můj systém):
#N monad, monad.swb.de, monad.swb.sub.org
#S AT 486DX50; Linux 0.99
#O private
#C Olaf Kirch
#E okir@monad.swb.de
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U brewhq
#W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST
#
monad brewhq(DAILY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org
Bílé místo následující za prvními dvěma znaky je znak tabulátoru. Význam většiny polí je zřejmý; detailní popis obdržíte od jakékoliv domény, u které se zaregistrujete. Největší zábavou je rozluštit význam pole L: To uvádí vaše geografické umístění ve formátu zeměpisná šířka / zeměpisná délka a používá se při vykreslování postscriptových map, které ukazují všechny systémy v rámci dané země nebo všechny systémy na světě.
Zkratka elm znamená "elektronická pošta" (electronic mail) a tento program je jedním z nejvýstižněji pojmenovaných unixových nástrojů. Program elm poskytuje celoobrazovkové rozhraní s propracovanou nápovědou. Nebudeme se zde zabývat způsobem jeho použití, ale zdržíme se pouze u jeho konfiguračních voleb.
Teoreticky můžete provozovat program elm bez jakékoliv konfigurace a přitom bude vše pracovat správně - kéž byste byli šťastní. Existuje však několik voleb, které je potřeba nastavit, i když budou potřeba jen při určitých událostech.
Při startu si program elm přečte několik konfiguračních proměnných ze souboru elm.rc, který se nachází v adresáři /usr/lib/elm. Potom se pokusí přečíst z vašeho domovského adresáře soubor .elm/elmrc. Tento soubor si obvykle nebudete vytvářet sami. Program ho vytvoří za vás, když z nabídky options vyberete volbu "save options".
Sada voleb použitá v souboru elmrc je také dostupná v globálním souboru elm.rc. Většina nastavení uvedená v soukromém souboru elmrc potlačí nastavení uvedená v globálním souboru.
V globálním souboru elm.rc musíte nastavit volby, které se týkají názvu vašeho hostitele.
Například ve společnosti Virtual Brewery by mohl soubor pro hostitele vlager obsahovat následující informace:
#
# Jméno hostitele
hostname = vlager
#
# Jméno domény
hostdomain = .vbrew.com
#
# Plně kvalifikované doménové jméno
hostfullname = vlager.vbrew.com
Tyto volby poskytují programu elm informace o názvu místního hostitele. I když se tyto informace používají jen zřídka, měli byste je mít nastaveny. Poznamenejte si, že tyto informace mají význam pouze v případě, že je uvedete v globálním konfiguračním souboru; nacházejí-li se ve vašem soukromém souboru elmrc, budou ignorovány.
V minulosti byly navrženy doplňky standardu definovaného v dokumentu RFC 822, které by umožnily podporu různých typů zpráv, například prostý text, binární soubory, postscriptové soubory atd. Skupina standardů a dokumentů RFC, které vyhovují těmto aspektům, se obecně označují zkratkou MIME (Multipurpose Internet Mail Extensions). Kromě jiného tyto standardy umožňují příjemci zjistit, zda byla při psaní zprávy použita jiná znaková sada než standardní znaková sada ASCII, například francouzské akcenty nebo německé přehlásky.
V určitých mezích tyto standardy podporuje i program elm.
Znaková sada, kterou vnitřně používá operační systém Linux, se obvykle označuje jako ISO8859-1, což je název standardu, který tato znaková sada splňuje. Tento standard je také známý pod označením Latin-1. Všechny zprávy používající znaky z této znakové sady by měly mít ve své hlavičce následující řádek:
Content-Type: text/plain; charset=iso-8859-1
Přijímací systém by měl toto pole rozeznat a při zobrazování zprávy by měl provést příslušná opatření. Pro zprávy typu text/plain (prostý text) je implicitně nastaveno pole znakové sady charset na hodnotu us-ascii.
Aby bylo možné zobrazit zprávy napsané v jiné znakové sadě, než je znaková sada ASCII, musí program elm vědět, jak má tyto znaky zobrazit. Pokud program elm obdrží zprávu, ve které má pole charset jinou hodnotu než us-ASCII (nebo při zachování stejné znakové sady bude nastaven jiný typ obsahu zprávy než text/plain), pokusí se implicitně zobrazit zprávu pomocí příkazu s názvem metamail. Zprávy vyžadující pro zobrazení program metamail mají na obrazovce přehledu zobrazeno v prvním sloupci písmeno ‚M‚.
Protože je implicitní znakovou sadou operačního systému Linux znaková sada ISO-8859-1, není nutné pro zobrazení zpráv vytvořených pomocí této znakové sady používat program metamail. Je-li programu elm sděleno, že zobrazení odpovídá standardu ISO-8859-1, pak se program metamail nepoužije, ale zpráva bude zobrazena přímo. To zajistíte nastavením následující volby v globálním souboru elm.rc:
displaycharset = iso-8859-1
Pamatujte, že tuto volbu byste měli nastavit i v případě, že neplánujete posílání nebo přijímání zpráv, které obsahují jiné znaky než definuje standard ASCII. Tato volba se uvádí proto, že lidé posílající takovýto typ zpráv obvykle nakonfigurují svůj mailer tak, aby vložil do hlavičky pošty patřičné pole Content-Type:, a to bez ohledu na skutečnost, zda je či není daná zpráva napsána ve znakové sadě ASCII.
Ale pouze nastavení této volby v souboru elm.rc nestačí. Problém spočívá v tom, že při zobrazování zprávy pomocí vestavěného prohlížeče zavolá program elm pro každý zobrazovaný znak příslušnou funkci knihovny, aby zjistil, zda daný znak je či není zobrazitelný. Implicitně bude tato funkce považovat za zobrazitelné pouze znaky splňující standard ASCII a všechny ostatní znaky zobrazí jako "^?". Tento problém lze vyřešit tak, že nastavíme proměnnou prostředí LC_CTYPE na hodnotu ISO-8859-1. Tato proměnná sdělí knihovně, aby považovala za zobrazitelné všechny znaky ze znakové sady Latin-1. Podpora této i dalších vlastností je dostupná od verze knihovny libc-4.5.8.
Při posílání zpráv, které obsahují speciální znaky ze znakové sady ISO-8859-1, byste se měli ujistit, že jste v souboru elm.rc nastavili ještě další dvě proměnné:
charset = iso-8859-1
textencoding = 8bit
Tyto volby způsobí, že program elm uvede v hlavičce pošty, že příslušná zpráva byla vytvořena pomocí znakové sady ISO-8859-1 a že bude poslána ve formě 8bitových hodnot (implicitně se veškeré znaky překládají na 7bitové hodnoty).
Samozřejmě, že jakoukoliv z těchto voleb lze místo v globálním konfiguračním souboru uvést v soukromém souboru elmrc.