redachi. Nesmotrya na eto, otnositel'no bol'shie neproizvoditel'nye zatraty( po sravneniyu s potokovym protokolom), delayut paketnyj protokol neeffektivnym dlya ispol'zovaniya poverch TCR. SHirina puti dannyh takzhe daet razlichie. Inogda posylka vos'mibitovyh simvolov nad posledovatel'nym soedineniem nevozmozhna, naprimer, esli - 240 - soedinenie prsmatrivaet glupyj server terminala. V etom sluchae, simvoly s vos'mym naborom bitov dolzhny citirovat'sya na peredache. Kogda Vy peredaete vos'mibitovye simvoly nad soedineniem s sem'yu liniyami, oni dolzhny byt' Soglasno predpolozheniyam s samym plohim sluchaem, eto udvaivaet kolichestvo dannyh, kotorye budut peredany, hotya szhatie, vypolnennoe apparatnymi sredstvami mozhet kompensirovat' etot. Stroki, kotorye mogut peredavat' proizvol'nye vos'mibitovye simvoly, obychno nazyvayutsya vos'mibitovymi chistymi. Delo obstoit tak dlya vseh soedinenij TCP, takzhe kak dlya bol'shinstva soedinenij modema. Sleduyushchie protokoly dostupny s Taylor UUCP 1.04: g - naibolee obshchij protokol i mozhet byt' ponyatym virtual'no vsemi uucico's.On delaet polnuyu proverku oshibok i sledovatel'no horosho podhodit dlya plohih telefonnyh linij. g trebuet vos'mibitovogo chistogo soedineniya.|to - paket-orientirovannyj protokol, kotoryj ispol'zuet metodiku podvizhnogo okna. i - yavlyaetsya dvunapravlennym paketnym protokolom, kotoryj mozhet posylat' i poluchat' fajly odnovremenno. Trebuetsya dupleksnoe soedinenie i vos'mibitovyj put' dannyh.On v nastoyashchee vremya raspoznaetsya tol'ko Taylor UUCP. t - protokol, prednaznachennyj dlya ispol'zovaniya nad soedineniem TCP, ili drugimi, svobodnymi ot oshibok. Ispol'zuet pakety v 1024 bajtov i trebuet vos'mibitovogo chistogo soedineniya. e - analog t, no tol'ko potokovyj. f - prednaznachen dlya ispol'zovaniya s nadezhnym X. 25 soedineniem. |to potokovyj protokol, zhelatelen semibitovyj put' dannyh. Vos'mibitovye simvoly citiruyutsya, chto mozhet sdelat' peredachu neeffektivnoj. G - realizaciya g-protokola v System V Relgase"4. Takzhe raspoznaetsya i nekotorymi drugimi versiyami UUCP. - 241 - a - protokol similiar k ZMODEM. Trebuetsya vos'mi razryadnoe soedinenie, citiruyutsya nekotorye upravlyayushchie simvoly podobno XON i XOFF. 13.6.2 Nastrojka Protokola Peredachi Vse protokoly uchityvayut nekotoroe izmenenie v razmerah paketa, blokirovkah po vremeni, i t.p.. Obychno znacheniya po umolchaniyu, obespechivayushchie rabotu pri standartnyh obstoyatel'stvah, ne optimal'ny dlya vashej sistemy. Protokol g, naprimer, ispol'zuet razmery okna ot 1 do 7, i razmery paketa v stepenyah 2 v predelah ot 64 do 4096. (14), esli vasha telefonnaya liniya obychno nastol'ko shumnaya, chto teryaetsya bolee 5% vseh paketov, Vy dolzhny umen'shit' razmer paketa i sokratit' okno. S drugoj storony, na ochen' horoshih telefonnyh liniyah neproizvoditel'nye zatraty protokola pri posylke zaprosa cherz kazhdye 128 bajt mogut okazzat'sya rastochitel'nymi, tak chto Vy mozhete uvelichivat' razmer paketa do 512 ili dazhe 1024. Taylor UUCP obespechivaet mehanizm nastrojki etih parametrov komandoj protocol-parameter v fajle sys. Naprimer, chtoby ustanovit' paket protokola g v 512 bajt pri obmene s pablo: system pablo protocol-parameter g packet-size 512 14. Bol'shinstvo binaries vklyuchennyh v distributivy Linux ustanavlivayut po umolchaniyu razmer okna 7 ,razmer paketa 128 bajt . Nastraivaemye parametry i ih nazvaniya izmenyayutsya ot protokola k protokola. Dlya polnogo spiska sm. dokumentaciyu,postavlyaemuyu s Taylor UUCP. 13.6.3 Vybor Specificheskih Protokolov Ne kazhdaya realizaciya uucico ponimaet kazhdyj protokol, tak chto v techenie nachal'noj fazy rukopozhatiya, oba processa dolzhny dogovorit'sya ob obshchem protokole.Glavnyj uucico predlagaet podchinenomu spisok obespechivaemyh - 242 - protokolov, posylaya Pprotlist, iz#kotorogo podchinennyj mozhet vybirat'. Osnovyvayas' na tipe ispol'zuemogo porta (modem, TCP, ili pryamoj), uucico sostavit zadannyj po umolchaniyu spisok iz protokolov. Dlya modema i pryamyh soedinenij, etot spisok obychno vklyuchaet i, a, g, G, j i f. Dlya soedinenij TCP, spisok - t, e, ya, a, peregruzka, G, j, i f. Vy mozhete izmenit' etot zadannyj po umolchaniyu spisok komandoj protocols, kotoraya mozhet byt' opredelena vo vhode sistemy takzhe kak vhode porta. Naprimer, Vy mogli by zapisat' v fajl port primerno sleduyushchee: port serial1 protocols igG |to trebuet lyubogo vhodyashchego ili ishodyashchego soedineniya cherez etot port, chtoby ispol'zovat' i,g, ili G., esli udalennaya sistema ne podderzhivaet nikakoj iz nih, dialog poterpit neudachu. 13.7 Poisk neispravnostej |tot razdel opisyvaet vozmozhnye neispravnosti v vashem soedinenii UUCP, i daet vozmozhnye puti ih ispravleniya. Odnako my byli prosto ne v sostoyanii ohvatit' vse vozmozhnye varianty. V lyubom sluchae, vklyuchite otladku opciej -xall, i smotrite na vyvod v fajle Debug v kataloge spool. |to pomozhet Vam bystro raspoznt', gde proishodit sboj. Takzhe, ya vsegda nahodil poleznym vklyuchat' dinamik modema, kogda soedinenie ne udavalos'. S Hayes-sovmestimymi modemami eto mozhno sdelat', dobaviv " ATL1M1 OK " k druzheskoj besede modema v fajle dial. Pervym delom stoit proverit' vse li prava dostupa k fajlam ustanovleny pravil'no. Uucico dolzhen prinadlezhat' uucp, i vse fajly v /usr/lib/uucp, /var/spool/uucp i /var/spool/uucppublic dolzheny prinadlezhat' uucp. Imeyutsya takzhe nekotorye skrytye fajly (15) v kataloge spool, kotorye takzhe dolzhny prinadlezhat' uucp. Uucico mozhet skazat' "Wrong time to call "(" Nepravil'noe vremya - 243 - vyzova "). |to mozhet znachit',chto v fajle sys , Vy ne opredelili komandu time, kotoraya opredelyaet, kogda udalennaya sistemv mozhet vyzyvat'sya, ili fakticheski zapretili zahod v tekushchee vremya. Esli vremya obrashcheniya ne zadano, uucico prinimaet, chto sistema nikogda ne mozhet vyzyvat'sya. Uucico zhaluetsya, chto sistema uzhe blokirovana. |to oznachaet ,chto uucico obnaruzhil fajl blokirovki dlya udalennoj sistemy v /var/spool/uucp. Fajl blokirovki mozhet ostat'sya starogo obrashcheniya k sisteme, esli ee rabota byla prervana nekorrektno. Odnako takzhe pravdopodobno, chto est'drugoj process uucico, kotoryj probuet nabrat' udalennuyu sistemu i zastrevaet v scenarie druzheskoj besedy, i t.d.. Esli etot process uucico ne preuspel v soedinenie s udalennoj sistemoj, unichtozhte ego, i udalite vse fajly blokirovki, kotorye on ostavil. YA mogu soedinit'sya s udalennoj sistemoj, no proishodit sboj scenariya druzheskoj besedy: Rassmotrite tekst, kotoryj Vy poluchaete ot udalennogo mesta. Esli on iskazhen, eto mozhet byt' svyazano s bystrodejstviem. Inache, podtverdite, soglashaetsya li eto dejstvitel'no, tem, chto vash scenarij druzheskoj besedy ozhidaet. Pomnite, chto scenarij druzheskoj besedy nachinaetsya s ozhidayushchejsya strokoj. Esli Vy poluchaete podskazku vhoda v sistemu, zatem posylaete imya, no ne poluchaete podskazku parolya, vstav'te nekotorye zaderzhki pered posylkoj etomu, ili chetnomu promezhutku simvoly. Vy mozhete byt' slishkom bystry dlya vashego modema. Moj modem ne soedinyaetsya: Esli vash modem ne ukazyvaet, chto DTR liniya byla ustanovlena, kogda uucico vyzyvaet,vozmozhno Vy zadali nepravil'noe ustrojstvo uucico. Esli vash modem raspoznaet DTR, sver'tes' s a 15. To est' fajly, ch'i imya nachinaet s tochki. Takie fajly obychno ne otobrazhayutsya komandoj ls. Programma terminala, kotoruyu Vy mozhete zapisyvat' k etomu. Esli eto rabotaet, vklyuchite otobrazhenie na ekrane k \E v nachale druzheskoj besedy modema. Esli eto ne delaet ECHO vashi komandy v techenie druzheskoj besedy modema, prover'te, yavlyaetsya li vashe bystrodejstvie stroki slishkom vysoko ili nizpo dlya vashego modema. Esli Vy vidite ECHO, prover'te, otklyuchili li Vy otvety modema, ili ustanavlivaete ih k kodam chisla. Proverite, chto scenarij druzheskoj besedy neposredstvenno pravilen. Ne zabud'te, chto Vy dolzhny zapisat' dve naklonnyh cherty vlevo, chtoby poslat' tot modemu. Moj modem probuet soedinyatsya, no ne mozhet: Vstav'te zaderzhku v nomer - 244 - telefona. |to osobenno polezno kogda nabor idet iz vnutrennej telefonnoj seti kompanii. Esli vy obychno pol'zuetes' impul'snym naborom,poprobujte tonovyj. V nekotoryh stranah moshchnosti telefonnyh setej narastili nedavno i tonovyj nabor inogda pomogaet. log fajl govorit, chto ya imeyu chrezvychajno vysokie poteri peredachi: |to pohozhe na problemu bystrodejstviya. Vozmozhno svyaz' mezhdu komp'yuterom i modemom takzhe medlenna (ustanovite ee dlya samoj vysokoj effektivnoj skorosti)? Ili eto vashi apparatnye sredstva, kotorye yavlyayutsya takzhe medlenno k servisnym preryvaniyam vovremya? S NSC 16550A chipset na vashem posledovatel'nom porte, 38kbps rabotaet horosho; odnako, bez FIFOs (podobnyh 16450 chipam), 9600 bit\sek - verhnij predel skorosti. Takzhe Vy dolzhny udostoverit'sya, chto apparatnoe rukopozhatie dopuskaetsya na posledovatel'noj linii. Drugaya veroyatnaya prichina - apparatnoe rukopozhatie ne dopuskaetsya na porte. Taylor UUCP 1.04 ne imeet nikakih sredstv dlya vklyucheniya RTS/CTS rukopozhatiya. Vy dolzhny sdelat' eto yavno iz rc.serial ispol'zovanie sleduyushchej komandy: $ Stty crtscts < /dev/cua3 YA registriruyus' v, no proishodit sboj rukopozhatiya: Horosho, mozhet imet'sya ryad problem. Vyvod v registracionnom fajle dolzhen soobshchit' Vam mnozhestvo. Rassmotrite to, kakim protokolam udalennye predlozheniya mesta (|to posylaet stroku Pprotlist v techenie rukopozhatiya). Vozmozhno oni ne imeyut lyubogo v obshchem (Vy vybiraete lyubye protokoly v sistemnom ili port?). Esli udalennaya sistema posylaet RLCK, imeetsya prosrochennyj lockfile dlya Vas na udalennoj sisteme. Esli vy uzhe ne soedineny s udalennoj sistemoj na zhrugoj linii poprosite udalit' ego. Esli ona posylaet RBADSEQ, drugoe mesto imeet proverki scheta dialoga, dopuskaemye dlya Vas, no chisla ne sootvetstvovali. Esli eto posylaet RLOGIN, Vas ne razreshali k vhodu v sistemu pod etim identifikatorom. 13.8 Registracionnye Fajly Pri kompilirovanii nabora programm UUCP na ispol'zovanie registracii taylor-stilya, Vy imeete tol'ko tri global'nyh registracionnyh fajla,kotorye - 245 - nahodyatsya v kataloge spool. Osnovnoj registracionnyj fajl nazyvaetsya Log i soderzhit vsyu informaciyu otnositel'no ustanovlennyh soedinenij i peremeshchennyh fajlov. Tipichnyj Log-fajl vyglyadit primerno tak uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3) uucico pablo - (1994-05-28 17:15:39.25 539) Login successful uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful protocol 'g' packet size 1024 window 7) uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj ucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2 uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1 uucico pablo - (1994-05-28 17:15:59.05 539) Protocol 'g' packets: sent 15, resent 0, received 32 uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26 seconds) uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1 (rmail okir) Sleduyashchij"vazhnyj registracionnyj fajl - Stats, kotoryj soderzhit statistiku peredachi fajlov. Razdel Stats sootvetstvuyushchij vysheupomyanutoj - 246 - peredache pohodit na eto: postmaster pablo (1994-05-28 17:15:44.78) received 1714 bytes in 1.802 seconds (951 bytes/sec) postmaster pablo (1994-05-28 17:15:46.66) received 57 bytes in 0.634 seconds (89 bytes/sec) postmaster pablo (1994-05-28 17:15:49.91) received 1898 bytes in 1.599 seconds (1186 bytes/sec) postmaster pablo (1994-05-28 17:15:51.67) received 65 bytes in 0.555 seconds (117 bytes/sec) postmaster pablo (1994-05-28 17:15:55.71) received 3217 bytes in 2.254 seconds (1427 bytes/sec) postmaster pablo (1994-05-28 17:15:57.31) received 65 bytes in 0.590 seconds (110 bytes/sec) Tretij fajl - Debug. V nem soderzhitsya otladochnaya informaciya. Esli Vy ispol'zuete otladku, Vy dolzhny udostoverit'sya, chto etot fajl imeet rezhim zashchity 600. V zavisimosti ot rezhima otladki, kotoryj Vy vybrali, on mozhet soderzhat' imya vhoda v sistemu i parol', kotoryj Vy ispol'zuete dlya soedineniya s udalennoj sistemoj. Nekotorye UUCP binaries vklyuchennye v distributivy Linux-a kompilirovalis', chtoby ispol'zovat' registraciyu HDB-stilya. HDB UUCP ispol'zuet celuyu svyazku registracionnyh fajlov, sohranennyh v /var/spool/uucp/.Log. |tot katalog soderzhit eshche tri kataloga, kotorye nazyvayutsya uucico, uuxqt, i uux. Oni soderzhat vyvod, sgenerirovannyj kazhdoj iz sootvetstvuyushchih komand, sortiruemyj v razlichnye fajly dlya kazhdoj sistemy. Takim obrazom, vyvod uucico pri vyzove sistemy pablo pojdet v .Log/uucico/pablo, v to vremya kak uuxqt zapishet v .Log/uuxqt/pablo. Stroki, zapisannye v razlichnyj lofiles - takie zhe kak i pri registracii Taylor. Kogda Vy vklyuchaete otladku s HDB-stilem, vyvod pojdet v .Admin v /var/spool/uucp. Pri soedinenii iz vashej sistemy, informaciya ob otladke budet poslana v Admin/audit.locan, v to vremya kak vyvod uucico pri vyzove izvne budet idti k .Admin/audit. - 247 - 14. |lektronnaya pochta Odno iz naibolee vidnyh ispol'zovanij setej nachinaya s pervyh setej - eto elektronnaya pochta. Ona nachinalas' kak prostoe obsluzhivanie, tipa kopirovaniya fajla odnoj mashiny dlya drugoj, i konkatenirovaniya ego k mailbox fajlu poluchatelya. V osnovnom email etim i zanimaesya, hotya vozrastastayushchaya set' s kompleksom trebovanij i uvelicheniem zagruzki soobshchenij sdelala neobhodimoj bolee slozhnuyu shemu. Byli izobreteny razlichnye standarty obmena pochty. Mnogo usilij bylo prilozheno dlya sozdaniya " mul'ti-medijnoj pochty '', kotoraya vklyuchaet izobrazheniya i zvuk v soobshcheniya pochty. Ochen' bol'shoe kolichestvo programm transportirovki pochty bylo vypolneno dlya sistemy Un*x. Odna iz luchshe vsego izvestnyh - sendmail Universiteta Berkeley. Pervonachal'nyj avtor Eric Allman teper' aktivno rabotaet nad sendmail snova. Imeyutsya dva Linux porta dostupnyh dlya sendmail-5.56c, odin iz kotoryh budet opisan v glave 16 .., v nastoyashchee vremya razrabatyvaemaya versiya sendmail - 8.6.5. Pochtovyj agent, naibolee ispol'zuemyj s Linux - smail-3.1.28, kotoryj napisan i obespechen avtorskim pravom Curt Landon Noll i Ronald S. Karr. On vklyuchen v bol'shinstvo postavok Linux. V posleduyushchem, my budem obrashchat'sya k nemu prosto kak smail, hotya imeyutsya drugie versii, kotorye polnost'yu otlichny, i kotorye my ne opisyvaem zdes'. Sravnivaya s sendmail, smail dovol'no molod. Pri obrabotke pochty bez slozhnyh trebovanij marshrutizacii, ih vozmozhnosti - dovol'no blizki. Dlya bol'shih trebovanij, odnako, sendmail vsegda pobezhdaet, potomu chto ego shema konfiguracii namnogo bolee gibka. I smail i sendmail podderzhivayut nabor fajlov konfiguracii, kotorye dolzhny byt' nastroeny. Krome informacii, kotoraya - 248 - trebuetsya dlya zapuska podsistemy pochty (tipa lokal'nogo hostname), imeetsya namnogo bol'she parametrov, kotorye mogut byt' nastroeny. Fajl konfiguracii sendmail snachala ochen' trudno ponyat' Vyglyadit, kak budto vasha koshka hodila po vashej klaviature s nazhatoj klavishej SHIFT. Smail fajly konfiguracii bolee strukturny i proshche dlya ponimaniya chem sendmail, no ne dayut pol'zovatelyu tak mnogo svobody v nastrojke povedeniya mailer'ov. Odnako, dlya malogo UUCP ili Internet rabota, trebuemaya dlya ustanovki lyubogo iz nih - priblizitel'no ta zhe samaya. V etoj glave, my budem imet' delo tem, chem email yavlyaetsya i s kakimi problemami Vy, kak administrator budete dolzhny imet' delo. Glavy 15. i 16. dadut instrukcii po ustanovke smail i sendmail vpervye. K koncu tekushchej glavy my kratko opishem ustanovku pol'zovatelya pochty na mnogih Unix-podobnyh sistemah, vklyuchaya Linux. Dlya polucheniya bolee podrobnoj informacii otnositel'no elektronnoj pochty na Linux, pozhalujsta obratites' v Electronic Mail HOWTO Vince Skahan, kotoryj zaregistrirovan comp.os.linux.announce regulyarno. 14.1 CHto takoe - Soobshcheniya Pochty? Soobshchenie Pochty voobshche sostoit iz tela soobshcheniya, kotoroe yavlyaetsya tekstom, napisannym otpravitelem, i special'nyh dannyh, opredelyayushchih poluchatelej, transportnuyu sredu, i t.d., podobno tomu, chto Vy vidite kogda Vy rassmatrivaete pochtovyj konvert. |ta administrativno-upravlencheskaya informaciya otnositsya k dvum kategoriyam; v pervom klasse - lyubye dannye, kotoryj yavlyaetsya specificheskimi dlya transportnoj sredy, podobno adresu otpravitelya i poluchatelya. |to sledovatel'no nazyvaetsya konvertom ili obolochkoj. |to mozhet byt' preobrazovano transportnym programmnym obespecheniem, pri peredache soobshcheniya. Vtoraya - lyubye dannye, neobhodimye dlya obrabotki soobshcheniya pochty, kotorye - ne chast' lyubogo transportnogo mehanizma, tipa podchinennoj stroki soobshcheniya, spiska vseh poluchatelej, i daty. V mnogih setyah, stalo standartnym dobavlyat' eti dannye k soobshcheniyu - 249 - pochty, formiruya tak nazyvaemyj zagolovok pochty. |to otdeleno ot tela pochty pustoj strokoj. (1) 1. Obychno dobavlyayutsya signatura ili .sig k soobshcheniyu pochty, obychno soderzhashchaya informaciyu otnositel'no avtora, naryadu s shutkoj ili devizom. Ona otdelyaetsya ot soobshcheniya pochty strokoj, soderzhashchej "--". Bol'shinstvo programmnogo obespecheniya dlya transporta pochty v mire Unix ispol'zuet format zagolovka, vydelennyj v RFC 822. Ego pervonachal'naya cel' - opredelit' standart dlya ispol'zovaniya na ARPANET. RFC 822 odnako - tol'ko samyj obshchij. Bolee sovremennye standarty byli zadumany, chtoby spravit'sya s vozrastaniem potrebnostej kak, naprimer, shifrovanie dannyh, podderzhka nabora internacional'nogo simvola, i mul'ti-sredstv rasshireniya pochty (MIME). Vsego eti standarty, zagolovka sostoyat iz otdel'nyh strok, otdelyaemyh simvolami perevoda stroki. Tipichnyj zagolovok pochty mozhet vyglyadet' sleduyushchim obrazom: 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 MET DST Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp (Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 21:47 MEST Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 - 0400 Date: Tue, 12 Apr 1994 15:56:49 -0400 Message-Id: <199404121956.PAA07787@ruby> From: andyo@ora.com (Andy Oram) To: okir@monad.swb.de Subject: Re: Your RPC section Obychno, vse neobhodimye polya zagolovka generiruyutsya Vashim mailer`om, naprimer elm (elektronnaya pochta), pine, mush, ili mailx. Nekotorye odnako neobyazatel'ny, i mogut byt' dobavleny pol'zovatelem. |lektronnaya pochta, naprimer, pozvolyaet Vam redaktirovat' chast' zagolovka soobshcheniya. From: |to soderzhit adres email otpravitelya, i vozmozhno "real'noe - 250 - imya''. To: |to - adres email poluchatelya. Subject: Opisyvaet soderzhanie pochty v neskol'kih slovah. Po krajnej mere dolzhen. Date: Data posylki pochty. Reply-To: Opredelyaet adres dlya otveta poluchatelya. |to mozhet byt' polezno, esli Vy imeete neskol'ko adresov, no hotite poluchat' bol'shuyu chast' pochty tol'ko na tom, kotoryj Vy ispol'zuete naibolee chasto. |to pole neobyazatel'no. Oranization: organizaciya, kotoraya obladaet mashinoj iz kotoryj pochta ishodit. |to pole neobyazatel'no. Message-ID: stroka, sgenerirovannaya transportirovshchikom pochty. Ona unikal'na dlya etogo soobshcheniya. Received: Kazhdyj punkt, cherez kotoryj prohodit vasha pochta (vklyuchaya mashiny otpravitelya i poluchatelya) vstavlyaet takoe pole v zagolovok, ukazyvaya imya punkta, identichnost' soobshcheniya, vremya i datu polucheniya soobshcheniya, iz kakogo punkta ono proishodit, i kotoroe transportnoe programmnoe obespechenie ispol'zovalos'. |to sdelano chtoby Vy mogli prosledit' put' soobshcheniya soobshcheniya. X-zagolovok: mail-programmy ne dolzhny zhalovat'sya na zagolovki, kotorye nachinayutsya s X-. Oni ispol'zuyutsya, chtoby voplotit' dopolnitel'nye vozmozhnosti, kotorye eshche ne realizovany v RFC. Odno isklyuchenie k etoj strukture - sama pervaya stroka. Ona nachinaetsya s klyuchevogo slova From, kotoroe soprovozhdaetsya probelom vmesto dvoetochiya. Ona soderzhit marshrut, vremya i datu, kogda ono bylo polucheno poslednej mashinoj, obrabatyvavshej ego, i neobyazatel'nuyu chast', opredelyayushchuyu, ot kotoroj glavnoj |VM ono bylo polucheno. Pole From predusmotreno dlya sovmestimosti s neskol'ko bolee starym mailer'ami, i ne ispol'zuetsya osobenno chasto, za isklyucheniem interfejsami pol'zovatelya pochty. - 251 - 14.2 Kak Peredaetsya Pochta? Voobshche, Vy ustanavliaete pochtu, ispol'zuya interfejs podobnyj mailx; ili bolee slozhnyj podobno elm, mush, ili pine. |ti programmy nazyvayutsya sredstvami pol'zovatelya pochty, ili MUA dlya kratkosti. Esli Vy posylaete soobshchenie pochty, programma interfejsa budet v bol'shinstve sluchaev vruchat' ego drugoj programme, kotoraya nazyvaetsya sredstvom transporta pochty, ili MTA. Na nekotoryh sistemah, imeyutsya razlichnye sredstva transporta pochty dlya lokal'noj i otdalennoj pochty, na drugih, imeetsya tol'ko odno. Komanda dlya otdalennoj obychno nazyvaetsya rmail, dlya drugoj - lmail (esli ona sushchestvuet). Lokal'noe poluchenie pochty, konechno, bol'she chem konkatenaciya vhodyashchego soobshcheniya k mailxbox poluchatelya. Obychno, lokal'nyj MTA pojmet sovmeshchenie imen (ustanovka lokal'nyh adresov poluchatelya, ukazyvayushchih na drugie adresa), i peresylku (perenaznachenie pochty pol'zovatelya k nekotoromu drugomu adresatu). Takzhe, soobshcheniya, kotorye ne mogut byt' peredany, dolzhny obychno byt' bounced, to est' vozvrashchenny otpravitelyu naryadu s nekotorym soobshcheniem oshibki. Dlya otdalennogo polucheniya, ispol'zuemoe programmnoe obespechenie zavisit ot haraktera svyazi. Esli pochta dolzhna byt' peredana po seti, ispol'zuya TCP/IP, obychno ispol'zuetsya SMTP. SMTP zameshchaet Prostoj Protokol peredachi Pochty, i opredelen v RFC 788 i 821 RFC. SMTP obychno soedinyaetsya s mashinoj poluchatelya neposredstvenno. V UUCP setyah, pochta neposredstvenno ne budet obychno peredana, no budet poslana na glavnuyu |VM adresata ryadom sistem promezhutochnogo zvena. CHtoby posylat' soobshchenie po UUCP, MTA budet obychno vypolnyat' rmail na sisteme peresylki, ispol'zuya uux, i podavat' eto soobshchenie na standartnom vvode. Tak kak eto vypolnyaetsya dlya kazhdogo soobshcheniya otdel'no, eto mozhet proizvodit' znachitel'nuyu zagruzku glavnogo uzlovogo haba pochty, takzhe kak sotni malyh fajlov, zanimayushchih neproporcional'noe kolichestvo diskovogo prostranstva. (2) Nekotorye MTA sledovatel'no pozvolyayut Vam sobirat' otdel'nye soobshcheniya dlya otdalennoj sistemy v odinochnom komandnom fajle. Komandnyj fajl soderzhit komandy SMTP, kotorye lokal'naya glavnaya |VM obychno vydala by, esli by ispol'zovalos' pryamoe SMTP - 252 - soedinenie. |to nazyvaetsya BSMTP, ili paketirovka SMTP. Paket peredaetsya programme rsmtp ili bsmtp na otdalennoj sisteme, kotoraya budet proivedet vvod, kak budto proizoshlo normal'noe SMTP soedinenie. 14.3 Email Adresa Dlya elektronnoj pochty, adres sostoit iz po krajnej mere imeni mashiny, obrabatyvayushchej pochtu opredelennogo cheloveka, i identifikaciyu pol'zovatelya, raspoznavaemuyu etoj sistemoj. |to mozhet byt' imya vhoda v sistemu poluchatelya, no mozhet takzhe byt' chto - nibud' eshche. Drugaya pochtovaya adresuyushchaya shema, podobno X.400, ispol'zuet bolee obshchij nabor " atributov " kotorye ispol'zuyutsya, chtoby iskat' glavnuyu |VM poluchatelya v X.500. Sposob interpretacii mashinnogo imeni zavisit ot seti, v kotoruyu Vy vklyucheny. Abonenty Internet tverdo priderzhivayutsya RFC 822 standarta, kotoryj trebuet zapisi user@host.domain, gde host.domain - polnost'yu kvalificirovannoe imya glavnoj |VM oblasti. V seredine znak "v". Potomu chto eta zapis' ne vklyuchaet marshrut do glavnoj |VM adresata, no daet (unikal'noe) hostname vzamen, eto nazyvaetsya absolyutnym adresom. V originale UUCP sredy, rasprostranennaya forma byla path!host!user (put'!glavnaya |VM!pol'zovatel'), gde put' opisyval posledovatel'nost' glavnyh |VM dlya dostizheniya glavnoj |VM adresata. |ta konstrukciya nazyvaetsya zapis'yu puti udara, potomu chto metka vosklicaniya nazyvaetsya "Udarom". Segodnya, mnogo uucp- podobnyh setej prinyali RFC822, i ponimayut etot tip adresa. Odnako, imeetsya sposob opredelit' marshruty RFC822- sovmestimymi sposoboami: < @hostA,@hostB: user@hostC > oboznachaet adres pol'zovatelya na hostC, gde HostC dolzhen byt' dostignut cherez hostA i hostB (v etom poryadke). |tot tip adresa - chasto nazyvaetsya adresom marshruta. - 253 - Kogda, imeetsya " % " operator adresa: user%hostB@hostA budet snachala poslan hostA, kotoryj rasshiryaet znak procenta v znak "@". Adres - teper' user@hostB, i Mailer budet schastlivo peredavat' vashe soobshchenie k hostB, kotoryj peredast ego pol'zovatelyu. |tot tip adresa inogda upominaetsya kak "Ye Olde ARPANET Kludge''. Odnako, mnogo sredstv transporta pochty generiruyut etot tip adresa. Drugie seti imeyut razlichnye sposoby adresacii. Decnet- osnovannye seti, naprimer, ispol'zuyut dva dvoetochiya kak razdelitel' adresov, proizvodya adres tak - glavnaya |VM::pol'zovatel'. X.400 standart ispol'zuet polnost'yu otlichnuyu shemu, opisyvaya poluchatelya naborom par svojstv, podobno strane i organizacii. V seti FidoNet, kazhdyj pol'zovatel' identificirovan kodom podobno 2:320/204.9, sostoyashchem iz chetyreh chisel, oboznachayushchih: zonu (2 - dlya Evropy), set' (320 dlya Parizha), uzel (lokal'nyj uzlovoj hab), i ukazatel' (PC individual'nogo pol'zovatelya). Fidonet adresa mozhgut byt' otobrazheny na RFC 822; vysheupomyanutoe napisali by kak Thomas.Quinot@p9.f204.n320.z2.fidonet.org. 14.4 Kak Rabotaet Marshrutizaciya? Process napravleniya soobshcheniya na glavnuyu |VM poluchatelya nazyvaetsya marshrutizaciya. Krome nahozhdeniya puti ot punkta posylki do adresata, eto vklyuchaet proverku oshibok takzhe kak optimizaciyu stoimosti i bystrodejstvie. Imeetsya bol'shoe razlichie mezhdu UUCP sposobom marshrutizacii deskriptorov punkta, i sposobrom, kotorym delaet punkt Internet. V Internet, osnovnaya rabota napravleniya dannyh na glavnuyu |VM poluchatelya (esli tol'ko izvesten adres IP) vypolnen IP urovnem raboty s setyami, v to vremya kak v UUCP zone, marshrut dolzhen byt' obespechen pol'zovatelem, ili sgenerirovat'sya sredstvom peredachi pochty. 14.4.1 Marshrutizaciya Pochty v Internet V Internet ot glavnoj |VM adresata zavisit polnost'yu, - 254 - vypolnyaetsya li lyubaya specificheskaya marshrutizaciya pochty voobshche. Znachenie po umolchaniyu dolzhno peredat' soobshchenie glavnoj |VM adresata neposredstvenno, i ostavlyat' fakticheskuyu marshrutizaciyu dannyh IP transportomu urovnyu. Bol'shinstvo punktov budet obychno napravlyat' vsyu pochtu k dostupnomu serveru pochty, kotoryj sposoben obrabotat' vse eto dvizhenie. CHtoby ob®yavit' eto obsluzhivanie, punkt sozdaet tak nazyvaemuyu zapis' MX dlya ih lokal'noj oblasti v DNS baze dannyh. MX zameshchaet |kspreobrazovatel' Pochty i v osnovnom zayavlyaet, chto glavnaya |VM servera zhelaet dejstvovat' kak mehanizm prodvizheniya dannyh pochty dlya vseh mashin v etoj oblasti. MX zapisi mozhgut takzhe ispol'zovat'sya, chtoby obrabotat' traffik dlya glavnyh |VM, kotorye ne soedineny s Internet samostoyatel'no, podobno UUCP setyam, ili setyam kompanij s glavnymi |VM, nesushchimi konfidencial'nuyu informaciyu. MX zapisi takzhe imeyut prioritet, svyazannyj s nimi. |to - polozhitel'noe celoe chislo, kotoroe pozvolyaet opredelit' ocherednost' posylki pochty. Predpolozhite, chto organizaciya Foobar Inc, hochet vsyu ih pochtu obrabatyvat' ih mashinoj, nazyvaemoj mailhub. Oni budut imet' zapis' MX primerno tak v DNS baze dannyh: foobar.com IN MX 5 mailhub.foobar.com |to ob®yavlyaet mailhub.foobar.com kak obrabotchik pochty dlya foo- bar.com so znacheniem predpochteniya 5. Glavnaya |VM, kotoraya hochet peredavat' soobshchenie joe@greenhouse.foobar.com, proverit DNS dlya foobar.com, i najdet zapis' MX, ukazyvayushchuyu na mailhub. Esli ne imeetsya nikakogo MX s predpochteniem men'she chem 5, soobshchenie budet peredano na mailhub. 14.4.2 Marshrutizaciya Pochty v Mire UUCP Marshrutizaciya Pochty na UUCP setyah namnogo bol'she slozhna chem na Internet, potomu chto transportnoe programmnoe obespechenie ne vypolnyaet nikakoj marshrutizacii neposredstvenno. V bolee rannih vremenah, vsya pochta byla dolzhna byt' adresovana, ispol'zuya puti - 255 - udara. Puti Udara opredelyali spisok glavnyh |VM dlya peredachi soobshcheniya, otdelyaemye metkami vosklicaniya, i s posleduyushchim imenem pol'zovatelya. CHtoby adresovat' pis'mo Janet Pol'zovatelyu na mashine, imenovannoj moria, Vy ispol'zovali by put' eek!swim!Moria!Janet. |to poslalo by pochtu ot vashej glavnoj |VM do eek, ottuda na swim i v zaklyuchenie k moria. Ochevidnyj nedostatok etoj metodiki sostoit v tom, chto trebuetsya, chtoby Vy pomnili mnogo otnositel'no setevoj topologii, i t.d. Namnogo huzhe, to chto izmeneniya v setevoj topologii --- podobno udalyaemym svyazyam ili udalyaemym glavnym |VM --- mogut zastavlyat' soobshcheniya terpet' neudachu prosto potomu chto Vy ne znali bo izmenenii. I v zaklyuchenie, v sluchae, esli Vy posylaete v razlichnye mesta, Vy budete dolzhny modificirovat' vse eti marshruty. Pervyj shag v identifikacii hostname byl osnovanie UUCP Otobrazhayushchego Proekta. On razmeshchen v Rutgers Universitete, i registriruet vse oficial'nye UUCP hostname, naryadu s informaciej otnositel'no ih sosedej UUCP i ih geograficheskego raspolozheniya, sozdavaya uverennost', chto nikakoj hostname ne ispol'zuetsya dvazhdy. Informaciya, sobrannaya Proektom Otobrazheniya izdana kak Karty Usenet, kotorye raspredeleny regulyarno cherez Usenet. (4) tipichnyj vhod sistemy v Karte (pri udalenii kommentariev) pohodit na eto: 4. Maps for sites registered with The UUCP Mapping Project are distributed through the newsgroup comp.mail.maps; other organizations may publish separate maps for their network. moria bert(DAILY/2), swim(WEEKLY) |tot vhod govorit, chto moria imeet svyaz' s bert, kotoruyu ona vyzyvaet dvazhdy v den', i so swim, kotoruyu ona vyzyvaet ezhenedel'no. My vozvratimsya k formatu fajlov Karty pozzhe. Ispol'zuya informaciyu svyaznosti, obespechennoj v kartah, Vy mozhet avtomaticheski generirovat' polnye puti ot vashej glavnoj |VM do lyubogo punkta adresata. |ta informaciya obychno sohranyaetsya v fajle putej, takzhe nazyvaemom pathalias baza dannyh. Esli Karty ustanavlivayut, chto Vy mozhete dostigat' bert cherez ernie, to pathalias - 256 - vhod dlya moria, sgenerirovannyj iz otryvka Karty vyshe vyglyadit sleduyushchim obrazom: moria ernie!bert!moria!%s Esli, kotoryj Vy teper' daete adres adresata janet@moria.uucp, vash MTA, vyberet marshrut, pokazannyj vyshe, i poshlet soobshchenie ernie s adresom konverta bert! Moria! Janet. Formirovanie fajla putej iz polnyh kart Usenet - ne ochen' horoshaya ideya. Informaciya, obespechennaya v nih obychno iskazhaetsya, i inogda ustarevaet. Sledovatel'no, tol'ko ryad glavnyh glavnyh |VM ispol'zuet polnye UUCP vsemirnye karty, chtoby formirovat' ih fajl putej. Bol'shinstvo abonentov podderzhivaet informaciyu marshrutizacii dlya abonenta v ih sosedstve(okrestnostyah), i posylayut pochtu abonentu, kotorogo oni ne nahodyat v ih bazah dannyh na bolee intellektual'nuyu glavnuyu |VM s bolee polnoj informaciej marshrutizacii. |ta shema nazyvaetsya intellektual'no - glavnoj marshrutizaciej. 14.4.3 Smeshivanie UUCP i RFC 822 Samoe luchshee ispravlenie protiv problem marshrutizacii pochty v UUCP setyah - prinyatie sistemy imeni oblasti v UUCP setyah. Konechno, Vy ne mozhete sdelat' zapros bloka preobrazovaniya imen nad UUCP. Odnako, mnogie UUCP abonenty sformirovali malye oblasti, kotorye koordiniruyut ih marshrutizaciyu vnutrenne. V Kartah, eti oblasti ob®yavlyayut odnu ili dve glavnyh |VM kak ih vorota pochty, tak, chtoby ne byl vhoda karty dlya kazhdoj glavnoj |VM v oblasti. Vorota obrabatyvayut vsyu pochtu, kotoraya techet v i vne oblasti. Shema marshrutizacii vnutri oblasti polnost'yu nevidima dlya vneshnego mira. |to rabotaet ochen' horosho s intellektual'no - glavnoj shemoj marshrutizacii, opisannoj vyshe. Global'naya peremennaya, napravlyayushchaya informaciyu podderzhivaetsya vorotami; malyj Glavnye |VM vnutri oblasti poluchat tol'ko malyj fajl putej, kotoryj perechislyaet marshruty vnutri ih oblasti, i marshruta k habu - 257 - pochty. Dazhe vorota pochty ne dolzhny imet' informacii marshrutizacii dlya kazhdoj odinochnoj UUCP glavnoj |VM v mire. Im nuzhno imet' marshruty k vsem oblastyam v ih bazah dannyh. Naprimer, pathalias vhod, pokazannyj nizhe napravlyaet vsyu pochtu dlya abonenta v sub.org oblasti k smurf: .sub.org swim!smurf!%s Lyubaya pochta, adresovannaya claire@jones.sub.org budet poslana swim s adresom konverta smurf! Jones! Claire. Ierarhicheskaya organizaciya oblasti nazyvaet mesto, pozvolyaet serveram pochty smeshivat' bolee specificheskie marshruty s menee specificheskimi. Naprimer, sistema vo Francii mozhet imet' specificheskie marshruty dlya podoblastej fr, no napravlyat' lyubuyu pochtu dlya glavnyh |VM v SSHA oblast' k nekotoroj sisteme v SSHA. Takim obrazom,, oblast'-osnovannaya marshrutizaciya (kak eta metodika nazyvaetsya) znachitel'no umen'shaet razmer baz dannyh marshrutizacii takzhe kak administrativnyh neobhodimyh neproizvoditel'nyh zatrat. Osnovnaya pol'za ispol'zovaniya imen oblasti v UUCP srede to chto soglasie s RFC 822, razreshaet prostoj perehod mezhdu UUCP setyami i Internet. Mnogie UUCP oblasti v nastoyashchee vremya imeyut svyaz' s vorotami Internet, kotorye dejstvuyut kak ih intellektual'no - glavnye. Posylka soobshchenij cherez Internet bystree, i informaciya marshrutizacii namnogo bolee nadezhna, potomu chto glavnye |VM Internet mogut ispol'zovat' DNS vmesto Kart Usenet. CHtoby byt' dostupnym iz Internet, uucp-osnovannye oblasti obychno imeyut vorota v Internet, i ob®yavlyayut zapis' MX dlya nih (MX zapisi byli opisany vyshe). Naprimer, primite, chto moria prinadlezhit orcnet.org oblasti. Gcc2.groucho.edu dejstvuet kak vorota v Internet. Moria sledovatel'no ispol'zoval by gcc2 kak intellektual'no - glavnogo (smart-host), tak, chtoby vsya pochta dlya inostrannyh oblastej byla peredan cherez Internet. S drugoj storony, gcc2 ob®yavil by zapis' MX dlya orcnet.org, i peredaval vsyu vhodyashchuyu pochtu dlya orcnet abonenta k moria. Edinstvenaya ostayushchayasya problema sostoit v tom, chto UUCP transportnye programmy ne mogut imet' delo s kvalificirovannymi imenami oblasti. Bol'shinstvo UUCP programm bylo razrabotano, chtoby spravit'sya s imenami punkta do vos'mi simvolov, i ispol'zovanie ne-alfavitno-cifrovyh simvolov tipa tochek - - 258 - polnost'yu vne pravil. Sledovatel'no, nekotoroe otobrazhenie mezhdu RFC 822 imenami i UUCP hostname'ami neobhodimo. Odin obshchij sposob otobrazheniya FQDN na imena UUCP sostoit v tom, chtoby ispol'zovat' pathalias fajl dlya etogo: moria.orcnet.org ernie!bert!moria!%s |to proizvedet chistyj put' uucp-stilya iz adresa, kotoryj opredelyaet polnost'yu kvalificirovannoe imya oblasti. Nekotorye mailer'y obespechivayut special'nye fajly dlya etogo; sendmail, naprimer, ispol'zuet uucpxtable. Obratnoe preobrazovanie inogda trebuetsya pri posylke pochty iz UUCP seti v Internet. Kak tol'ko otpravitel' pochty ispol'zuet polnost'yu kvalificirovannoe imya oblasti v adrese adresata, etoj problemy mozhno izbezhat' ne udalyaya imya oblasti iz adresa konverta pri peresylke soobshcheniya na smart-host. Odnako, imeetsya vse eshche nekotoryj UUCP abonent, kotoryj - ne est' chast' lyuboj oblasti. Oni - obychno opredelyayutsya, konkateniruya psevdo oblast' uucp. 14.5 Pathalias i Format fajla Karty Pathalias baza dannyh obespechivaet glavnuyu, napravlyayushchuyu informaciyu v uucp-osnovannyh setyah. Tipichnyj vhod pohodit na etot (imya punkta, i put' otdelyaetsya METKAMI TABULYACII): moria.orcnet.org ernie!bert!moria!%s moria ernie!bert!moria!%s |to napravlyaet lyuboe soobshchenie k moria cherez ernie i bert. moria polnost'yu sostavnoe imya i imya UUCP dolzhno byt' zadano, esli mailer ne imeet otdel'nogo sposoba otobrazheniya mezhdu etimi imenami. Esli Vy hotite napravlyat' vse soobshcheniya na glavnye |VM vnutri nekotoroj oblasti na rele pochty, Vy mozhet takzhe opredelyat' put' v pathalias baze dannyh, davaya imya oblasti kak celevoj, s predshestvuyushchej tochkoj. Naprimer, esli vse glavnye |VM v sub.org - 259 - mogut byt' dostignuty cherez swim!smurf, pathalias vhod mog by vyglyadet' sleduyushchim obrazom: \&.sub.org swim!smurf!%s Zapis' v pathalias fajl yavlyaetsya dopustimoj tol'ko, kogda Vy imeete punkt kotoryj ne dolzhen delat' mnogo marshrutizacii. Esli Vy dolzhny delat' marshrutizaciyu dlya bol'shogo kolichestva glavnyh |VM, luchshij sposob - ispol'zovat' pathalias komandu, chtoby sozdat' fajl iz fajlov karty. Karty mogut podderzhivat'sya namnogo proshche, potomu chto Vy mozhete prosto dobavlyat' ili udalyat' sistemu, redaktiruya vhod karty sistemy, i vnov' sozdavat' fajl karty. Hotya karty, izdannye Usenet Proektom ne ochen' ispol'zuyutsya dlya marshrutizacii, UUCP seti mogut obespechivat' informaciyu marshrutizacii v ih sobstvennom nabore kart. Fajl karty v osnovnom sostoit iz spiska abonentov, pechataya abonentov kazhdogo oprosa sistemy. Imya sistemy nachinaetsya v pervom stolbce, i soprovozhdaetsya otdelennym zapyatoj spiskom svyazej. Spisok mozhet byt' prodolzhen cherez simvol perevoda stroki, esli sleduyushchaya stroka nachinaetsya s metki tabulyacii. Kazhdaya svyaz' sostoit iz imeni punkta, soprovozhdaemogo stoimost'yu, dannoj v skobkah. Stoimost' - arifmeticheskoe vyrazhenie, sostoyashcheee iz chisel i simvolicheskih izderzhek. Stroki, nachinayushchiesya znakom musora ignoriruyutsya. Naprimer, rassmotrite moria, kotoryj oprashivaet swim .tobirds.com dva raza v den', i bert.sesame.com tol'ko raz v nedelyu. Krome togo, svyaz' s bert ispol'zuet medlennyj 2400bps modem. Moria izdal by sleduyushchij vhod kart: moria.orcnet.org bert.sesame.com(DAILY/2), swim.twobirds.com(WEEKLY+LOW) moria.orcnet.org = moria Poslednyaya stroka delala by eto izvestnym pod imenem UUCP. Obratite vnimanie, chto eto dolzhno byt' DAILY/2, pri vyzove dva raza v den' fakticheski poloviny stoimost' dlya etoj svyazi. Ispol'zovanie informacii iz takih fajlov karty, pathalias sposobno vychislit' optimal'nye marshruty k lyubomu punktu - 260 - adresata, perechislennomu v fajle putej, i proizvodit' pathalias bazu dannyh iz etogo, kotoraya mozhet ispol'zovat'sya dlya marshrutizacii dlya etogo abonenta. Pathalias obespechivaet paru drugih vozmozhnostej podobno skryvayushchemusya punktu (to est' abonent, dostupnyj tol'ko cherez vorota) i t.d. Sm. stranicu dlya pathalias dlya utochneniya, takzhe kak dlya polnogo spiska izderzhek svyazi. Kommentarii v fajle karty voobshche soderzhat dopolnitel'nuyu informaciyu otnositel'no abonenta, opisannogo v etom. Imeetsya zhestkij format, chtoby opredelit' ih, tak, chtoby eto moglo byt' vosstanovleno(otyskano) iz kart. Naprimer, programma, nazyvaemaya uuwho ispol'zuet bazu dannyh, sozdannuyu iz fajlov karty, chtoby otobrazit' etu informaciyu priyatno formatiruemym sposobom. Kogda Vy registriruete vash punkt v organizacii, kotoraya raspredelyaet fajly karty, Vy voobshche dolzhny zapolnit' takoj vhod karty. Nizhe - tipovoj vhod karty (fakticheski, eto - to dlya moego punkta): #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 1993 # monad brewhq(DAILY/2) # Domains monad = monad.swb.de monad = monad.swb.sub.org Nezapolnennoe prostranstvo posle pervyh dvuh simvolov - METKA TABULYACII. Znachenie bol'shinstva polej dovol'no ochevidno; Vy poluchite detalizirovannoe opisanie v lyuboj oblasti, v kotoroj Vy registriruetes'. L pole naibolee zabavno: ono zadaet vashu geograficheskuyu poziciyu v lati-tude/longitude i ispol'zuetsya, chtoby risovat' karty postscript