Страница:
log файл говорит, что я имею чрезвычайно высокие потери передачи: Это
похоже на проблему быстродействия. Возможно связь между компьютером и
модемом также медленна (установите ее для самой высокой эффективной
скорости)? Или это ваши аппаратные средства, которые являются также
медленно к сервисным прерываниям вовремя? С NSC 16550A chipset на вашем
последовательном порте, 38kbps работает хорошо; однако, без FIFOs
(подобных 16450 чипам), 9600 бит\сек - верхний предел скорости. Также Вы
должны удостовериться, что аппаратное рукопожатие допускается на
последовательной линии.
Другая вероятная причина - аппаратное рукопожатие не допускается на
порте. Taylor UUCP 1.04 не имеет никаких средств для включения RTS/CTS
рукопожатия. Вы должны сделать это явно из rc.serial использование
следующей команды:
$ Stty crtscts < /dev/cua3
Я регистрируюсь в, но происходит сбой рукопожатия: Хорошо, может
иметься ряд проблем. Вывод в регистрационном файле должен сообщить Вам
множество. Рассмотрите то, каким протоколам удаленные предложения места
(Это посылает строку Pprotlist в течение рукопожатия). Возможно они не
имеют любого в общем (Вы выбираете любые протоколы в системном или порт?).
Если удаленная система посылает RLCK, имеется просроченный lockfile
для Вас на удаленной системе. Если вы уже не соединены с удаленной
системой на жругой линии попросите удалить его.
Если она посылает RBADSEQ, другое место имеет проверки счета диалога,
допускаемые для Вас, но числа не соответствовали. Если это посылает RLOGIN,
Вас не разрешали к входу в систему под этим идентификатором.
13.8 Регистрационные Файлы
При компилировании набора программ UUCP на использование регистрации
taylor-стиля, Вы имеете только три глобальных регистрационных файла,которые
- 245 -
находятся в каталоге spool. Основной регистрационный файл называется Log и
содержит всю информацию относительно установленных соединений и
перемещенных файлов. Типичный Log-файл выглядит примерно так
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)
Следуящий"важный регистрационный файл - Stats, который содержит
статистику передачи файлов. Раздел Stats соответствующий вышеупомянутой
- 246 -
передаче походит на это:
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)
Третий файл - Debug. В нем содержится отладочная информация. Если Вы
используете отладку, Вы должны удостовериться, что этот файл имеет режим
защиты 600. В зависимости от режима отладки, который Вы выбрали, он может
содержать имя входа в систему и пароль, который Вы используете для
соединения с удаленной системой.
Некоторые UUCP binaries включенные в дистрибутивы Linux-а
компилировались, чтобы использовать регистрацию HDB-стиля. HDB UUCP
использует целую связку регистрационных файлов, сохраненных в
/var/spool/uucp/.Log. Этот каталог содержит еще три каталога, которые
называются uucico, uuxqt, и uux. Они содержат вывод, сгенерированный
каждой из соответствующих команд, сортируемый в различные файлы для каждой
системы. Таким образом, вывод uucico при вызове системы pablo пойдет в
.Log/uucico/pablo, в то время как uuxqt запишет в .Log/uuxqt/pablo.
Строки, записанные в различный lofiles - такие же как и при регистрации
Taylor.
Когда Вы включаете отладку с HDB-стилем, вывод пойдет в .Admin в
/var/spool/uucp. При соединении из вашей системы, информация об отладке
будет послана в Admin/audit.locan, в то время как вывод uucico при вызове
извне будет идти к .Admin/audit.
- 247 -
14. Электронная почта
Одно из наиболее видных использований сетей начиная с первых
сетей - это электронная почта. Она начиналась как простое
обслуживание, типа копирования файла одной машины для другой, и
конкатенирования его к mailbox файлу получателя. В основном email
этим и занимаеся, хотя возрастастающая сеть с комплексом требований
и увеличением загрузки сообщений сделала необходимой более
сложную схему.
Были изобретены различные стандарты обмена почты. Много
усилий было приложено для создания " мульти-медийной почты '',
которая включает изображения и звук в сообщения почты.
Очень большое количество программ транспортировки почты было
выполнено для системы Un*x. Одна из лучше всего известных - sendmail
Университета Berkeley. Первоначальный автор Eric Allman теперь
активно работает над sendmail снова. Имеются два Linux порта
доступных для sendmail-5.56c, один из которых будет описан в главе 16
.., в настоящее время разрабатываемая версия sendmail - 8.6.5.
Почтовый агент, наиболее используемый с Linux - smail-3.1.28,
который написан и обеспечен авторским правом Curt Landon Noll и
Ronald S. Karr. Он включен в большинство поставок Linux. В
последующем, мы будем обращаться к нему просто как smail, хотя
имеются другие версии, которые полностью отличны, и которые мы не
описываем здесь.
Сравнивая с sendmail, smail довольно молод. При обработке почты
без сложных требований маршрутизации, их возможности - довольно
близки. Для больших требований, однако, sendmail всегда побеждает,
потому что его схема конфигурации намного более гибка.
И smail и sendmail поддерживают набор файлов конфигурации,
которые должны быть настроены. Кроме информации, которая
- 248 -
требуется для запуска подсистемы почты (типа локального hostname),
имеется намного больше параметров, которые могут быть настроены.
Файл конфигурации sendmail сначала очень трудно понять Выглядит,
как будто ваша кошка ходила по вашей клавиатуре с нажатой клавишей
SHIFT. Smail файлы конфигурации более структурны и проще для
понимания чем sendmail, но не дают пользователю так много свободы в
настройке поведения mailer'ов. Однако, для малого UUCP или Internet
работа, требуемая для установки любого из них - приблизительно та же
самая.
В этой главе, мы будем иметь дело тем, чем email является и с
какими проблемами Вы, как администратор будете должны иметь дело.
Главы 15. и 16. дадут инструкции по установке smail и sendmail впервые.
К концу текущей главы мы кратко опишем установку пользователя
почты на многих Unix-подобных системах, включая Linux.
Для получения более подробной информации относительно
электронной почты на Linux, пожалуйста обратитесь в Electronic Mail
HOWTO Vince Skahan, который зарегистрирован comp.os.linux.announce
регулярно.
14.1 Что такое - Сообщения Почты?
Сообщение Почты вообще состоит из тела сообщения, которое
является текстом, написанным отправителем, и специальных данных,
определяющих получателей, транспортную среду, и т.д., подобно тому,
что Вы видите когда Вы рассматриваете почтовый конверт.
Эта административно-управленческая информация относится к
двум категориям; в первом классе - любые данные, который является
специфическими для транспортной среды, подобно адресу отправителя
и получателя. Это следовательно называется конвертом или оболочкой.
Это может быть преобразовано транспортным программным
обеспечением, при передаче сообщения.
Вторая - любые данные, необходимые для обработки сообщения
почты, которые - не часть любого транспортного механизма, типа
подчиненной строки сообщения, списка всех получателей, и даты. В
многих сетях, стало стандартным добавлять эти данные к сообщению
- 249 -
почты, формируя так называемый заголовок почты. Это отделено от
тела почты пустой строкой. (1)
1. Обычно добавляются сигнатура или .sig к сообщению почты, обычно
содержащая информацию относительно автора, наряду с шуткой или
девизом. Она отделяется от сообщения почты строкой, содержащей "--".
Большинство программного обеспечения для транспорта почты в
мире Unix использует формат заголовка, выделенный в RFC 822. Его
первоначальная цель - определить стандарт для использования на
ARPANET.
RFC 822 однако - только самый общий. Более современные
стандарты были задуманы, чтобы справиться с возрастанием
потребностей как, например, шифрование данных, поддержка набора
интернационального символа, и мульти-средств расширения почты
(MIME).
Всего эти стандарты, заголовка состоят из отдельных строк,
отделяемых символами перевода строки.
Типичный заголовок почты может выглядеть следующим образом:
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
Обычно, все необходимые поля заголовка генерируются Вашим
mailer`ом, например elm (электронная почта), pine, mush, или mailx.
Некоторые однако необязательны, и могут быть добавлены
пользователем. Электронная почта, например, позволяет Вам
редактировать часть заголовка сообщения.
From: Это содержит адрес email отправителя, и возможно "реальное
- 250 -
имя''.
To: Это - адрес email получателя.
Subject: Описывает содержание почты в нескольких словах. По крайней
мере должен.
Date: Дата посылки почты.
Reply-To: Определяет адрес для ответа получателя. Это может быть
полезно, если Вы имеете несколько адресов, но хотите получать
большую часть почты только на том, который Вы используете наиболее
часто. Это поле необязательно.
Oranization: организация, которая обладает машиной из который почта
исходит. Это поле необязательно.
Message-ID: строка, сгенерированная транспортировщиком почты. Она
уникальна для этого сообщения.
Received: Каждый пункт, через который проходит ваша почта (включая
машины отправителя и получателя) вставляет такое поле в заголовок,
указывая имя пункта, идентичность сообщения, время и дату получения
сообщения, из какого пункта оно происходит, и которое транспортное
программное обеспечение использовалось. Это сделано чтобы Вы
могли проследить путь сообщения сообщения.
X-заголовок: mail-программы не должны жаловаться на заголовки,
которые начинаются с X-. Они используются, чтобы воплотить
дополнительные возможности, которые еще не реализованы в RFC.
Одно исключение к этой структуре - сама первая строка. Она
начинается с ключевого слова From, которое сопровождается пробелом
вместо двоеточия. Она содержит маршрут, время и дату, когда оно
было получено последней машиной, обрабатывавшей его, и
необязательную часть, определяющую, от которой главной ЭВМ оно
было получено.
Поле From предусмотрено для совместимости с несколько более
старым mailer'ами, и не используется особенно часто, за исключением
интерфейсами пользователя почты.
- 251 -
14.2 Как Передается Почта?
Вообще, Вы устанавлиаете почту, используя интерфейс подобный
mailx; или более сложный подобно elm, mush, или pine. Эти программы
называются средствами пользователя почты, или MUA для краткости.
Если Вы посылаете сообщение почты, программа интерфейса будет в
большинстве случаев вручать его другой программе, которая
называется средством транспорта почты, или MTA. На некоторых
системах, имеются различные средства транспорта почты для
локальной и отдаленной почты, на других, имеется только одно.
Команда для отдаленной обычно называется rmail, для другой - lmail
(если она существует).
Локальное получение почты, конечно, больше чем конкатенация
входящего сообщения к mailxbox получателя. Обычно, локальный MTA
поймет совмещение имен (установка локальных адресов получателя,
указывающих на другие адреса), и пересылку (переназначение почты
пользователя к некоторому другому адресату). Также, сообщения,
которые не могут быть переданы, должны обычно быть bounced, то есть
возвращенны отправителю наряду с некоторым сообщением ошибки.
Для отдаленного получения, используемое программное
обеспечение зависит от характера связи. Если почта должна быть
передана по сети, используя TCP/IP, обычно используется SMTP. SMTP
замещает Простой Протокол передачи Почты, и определен в RFC 788 и
821 RFC. SMTP обычно соединяется с машиной получателя
непосредственно.
В UUCP сетях, почта непосредственно не будет обычно передана,
но будет послана на главную ЭВМ адресата рядом систем
промежуточного звена. Чтобы посылать сообщение по UUCP, MTA
будет обычно выполнять rmail на системе пересылки, используя uux, и
подавать это сообщение на стандартном вводе.
Так как это выполняется для каждого сообщения отдельно, это
может производить значительную загрузку главного узлового хаба
почты, также как сотни малых файлов, занимающих
непропорциональное количество дискового пространства. (2)
Некоторые MTA следовательно позволяют Вам собирать отдельные
сообщения для отдаленной системы в одиночном командном файле.
Командный файл содержит команды SMTP, которые локальная главная
ЭВМ обычно выдала бы, если бы использовалось прямое SMTP
- 252 -
соединение. Это называется BSMTP, или пакетировка SMTP. Пакет
передается программе rsmtp или bsmtp на отдаленной системе, которая
будет проиведет ввод, как будто произошло нормальное SMTP
соединение.
14.3 Email Адреса
Для электронной почты, адрес состоит из по крайней мере имени
машины, обрабатывающей почту определенного человека, и
идентификацию пользователя, распознаваемую этой системой. Это
может быть имя входа в систему получателя, но может также быть что -
нибудь еще. Другая почтовая адресующая схема, подобно X.400,
использует более общий набор " атрибутов " которые используются,
чтобы искать главную ЭВМ получателя в X.500.
Способ интерпретации машинного имени зависит от сети, в
которую Вы включены.
Абоненты Internet твердо придерживаются RFC 822 стандарта,
который требует записи user@host.domain, где host.domain - полностью
квалифицированное имя главной ЭВМ области. В середине знак "в".
Потому что эта запись не включает маршрут до главной ЭВМ адресата,
но дает (уникальное) hostname взамен, это называется абсолютным
адресом.
В оригинале UUCP среды, распространенная форма была
path!host!user (путь!главная ЭВМ!пользователь), где путь описывал
последовательность главных ЭВМ для достижения главной ЭВМ
адресата. Эта конструкция называется записью пути удара, потому что
метка восклицания называется "Ударом". Сегодня, много uucp-
подобных сетей приняли RFC822, и понимают этот тип адреса.
Однако, имеется способ определить маршруты RFC822-
совместимыми способоами: < @hostA,@hostB: user@hostC > обозначает
адрес пользователя на hostC, где HostC должен быть
достигнут через hostA и hostB (в этом порядке).
Этот тип адреса - часто называется адресом маршрута.
- 253 -
Когда, имеется " % " оператор адреса: user%hostB@hostA будет
сначала послан hostA, который расширяет знак процента в знак "@".
Адрес - теперь user@hostB, и Mailer будет счастливо передавать ваше
сообщение к hostB, который передаст его пользователю. Этот тип
адреса иногда упоминается как "Ye Olde ARPANET Kludge''. Однако,
много средств транспорта почты генерируют этот тип адреса.
Другие сети имеют различные способы адресации. Decnet-
основанные сети, например, используют два двоеточия как разделитель
адресов, производя адрес так - главная ЭВМ::пользователь. X.400
стандарт использует полностью отличную схему, описывая получателя
набором пар свойств, подобно стране и организации.
В сети FidoNet, каждый пользователь идентифицирован кодом
подобно 2:320/204.9, состоящем из четырех чисел, обозначающих: зону
(2 - для Европы), сеть (320 для Парижа), узел (локальный узловой хаб),
и указатель (PC индивидуального пользователя). Fidonet адреса можгут
быть отображены на RFC 822; вышеупомянутое написали бы как
Thomas.Quinot@p9.f204.n320.z2.fidonet.org.
14.4 Как Работает Маршрутизация?
Процесс направления сообщения на главную ЭВМ получателя
называется маршрутизация. Кроме нахождения пути от пункта посылки
до адресата, это включает проверку ошибок также как оптимизацию
стоимости и быстродействие.
Имеется большое различие между UUCP способом маршрутизации
дескрипторов пункта, и способром, которым делает пункт Internet. В
Internet, основная работа направления данных на главную ЭВМ
получателя (если только известен адрес IP) выполнен IP уровнем
работы с сетями, в то время как в UUCP зоне, маршрут должен быть
обеспечен пользователем, или сгенерироваться средством передачи
почты.
14.4.1 Маршрутизация Почты в Internet
В Internet от главной ЭВМ адресата зависит полностью,
- 254 -
выполняется ли любая специфическая маршрутизация почты вообще.
Значение по умолчанию должно передать сообщение главной ЭВМ
адресата непосредственно, и оставлять фактическую маршрутизацию
данных IP транспортому уровню.
Большинство пунктов будет обычно направлять всю почту к
доступному серверу почты, который способен обработать все это
движение. Чтобы объявить это обслуживание, пункт создает так
называемую запись MX для их локальной области в DNS базе данных.
MX замещает Экспреобразователь Почты и в основном заявляет, что
главная ЭВМ сервера желает действовать как механизм продвижения
данных почты для всех машин в этой области. MX записи можгут
также использоваться, чтобы обработать траффик для главных ЭВМ,
которые не соединены с Internet самостоятельно, подобно UUCP сетям,
или сетям компаний с главными ЭВМ, несущими конфиденциальную
информацию.
MX записи также имеют приоритет, связанный с ними. Это -
положительное целое число, которое позволяет определить
очередность посылки почты.
Предположите, что организация Foobar Inc, хочет всю их почту
обрабатывать их машиной, называемой mailhub. Они будут иметь запись
MX примерно так в DNS базе данных:
foobar.com IN MX 5 mailhub.foobar.com
Это объявляет mailhub.foobar.com как обработчик почты для foo-
bar.com со значением предпочтения 5. Главная ЭВМ, которая хочет
передавать сообщение joe@greenhouse.foobar.com, проверит DNS для
foobar.com, и найдет запись MX, указывающую на mailhub. Если не
имеется никакого MX с предпочтением меньше чем 5, сообщение будет
передано на mailhub.
14.4.2 Маршрутизация Почты в Мире UUCP
Маршрутизация Почты на UUCP сетях намного больше сложна чем
на Internet, потому что транспортное программное обеспечение не
выполняет никакой маршрутизации непосредственно. В более ранних
временах, вся почта была должна быть адресована, используя пути
- 255 -
удара. Пути Удара определяли список главных ЭВМ для передачи
сообщения, отделяемые метками восклицания, и с последующим
именем пользователя. Чтобы адресовать письмо Janet Пользователю на
машине, именованной moria, Вы использовали бы путь
eek!swim!Moria!Janet. Это послало бы почту от вашей главной ЭВМ до
eek, оттуда на swim и в заключение к moria.
Очевидный недостаток этой методики состоит в том, что требуется,
чтобы Вы помнили много относительно сетевой топологии, и т.д.
Намного хуже, то что изменения в сетевой топологии --- подобно
удаляемым связям или удаляемым главным ЭВМ --- могут заставлять
сообщения терпеть неудачу просто потому что Вы не знали бо
изменении. И в заключение, в случае, если Вы посылаете в различные
места, Вы будете должны модифицировать все эти маршруты.
Первый шаг в идентификации hostname был основание UUCP
Отображающего Проекта. Он размещен в Rutgers Университете, и
регистрирует все официальные UUCP hostname, наряду с информацией
относительно их соседей UUCP и их географическего расположения,
создавая уверенность, что никакой hostname не используется дважды.
Информация, собранная Проектом Отображения издана как Карты
Usenet, которые распределены регулярно через Usenet. (4) типичный
вход системы в Карте (при удалении комментариев) походит на это:
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)
Этот вход говорит, что moria имеет связь с bert, которую она
вызывает дважды в день, и со swim, которую она вызывает
еженедельно. Мы возвратимся к формату файлов Карты позже.
Используя информацию связности, обеспеченной в картах, Вы
может автоматически генерировать полные пути от вашей главной
ЭВМ до любого пункта адресата. Эта информация обычно сохраняется
в файле путей, также называемом pathalias база данных. Если Карты
устанавливают, что Вы можете достигать bert через ernie, то pathalias
- 256 -
вход для moria, сгенерированный из отрывка Карты выше выглядит
следующим образом:
moria ernie!bert!moria!%s
Если, который Вы теперь даете адрес адресата janet@moria.uucp, ваш
MTA, выберет маршрут, показанный выше, и пошлет сообщение ernie с
адресом конверта bert! Moria! Janet.
Формирование файла путей из полных карт Usenet - не очень
хорошая идея. Информация, обеспеченная в них обычно искажается, и
иногда устаревает. Следовательно, только ряд главных главных ЭВМ
использует полные UUCP всемирные карты, чтобы формировать их
файл путей.
Большинство абонентов поддерживает информацию
маршрутизации для абонента в их соседстве(окрестностях), и посылают
почту абоненту, которого они не находят в их базах данных на более
интеллектуальную главную ЭВМ с более полной информацией
маршрутизации. Эта схема называется интеллектуально - главной
маршрутизацией.
14.4.3 Смешивание UUCP и RFC 822
Самое лучшее исправление против проблем маршрутизации почты
в UUCP сетях - принятие системы имени области в UUCP сетях.
Конечно, Вы не можете сделать запрос блока преобразования имен над
UUCP. Однако, многие UUCP абоненты сформировали малые области,
которые координируют их маршрутизацию внутренне. В Картах, эти
области объявляют одну или две главных ЭВМ как их ворота почты,
так, чтобы не был входа карты для каждой главной ЭВМ в области.
Ворота обрабатывают всю почту, которая течет в и вне области. Схема
маршрутизации внутри области полностью невидима для внешнего
мира.
Это работает очень хорошо с интеллектуально - главной схемой
маршрутизации, описанной выше. Глобальная переменная,
направляющая информацию поддерживается воротами; малый
Главные ЭВМ внутри области получат только малый файл путей,
который перечисляет маршруты внутри их области, и маршрута к хабу
- 257 -
почты. Даже ворота почты не должны иметь информации
маршрутизации для каждой одиночной UUCP главной ЭВМ в мире. Им
нужно иметь маршруты к всем областям в их базах данных. Например,
pathalias вход, показанный ниже направляет всю почту для абонента в
sub.org области к smurf:
.sub.org swim!smurf!%s
Любая почта, адресованная claire@jones.sub.org будет послана swim с
адресом конверта smurf! Jones! Claire.
Иерархическая организация области называет место, позволяет
серверам почты смешивать более специфические маршруты с менее
специфическими. Например, система во Франции может иметь
специфические маршруты для подобластей fr, но направлять любую
почту для главных ЭВМ в США область к некоторой системе в США.
Таким образом,, область-основанная маршрутизация (как эта методика
называется) значительно уменьшает размер баз данных маршрутизации
также как административных необходимых непроизводительных
затрат.
Основная польза использования имен области в UUCP среде то что
согласие с RFC 822, разрешает простой переход между UUCP сетями и
Internet. Многие UUCP области в настоящее время имеют связь с
воротами Internet, которые действуют как их интеллектуально -
главные. Посылка сообщений через Internet быстрее, и информация
маршрутизации намного более надежна, потому что главные ЭВМ
Internet могут использовать DNS вместо Карт Usenet.
Чтобы быть доступным из Internet, uucp-основанные области
обычно имеют ворота в Internet, и объявляют запись MX для них (MX
записи были описаны выше). Например, примите, что moria
принадлежит orcnet.org области. Gcc2.groucho.edu действует как ворота
в Internet. Moria следовательно использовал бы gcc2 как
интеллектуально - главного (smart-host), так, чтобы вся почта для
иностранных областей была передан через Internet. С другой стороны,
gcc2 объявил бы запись MX для orcnet.org, и передавал всю входящую
почту для orcnet абонента к moria.
Единственая остающаяся проблема состоит в том, что UUCP
транспортные программы не могут иметь дело с квалифицированными
именами области. Большинство UUCP программ было разработано,
чтобы справиться с именами пункта до восьми символов, и
использование не-алфавитно-цифровых символов типа точек -
- 258 -
полностью вне правил.
Следовательно, некоторое отображение между RFC 822 именами и
UUCP hostname'ами необходимо. Один общий способ отображения
FQDN на имена UUCP состоит в том, чтобы использовать pathalias файл
для этого:
moria.orcnet.org ernie!bert!moria!%s
Это произведет чистый путь uucp-стиля из адреса, который
определяет полностью квалифицированное имя области. Некоторые
mailer'ы обеспечивают специальные файлы для этого; sendmail,
например, использует uucpxtable.
Обратное преобразование иногда требуется при посылке почты из
UUCP сети в Internet. Как только отправитель почты использует
полностью квалифицированное имя области в адресе адресата, этой
проблемы можно избежать не удаляя имя области из адреса конверта
при пересылке сообщения на smart-host. Однако, имеется все еще
некоторый UUCP абонент, который - не есть часть любой области. Они
- обычно определяются, конкатенируя псевдо область uucp.
14.5 Pathalias и Формат файла Карты
Pathalias база данных обеспечивает главную, направляющую
информацию в uucp-основанных сетях. Типичный вход походит на этот
(имя пункта, и путь отделяется МЕТКАМИ ТАБУЛЯЦИИ):
moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s
Это направляет любое сообщение к moria через ernie и bert. moria
похоже на проблему быстродействия. Возможно связь между компьютером и
модемом также медленна (установите ее для самой высокой эффективной
скорости)? Или это ваши аппаратные средства, которые являются также
медленно к сервисным прерываниям вовремя? С NSC 16550A chipset на вашем
последовательном порте, 38kbps работает хорошо; однако, без FIFOs
(подобных 16450 чипам), 9600 бит\сек - верхний предел скорости. Также Вы
должны удостовериться, что аппаратное рукопожатие допускается на
последовательной линии.
Другая вероятная причина - аппаратное рукопожатие не допускается на
порте. Taylor UUCP 1.04 не имеет никаких средств для включения RTS/CTS
рукопожатия. Вы должны сделать это явно из rc.serial использование
следующей команды:
$ Stty crtscts < /dev/cua3
Я регистрируюсь в, но происходит сбой рукопожатия: Хорошо, может
иметься ряд проблем. Вывод в регистрационном файле должен сообщить Вам
множество. Рассмотрите то, каким протоколам удаленные предложения места
(Это посылает строку Pprotlist в течение рукопожатия). Возможно они не
имеют любого в общем (Вы выбираете любые протоколы в системном или порт?).
Если удаленная система посылает RLCK, имеется просроченный lockfile
для Вас на удаленной системе. Если вы уже не соединены с удаленной
системой на жругой линии попросите удалить его.
Если она посылает RBADSEQ, другое место имеет проверки счета диалога,
допускаемые для Вас, но числа не соответствовали. Если это посылает RLOGIN,
Вас не разрешали к входу в систему под этим идентификатором.
13.8 Регистрационные Файлы
При компилировании набора программ UUCP на использование регистрации
taylor-стиля, Вы имеете только три глобальных регистрационных файла,которые
- 245 -
находятся в каталоге spool. Основной регистрационный файл называется Log и
содержит всю информацию относительно установленных соединений и
перемещенных файлов. Типичный Log-файл выглядит примерно так
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)
Следуящий"важный регистрационный файл - Stats, который содержит
статистику передачи файлов. Раздел Stats соответствующий вышеупомянутой
- 246 -
передаче походит на это:
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)
Третий файл - Debug. В нем содержится отладочная информация. Если Вы
используете отладку, Вы должны удостовериться, что этот файл имеет режим
защиты 600. В зависимости от режима отладки, который Вы выбрали, он может
содержать имя входа в систему и пароль, который Вы используете для
соединения с удаленной системой.
Некоторые UUCP binaries включенные в дистрибутивы Linux-а
компилировались, чтобы использовать регистрацию HDB-стиля. HDB UUCP
использует целую связку регистрационных файлов, сохраненных в
/var/spool/uucp/.Log. Этот каталог содержит еще три каталога, которые
называются uucico, uuxqt, и uux. Они содержат вывод, сгенерированный
каждой из соответствующих команд, сортируемый в различные файлы для каждой
системы. Таким образом, вывод uucico при вызове системы pablo пойдет в
.Log/uucico/pablo, в то время как uuxqt запишет в .Log/uuxqt/pablo.
Строки, записанные в различный lofiles - такие же как и при регистрации
Taylor.
Когда Вы включаете отладку с HDB-стилем, вывод пойдет в .Admin в
/var/spool/uucp. При соединении из вашей системы, информация об отладке
будет послана в Admin/audit.locan, в то время как вывод uucico при вызове
извне будет идти к .Admin/audit.
- 247 -
14. Электронная почта
Одно из наиболее видных использований сетей начиная с первых
сетей - это электронная почта. Она начиналась как простое
обслуживание, типа копирования файла одной машины для другой, и
конкатенирования его к mailbox файлу получателя. В основном email
этим и занимаеся, хотя возрастастающая сеть с комплексом требований
и увеличением загрузки сообщений сделала необходимой более
сложную схему.
Были изобретены различные стандарты обмена почты. Много
усилий было приложено для создания " мульти-медийной почты '',
которая включает изображения и звук в сообщения почты.
Очень большое количество программ транспортировки почты было
выполнено для системы Un*x. Одна из лучше всего известных - sendmail
Университета Berkeley. Первоначальный автор Eric Allman теперь
активно работает над sendmail снова. Имеются два Linux порта
доступных для sendmail-5.56c, один из которых будет описан в главе 16
.., в настоящее время разрабатываемая версия sendmail - 8.6.5.
Почтовый агент, наиболее используемый с Linux - smail-3.1.28,
который написан и обеспечен авторским правом Curt Landon Noll и
Ronald S. Karr. Он включен в большинство поставок Linux. В
последующем, мы будем обращаться к нему просто как smail, хотя
имеются другие версии, которые полностью отличны, и которые мы не
описываем здесь.
Сравнивая с sendmail, smail довольно молод. При обработке почты
без сложных требований маршрутизации, их возможности - довольно
близки. Для больших требований, однако, sendmail всегда побеждает,
потому что его схема конфигурации намного более гибка.
И smail и sendmail поддерживают набор файлов конфигурации,
которые должны быть настроены. Кроме информации, которая
- 248 -
требуется для запуска подсистемы почты (типа локального hostname),
имеется намного больше параметров, которые могут быть настроены.
Файл конфигурации sendmail сначала очень трудно понять Выглядит,
как будто ваша кошка ходила по вашей клавиатуре с нажатой клавишей
SHIFT. Smail файлы конфигурации более структурны и проще для
понимания чем sendmail, но не дают пользователю так много свободы в
настройке поведения mailer'ов. Однако, для малого UUCP или Internet
работа, требуемая для установки любого из них - приблизительно та же
самая.
В этой главе, мы будем иметь дело тем, чем email является и с
какими проблемами Вы, как администратор будете должны иметь дело.
Главы 15. и 16. дадут инструкции по установке smail и sendmail впервые.
К концу текущей главы мы кратко опишем установку пользователя
почты на многих Unix-подобных системах, включая Linux.
Для получения более подробной информации относительно
электронной почты на Linux, пожалуйста обратитесь в Electronic Mail
HOWTO Vince Skahan, который зарегистрирован comp.os.linux.announce
регулярно.
14.1 Что такое - Сообщения Почты?
Сообщение Почты вообще состоит из тела сообщения, которое
является текстом, написанным отправителем, и специальных данных,
определяющих получателей, транспортную среду, и т.д., подобно тому,
что Вы видите когда Вы рассматриваете почтовый конверт.
Эта административно-управленческая информация относится к
двум категориям; в первом классе - любые данные, который является
специфическими для транспортной среды, подобно адресу отправителя
и получателя. Это следовательно называется конвертом или оболочкой.
Это может быть преобразовано транспортным программным
обеспечением, при передаче сообщения.
Вторая - любые данные, необходимые для обработки сообщения
почты, которые - не часть любого транспортного механизма, типа
подчиненной строки сообщения, списка всех получателей, и даты. В
многих сетях, стало стандартным добавлять эти данные к сообщению
- 249 -
почты, формируя так называемый заголовок почты. Это отделено от
тела почты пустой строкой. (1)
1. Обычно добавляются сигнатура или .sig к сообщению почты, обычно
содержащая информацию относительно автора, наряду с шуткой или
девизом. Она отделяется от сообщения почты строкой, содержащей "--".
Большинство программного обеспечения для транспорта почты в
мире Unix использует формат заголовка, выделенный в RFC 822. Его
первоначальная цель - определить стандарт для использования на
ARPANET.
RFC 822 однако - только самый общий. Более современные
стандарты были задуманы, чтобы справиться с возрастанием
потребностей как, например, шифрование данных, поддержка набора
интернационального символа, и мульти-средств расширения почты
(MIME).
Всего эти стандарты, заголовка состоят из отдельных строк,
отделяемых символами перевода строки.
Типичный заголовок почты может выглядеть следующим образом:
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
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
Обычно, все необходимые поля заголовка генерируются Вашим
mailer`ом, например elm (электронная почта), pine, mush, или mailx.
Некоторые однако необязательны, и могут быть добавлены
пользователем. Электронная почта, например, позволяет Вам
редактировать часть заголовка сообщения.
From: Это содержит адрес email отправителя, и возможно "реальное
- 250 -
имя''.
To: Это - адрес email получателя.
Subject: Описывает содержание почты в нескольких словах. По крайней
мере должен.
Date: Дата посылки почты.
Reply-To: Определяет адрес для ответа получателя. Это может быть
полезно, если Вы имеете несколько адресов, но хотите получать
большую часть почты только на том, который Вы используете наиболее
часто. Это поле необязательно.
Oranization: организация, которая обладает машиной из который почта
исходит. Это поле необязательно.
Message-ID: строка, сгенерированная транспортировщиком почты. Она
уникальна для этого сообщения.
Received: Каждый пункт, через который проходит ваша почта (включая
машины отправителя и получателя) вставляет такое поле в заголовок,
указывая имя пункта, идентичность сообщения, время и дату получения
сообщения, из какого пункта оно происходит, и которое транспортное
программное обеспечение использовалось. Это сделано чтобы Вы
могли проследить путь сообщения сообщения.
X-заголовок: mail-программы не должны жаловаться на заголовки,
которые начинаются с X-. Они используются, чтобы воплотить
дополнительные возможности, которые еще не реализованы в RFC.
Одно исключение к этой структуре - сама первая строка. Она
начинается с ключевого слова From, которое сопровождается пробелом
вместо двоеточия. Она содержит маршрут, время и дату, когда оно
было получено последней машиной, обрабатывавшей его, и
необязательную часть, определяющую, от которой главной ЭВМ оно
было получено.
Поле From предусмотрено для совместимости с несколько более
старым mailer'ами, и не используется особенно часто, за исключением
интерфейсами пользователя почты.
- 251 -
14.2 Как Передается Почта?
Вообще, Вы устанавлиаете почту, используя интерфейс подобный
mailx; или более сложный подобно elm, mush, или pine. Эти программы
называются средствами пользователя почты, или MUA для краткости.
Если Вы посылаете сообщение почты, программа интерфейса будет в
большинстве случаев вручать его другой программе, которая
называется средством транспорта почты, или MTA. На некоторых
системах, имеются различные средства транспорта почты для
локальной и отдаленной почты, на других, имеется только одно.
Команда для отдаленной обычно называется rmail, для другой - lmail
(если она существует).
Локальное получение почты, конечно, больше чем конкатенация
входящего сообщения к mailxbox получателя. Обычно, локальный MTA
поймет совмещение имен (установка локальных адресов получателя,
указывающих на другие адреса), и пересылку (переназначение почты
пользователя к некоторому другому адресату). Также, сообщения,
которые не могут быть переданы, должны обычно быть bounced, то есть
возвращенны отправителю наряду с некоторым сообщением ошибки.
Для отдаленного получения, используемое программное
обеспечение зависит от характера связи. Если почта должна быть
передана по сети, используя TCP/IP, обычно используется SMTP. SMTP
замещает Простой Протокол передачи Почты, и определен в RFC 788 и
821 RFC. SMTP обычно соединяется с машиной получателя
непосредственно.
В UUCP сетях, почта непосредственно не будет обычно передана,
но будет послана на главную ЭВМ адресата рядом систем
промежуточного звена. Чтобы посылать сообщение по UUCP, MTA
будет обычно выполнять rmail на системе пересылки, используя uux, и
подавать это сообщение на стандартном вводе.
Так как это выполняется для каждого сообщения отдельно, это
может производить значительную загрузку главного узлового хаба
почты, также как сотни малых файлов, занимающих
непропорциональное количество дискового пространства. (2)
Некоторые MTA следовательно позволяют Вам собирать отдельные
сообщения для отдаленной системы в одиночном командном файле.
Командный файл содержит команды SMTP, которые локальная главная
ЭВМ обычно выдала бы, если бы использовалось прямое SMTP
- 252 -
соединение. Это называется BSMTP, или пакетировка SMTP. Пакет
передается программе rsmtp или bsmtp на отдаленной системе, которая
будет проиведет ввод, как будто произошло нормальное SMTP
соединение.
14.3 Email Адреса
Для электронной почты, адрес состоит из по крайней мере имени
машины, обрабатывающей почту определенного человека, и
идентификацию пользователя, распознаваемую этой системой. Это
может быть имя входа в систему получателя, но может также быть что -
нибудь еще. Другая почтовая адресующая схема, подобно X.400,
использует более общий набор " атрибутов " которые используются,
чтобы искать главную ЭВМ получателя в X.500.
Способ интерпретации машинного имени зависит от сети, в
которую Вы включены.
Абоненты Internet твердо придерживаются RFC 822 стандарта,
который требует записи user@host.domain, где host.domain - полностью
квалифицированное имя главной ЭВМ области. В середине знак "в".
Потому что эта запись не включает маршрут до главной ЭВМ адресата,
но дает (уникальное) hostname взамен, это называется абсолютным
адресом.
В оригинале UUCP среды, распространенная форма была
path!host!user (путь!главная ЭВМ!пользователь), где путь описывал
последовательность главных ЭВМ для достижения главной ЭВМ
адресата. Эта конструкция называется записью пути удара, потому что
метка восклицания называется "Ударом". Сегодня, много uucp-
подобных сетей приняли RFC822, и понимают этот тип адреса.
Однако, имеется способ определить маршруты RFC822-
совместимыми способоами: < @hostA,@hostB: user@hostC > обозначает
адрес пользователя на hostC, где HostC должен быть
достигнут через hostA и hostB (в этом порядке).
Этот тип адреса - часто называется адресом маршрута.
- 253 -
Когда, имеется " % " оператор адреса: user%hostB@hostA будет
сначала послан hostA, который расширяет знак процента в знак "@".
Адрес - теперь user@hostB, и Mailer будет счастливо передавать ваше
сообщение к hostB, который передаст его пользователю. Этот тип
адреса иногда упоминается как "Ye Olde ARPANET Kludge''. Однако,
много средств транспорта почты генерируют этот тип адреса.
Другие сети имеют различные способы адресации. Decnet-
основанные сети, например, используют два двоеточия как разделитель
адресов, производя адрес так - главная ЭВМ::пользователь. X.400
стандарт использует полностью отличную схему, описывая получателя
набором пар свойств, подобно стране и организации.
В сети FidoNet, каждый пользователь идентифицирован кодом
подобно 2:320/204.9, состоящем из четырех чисел, обозначающих: зону
(2 - для Европы), сеть (320 для Парижа), узел (локальный узловой хаб),
и указатель (PC индивидуального пользователя). Fidonet адреса можгут
быть отображены на RFC 822; вышеупомянутое написали бы как
Thomas.Quinot@p9.f204.n320.z2.fidonet.org.
14.4 Как Работает Маршрутизация?
Процесс направления сообщения на главную ЭВМ получателя
называется маршрутизация. Кроме нахождения пути от пункта посылки
до адресата, это включает проверку ошибок также как оптимизацию
стоимости и быстродействие.
Имеется большое различие между UUCP способом маршрутизации
дескрипторов пункта, и способром, которым делает пункт Internet. В
Internet, основная работа направления данных на главную ЭВМ
получателя (если только известен адрес IP) выполнен IP уровнем
работы с сетями, в то время как в UUCP зоне, маршрут должен быть
обеспечен пользователем, или сгенерироваться средством передачи
почты.
14.4.1 Маршрутизация Почты в Internet
В Internet от главной ЭВМ адресата зависит полностью,
- 254 -
выполняется ли любая специфическая маршрутизация почты вообще.
Значение по умолчанию должно передать сообщение главной ЭВМ
адресата непосредственно, и оставлять фактическую маршрутизацию
данных IP транспортому уровню.
Большинство пунктов будет обычно направлять всю почту к
доступному серверу почты, который способен обработать все это
движение. Чтобы объявить это обслуживание, пункт создает так
называемую запись MX для их локальной области в DNS базе данных.
MX замещает Экспреобразователь Почты и в основном заявляет, что
главная ЭВМ сервера желает действовать как механизм продвижения
данных почты для всех машин в этой области. MX записи можгут
также использоваться, чтобы обработать траффик для главных ЭВМ,
которые не соединены с Internet самостоятельно, подобно UUCP сетям,
или сетям компаний с главными ЭВМ, несущими конфиденциальную
информацию.
MX записи также имеют приоритет, связанный с ними. Это -
положительное целое число, которое позволяет определить
очередность посылки почты.
Предположите, что организация Foobar Inc, хочет всю их почту
обрабатывать их машиной, называемой mailhub. Они будут иметь запись
MX примерно так в DNS базе данных:
foobar.com IN MX 5 mailhub.foobar.com
Это объявляет mailhub.foobar.com как обработчик почты для foo-
bar.com со значением предпочтения 5. Главная ЭВМ, которая хочет
передавать сообщение joe@greenhouse.foobar.com, проверит DNS для
foobar.com, и найдет запись MX, указывающую на mailhub. Если не
имеется никакого MX с предпочтением меньше чем 5, сообщение будет
передано на mailhub.
14.4.2 Маршрутизация Почты в Мире UUCP
Маршрутизация Почты на UUCP сетях намного больше сложна чем
на Internet, потому что транспортное программное обеспечение не
выполняет никакой маршрутизации непосредственно. В более ранних
временах, вся почта была должна быть адресована, используя пути
- 255 -
удара. Пути Удара определяли список главных ЭВМ для передачи
сообщения, отделяемые метками восклицания, и с последующим
именем пользователя. Чтобы адресовать письмо Janet Пользователю на
машине, именованной moria, Вы использовали бы путь
eek!swim!Moria!Janet. Это послало бы почту от вашей главной ЭВМ до
eek, оттуда на swim и в заключение к moria.
Очевидный недостаток этой методики состоит в том, что требуется,
чтобы Вы помнили много относительно сетевой топологии, и т.д.
Намного хуже, то что изменения в сетевой топологии --- подобно
удаляемым связям или удаляемым главным ЭВМ --- могут заставлять
сообщения терпеть неудачу просто потому что Вы не знали бо
изменении. И в заключение, в случае, если Вы посылаете в различные
места, Вы будете должны модифицировать все эти маршруты.
Первый шаг в идентификации hostname был основание UUCP
Отображающего Проекта. Он размещен в Rutgers Университете, и
регистрирует все официальные UUCP hostname, наряду с информацией
относительно их соседей UUCP и их географическего расположения,
создавая уверенность, что никакой hostname не используется дважды.
Информация, собранная Проектом Отображения издана как Карты
Usenet, которые распределены регулярно через Usenet. (4) типичный
вход системы в Карте (при удалении комментариев) походит на это:
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)
Этот вход говорит, что moria имеет связь с bert, которую она
вызывает дважды в день, и со swim, которую она вызывает
еженедельно. Мы возвратимся к формату файлов Карты позже.
Используя информацию связности, обеспеченной в картах, Вы
может автоматически генерировать полные пути от вашей главной
ЭВМ до любого пункта адресата. Эта информация обычно сохраняется
в файле путей, также называемом pathalias база данных. Если Карты
устанавливают, что Вы можете достигать bert через ernie, то pathalias
- 256 -
вход для moria, сгенерированный из отрывка Карты выше выглядит
следующим образом:
moria ernie!bert!moria!%s
Если, который Вы теперь даете адрес адресата janet@moria.uucp, ваш
MTA, выберет маршрут, показанный выше, и пошлет сообщение ernie с
адресом конверта bert! Moria! Janet.
Формирование файла путей из полных карт Usenet - не очень
хорошая идея. Информация, обеспеченная в них обычно искажается, и
иногда устаревает. Следовательно, только ряд главных главных ЭВМ
использует полные UUCP всемирные карты, чтобы формировать их
файл путей.
Большинство абонентов поддерживает информацию
маршрутизации для абонента в их соседстве(окрестностях), и посылают
почту абоненту, которого они не находят в их базах данных на более
интеллектуальную главную ЭВМ с более полной информацией
маршрутизации. Эта схема называется интеллектуально - главной
маршрутизацией.
14.4.3 Смешивание UUCP и RFC 822
Самое лучшее исправление против проблем маршрутизации почты
в UUCP сетях - принятие системы имени области в UUCP сетях.
Конечно, Вы не можете сделать запрос блока преобразования имен над
UUCP. Однако, многие UUCP абоненты сформировали малые области,
которые координируют их маршрутизацию внутренне. В Картах, эти
области объявляют одну или две главных ЭВМ как их ворота почты,
так, чтобы не был входа карты для каждой главной ЭВМ в области.
Ворота обрабатывают всю почту, которая течет в и вне области. Схема
маршрутизации внутри области полностью невидима для внешнего
мира.
Это работает очень хорошо с интеллектуально - главной схемой
маршрутизации, описанной выше. Глобальная переменная,
направляющая информацию поддерживается воротами; малый
Главные ЭВМ внутри области получат только малый файл путей,
который перечисляет маршруты внутри их области, и маршрута к хабу
- 257 -
почты. Даже ворота почты не должны иметь информации
маршрутизации для каждой одиночной UUCP главной ЭВМ в мире. Им
нужно иметь маршруты к всем областям в их базах данных. Например,
pathalias вход, показанный ниже направляет всю почту для абонента в
sub.org области к smurf:
.sub.org swim!smurf!%s
Любая почта, адресованная claire@jones.sub.org будет послана swim с
адресом конверта smurf! Jones! Claire.
Иерархическая организация области называет место, позволяет
серверам почты смешивать более специфические маршруты с менее
специфическими. Например, система во Франции может иметь
специфические маршруты для подобластей fr, но направлять любую
почту для главных ЭВМ в США область к некоторой системе в США.
Таким образом,, область-основанная маршрутизация (как эта методика
называется) значительно уменьшает размер баз данных маршрутизации
также как административных необходимых непроизводительных
затрат.
Основная польза использования имен области в UUCP среде то что
согласие с RFC 822, разрешает простой переход между UUCP сетями и
Internet. Многие UUCP области в настоящее время имеют связь с
воротами Internet, которые действуют как их интеллектуально -
главные. Посылка сообщений через Internet быстрее, и информация
маршрутизации намного более надежна, потому что главные ЭВМ
Internet могут использовать DNS вместо Карт Usenet.
Чтобы быть доступным из Internet, uucp-основанные области
обычно имеют ворота в Internet, и объявляют запись MX для них (MX
записи были описаны выше). Например, примите, что moria
принадлежит orcnet.org области. Gcc2.groucho.edu действует как ворота
в Internet. Moria следовательно использовал бы gcc2 как
интеллектуально - главного (smart-host), так, чтобы вся почта для
иностранных областей была передан через Internet. С другой стороны,
gcc2 объявил бы запись MX для orcnet.org, и передавал всю входящую
почту для orcnet абонента к moria.
Единственая остающаяся проблема состоит в том, что UUCP
транспортные программы не могут иметь дело с квалифицированными
именами области. Большинство UUCP программ было разработано,
чтобы справиться с именами пункта до восьми символов, и
использование не-алфавитно-цифровых символов типа точек -
- 258 -
полностью вне правил.
Следовательно, некоторое отображение между RFC 822 именами и
UUCP hostname'ами необходимо. Один общий способ отображения
FQDN на имена UUCP состоит в том, чтобы использовать pathalias файл
для этого:
moria.orcnet.org ernie!bert!moria!%s
Это произведет чистый путь uucp-стиля из адреса, который
определяет полностью квалифицированное имя области. Некоторые
mailer'ы обеспечивают специальные файлы для этого; sendmail,
например, использует uucpxtable.
Обратное преобразование иногда требуется при посылке почты из
UUCP сети в Internet. Как только отправитель почты использует
полностью квалифицированное имя области в адресе адресата, этой
проблемы можно избежать не удаляя имя области из адреса конверта
при пересылке сообщения на smart-host. Однако, имеется все еще
некоторый UUCP абонент, который - не есть часть любой области. Они
- обычно определяются, конкатенируя псевдо область uucp.
14.5 Pathalias и Формат файла Карты
Pathalias база данных обеспечивает главную, направляющую
информацию в uucp-основанных сетях. Типичный вход походит на этот
(имя пункта, и путь отделяется МЕТКАМИ ТАБУЛЯЦИИ):
moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s
Это направляет любое сообщение к moria через ernie и bert. moria