13.6 UUCP Протоколы низкого уровня
Чтобы осуществлять контроль за приемом и передачей файлов, uucico
кспользует набор стандартизированных сообщений. Этот набор иначе
называется протоколом верхнего уровня. В течение фазы инициализации и фазы
зависания они просто посланы поперек как строки. Однако, в течение реальной
фазы передачи, дополнительный протокол низкого уровня использован, который
является обычно ясным для более высоких(высших) уровней. Это должно делать
проверки ошибки, возможные при использовании ненадежных линий, например.
13.6.1 Краткий обзор протоколов
Поскольку UUCP используется поверх различных типов соединений, типа
последовательных строк, TCP, или даже X. 25, специфические протоколы
низкого уровня необходимы. Кроме того, отдельные реализации UUCP
представили различные протоколы, которые делают приблизительно ту же самую
вещь(дело).
Протоколы могут быть разделены на две категории: потоковые и пакетные
протоколы. Первые передают файл в целиком, возможно вычисляя при этом
контрольную сумму . Нет непроизводственных затрат, но требуется надежное
соединение,так как любая ошибка потребует повторной передачи файла. Эти
протоколы обычно используются над соединениями TCP, но не подходят для
использования над телефонными линиями. Хотя современные модемы хорошо
исправляют ошибки, нельзя обнаружить ошибку между вашим компьютером и
модемом.
С другой стороны, пакетные протоколы разбивают файл на отдельные
куски равного размера. Каждый пакет посылается и получается отдельно,
контрольная сумма вычисляется, и квитирование возвращено датчику. Чтобы
делать это более эффективный, протоколы подвижного окна было изобретено,
которые учитывают ограниченный номер (окно) ожидающого обработки
acknoledgements в любое время. Это значительно уменьшает время ожидания
uucico в течение передачи. Несмотря на это, относительно большие
непроизводительные затраты( по сравнению с потоковым протоколом), делают
пакетный протокол неэффективным для использования поверч TCR.
Ширина пути данных также дает различие. Иногда посылка восьмибитовых
символов над последовательным соединением невозможна, например, если
соединение прсматривает глупый сервер терминала. В этом случае, символы с
восьмым набором битов должны цитироваться на передаче. Когда Вы передаете
восьмибитовые символы над соединением с семью линиями, они должны быть
Согласно предположениям с самым плохим случаем, это удваивает количество
данных, которые будут переданы, хотя сжатие, выполненное аппаратными
средствами может компенсировать этот. Строки, которые могут передавать
произвольные восьмибитовые символы, обычно называются восьмибитовыми
чистыми. Дело обстоит так для всех соединений TCP, также как для
большинства соединений модема.
Следующие протоколы доступны с Taylor UUCP 1.04:
g - наиболее общий протокол и может быть понятым виртуально всеми
uucico's.Он делает полную проверку ошибок и следовательно
хорошо подходит для плохих телефонных линий. g требует
восьмибитового чистого соединения.Это - пакет-ориентированный
протокол, который использует методику подвижного окна.
i - является двунаправленным пакетным протоколом, который может
посылать и получать файлы одновременно. Требуется дуплексное
соединение и восьмибитовый путь данных.Он в настоящее время
распознается только Taylor UUCP.
t - протокол, предназначенный для использования над соединением TCP,
или другими, свободными от ошибок. Использует пакеты в 1024
байтов и требует восьмибитового чистого соединения.
e - аналог t, но только потоковый.
f - предназначен для использования с надежным X. 25 соединением. Это
потоковый протокол, желателен семибитовый путь данных.
Восьмибитовые символы цитируются, что может сделать передачу
неэффективной.
G - реализация g-протокола в System V Relgase"4. Также распознается и
некоторыми другими версиями UUCP.
а - протокол similiar к ZMODEM. Требуется восьми разрядное
соединение, цитируются некоторые управляющие символы подобно XON
и XOFF.
13.6.2 Настройка Протокола Передачи
Все протоколы учитывают некоторое изменение в размерах пакета,
блокировках по времени, и т.п.. Обычно значения по умолчанию,
обеспечивающие работу при стандартных обстоятельствах, не оптимальны для
вашей системы. Протокол g, например, использует размеры окна от 1 до 7, и
размеры пакета в степенях 2 в пределах от 64 до 4096. (14), если ваша
телефонная линия обычно настолько шумная, что теряется более 5% всех
пакетов, Вы должны уменьшить размер пакета и сократить окно. С другой
стороны, на очень хороших телефонных линиях непроизводительные затраты
протокола при посылке запроса черз каждые 128 байт могут оказзаться
расточительными, так что Вы можете увеличивать размер пакета до 512 или
даже 1024.
Taylor UUCP обеспечивает механизм настройки этих параметров командой
protocol-parameter в файле sys. Например, чтобы установить пакет протокола
g в 512 байт при обмене с pablo:
system pablo
protocol-parameter g packet-size 512
14. Большинство binaries включенных в дистрибутивы Linux
устанавливают по умолчанию размер окна 7 ,размер пакета 128 байт .
Настраиваемые параметры и их названия изменяются от протокола к
протокола. Для полного списка см. документацию,поставляемую с Taylor UUCP.
13.6.3 Выбор Специфических Протоколов
Не каждая реализация uucico понимает каждый протокол, так что в
течение начальной фазы рукопожатия, оба процесса должны договориться об
общем протоколе.Главный uucico предлагает подчиненому список обеспечиваемых
протоколов, посылая Pprotlist, из#которого подчиненный может выбирать.
Основываясь на типе используемого порта (модем, TCP, или прямой),
uucico составит заданный по умолчанию список из протоколов. Для модема и
прямых соединений, этот список обычно включает i, a, g, G, j и f. Для
соединений TCP, список - t, e, я, a, перегрузка, G, j, и f. Вы можете
изменить этот заданный по умолчанию список командой protocols, которая
может быть определена во входе системы также как входе порта. Например, Вы
могли бы записать в файл port примерно следующее:
port serial1
protocols igG
Это требует любого входящего или исходящего соединения через этот
порт, чтобы использовать i,g, или G., если удаленная система не
поддерживает никакой из них, диалог потерпит неудачу.
13.7 Поиск неисправностей
Этот раздел описывает возможные неисправности в вашем соединении
UUCP, и дает возможные пути их исправления. Однако мы были просто не в
состоянии охватить все возможные варианты.
В любом случае, включите отладку опцией -xall, и смотрите на вывод в
файле Debug в каталоге spool. Это поможет Вам быстро распознть, где
происходит сбой. Также, я всегда находил полезным включать динамик модема,
когда соединение не удавалось. С Hayes-совместимыми модемами это можно
сделать, добавив " ATL1M1 OK " к дружеской беседе модема в файле dial.
Первым делом стоит проверить все ли права доступа к файлам
установлены правильно. Uucico должен принадлежать uucp, и все файлы в
/usr/lib/uucp, /var/spool/uucp и /var/spool/uucppublic должены принадлежать
uucp. Имеются также некоторые скрытые файлы (15) в каталоге spool, которые
также должны принадлежать uucp.
Uucico может сказать "Wrong time to call "(" Неправильное время
вызова "). Это может значить,что в файле sys , Вы не определили команду
time, которая определяет, когда удаленная системв может вызываться, или
фактически запретили заход в текущее время. Если время обращения не
задано, uucico принимает, что система никогда не может вызываться.
Uucico жалуется, что система уже блокирована. Это означает ,что
uucico обнаружил файл блокировки для удаленной системы в /var/spool/uucp.
Файл блокировки может остаться старого обращения к системе, если ее работа
была прервана некорректно. Однако также правдоподобно, что естьдругой
процесс uucico, который пробует набрать удаленную систему и застревает в
сценарие дружеской беседы, и т.д.. Если этот процесс uucico не преуспел в
соединение с удаленной системой, уничтожте его, и удалите все файлы
блокировки, которые он оставил.
Я могу соединиться с удаленной системой, но происходит сбой сценария
дружеской беседы: Рассмотрите текст, который Вы получаете от удаленного
места. Если он искажен, это может быть связано с быстродействием. Иначе,
подтвердите, соглашается ли это действительно, тем, что ваш сценарий
дружеской беседы ожидает. Помните, что сценарий дружеской беседы
начинается с ожидающейся строкой. Если Вы получаете подсказку входа в
систему, затем посылаете имя, но не получаете подсказку пароля, вставьте
некоторые задержки перед посылкой этому, или четному промежутку символы. Вы
можете быть слишком быстры для вашего модема.
Мой модем не соединяется: Если ваш модем не указывает, что DTR линия
была установлена, когда uucico вызывает,возможно Вы задали неправильное
устройство uucico. Если ваш модем распознает DTR, сверьтесь с a
15. То есть файлы, чьи имя начинает с точки. Такие файлы обычно не
отображаются командой ls.
Программа терминала, которую Вы можете записывать к этому. Если это
работает, включите отображение на экране к \E в начале дружеской беседы
модема. Если это не делает ECHO ваши команды в течение дружеской беседы
модема, проверьте, является ли ваше быстродействие строки слишком высоко
или низпо для вашего модема. Если Вы видите ECHO, проверьте, отключили ли
Вы ответы модема, или устанавливаете их к кодам числа. Проверите, что
сценарий дружеской беседы непосредственно правилен. Не забудьте, что Вы
должны записать две наклонных черты влево, чтобы послать тот модему.
Мой модем пробует соединятся, но не может: Вставьте задержку в номер
телефона. Это особенно полезно когда набор идет из внутренней телефонной
сети компании. Если вы обычно пользуетесь импульсным набором,попробуйте
тоновый. В некоторых странах мощности телефонных сетей нарастили недавно и
тоновый набор иногда помогает.
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-стиля, Вы имеете только три глобальных регистрационных файла,которые
находятся в каталоге 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 соответствующий вышеупомянутой
передаче походит на это:
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.
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 поддерживают набор файлов конфигурации,
которые должны быть настроены. Кроме информации, которая
требуется для запуска подсистемы почты (типа локального 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 Что такое - Сообщения Почты?
Сообщение Почты вообще состоит из тела сообщения, которое
является текстом, написанным отправителем, и специальных данных,
определяющих получателей, транспортную среду, и т.д., подобно тому,
что Вы видите когда Вы рассматриваете почтовый конверт.
Эта административно-управленческая информация относится к
двум категориям; в первом классе - любые данные, который является
специфическими для транспортной среды, подобно адресу отправителя
и получателя. Это следовательно называется конвертом или оболочкой.
Это может быть преобразовано транспортным программным
обеспечением, при передаче сообщения.
Вторая - любые данные, необходимые для обработки сообщения
почты, которые - не часть любого транспортного механизма, типа
подчиненной строки сообщения, списка всех получателей, и даты. В
многих сетях, стало стандартным добавлять эти данные к сообщению
почты, формируя так называемый заголовок почты. Это отделено от
тела почты пустой строкой. (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 отправителя, и возможно "реальное
имя''.
To: Это - адрес email получателя.
Subject: Описывает содержание почты в нескольких словах. По крайней
мере должен.
Date: Дата посылки почты.
Reply-To: Определяет адрес для ответа получателя. Это может быть
полезно, если Вы имеете несколько адресов, но хотите получать
большую часть почты только на том, который Вы используете наиболее
часто. Это поле необязательно.
Oranization: организация, которая обладает машиной из который почта
исходит. Это поле необязательно.
Message-ID: строка, сгенерированная транспортировщиком почты. Она
уникальна для этого сообщения.
Received: Каждый пункт, через который проходит ваша почта (включая
машины отправителя и получателя) вставляет такое поле в заголовок,
указывая имя пункта, идентичность сообщения, время и дату получения
сообщения, из какого пункта оно происходит, и которое транспортное
программное обеспечение использовалось. Это сделано чтобы Вы
могли проследить путь сообщения сообщения.
X-заголовок: mail-программы не должны жаловаться на заголовки,
которые начинаются с X-. Они используются, чтобы воплотить
дополнительные возможности, которые еще не реализованы в RFC.
Одно исключение к этой структуре - сама первая строка. Она
начинается с ключевого слова From, которое сопровождается пробелом
вместо двоеточия. Она содержит маршрут, время и дату, когда оно
было получено последней машиной, обрабатывавшей его, и
необязательную часть, определяющую, от которой главной ЭВМ оно
было получено.
Поле From предусмотрено для совместимости с несколько более
старым mailer'ами, и не используется особенно часто, за исключением
интерфейсами пользователя почты.
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
соединение. Это называется 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 (в этом порядке).
Этот тип адреса - часто называется адресом маршрута.
Когда, имеется " % " оператор адреса: 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 от главной ЭВМ адресата зависит полностью,
выполняется ли любая специфическая маршрутизация почты вообще.
Значение по умолчанию должно передать сообщение главной ЭВМ
адресата непосредственно, и оставлять фактическую маршрутизацию
данных 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, потому что транспортное программное обеспечение не
выполняет никакой маршрутизации непосредственно. В более ранних
временах, вся почта была должна быть адресована, используя пути
удара. Пути Удара определяли список главных ЭВМ для передачи
сообщения, отделяемые метками восклицания, и с последующим
именем пользователя. Чтобы адресовать письмо 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
вход для 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 абоненты сформировали малые области,
которые координируют их маршрутизацию внутренне. В Картах, эти
области объявляют одну или две главных ЭВМ как их ворота почты,
так, чтобы не был входа карты для каждой главной ЭВМ в области.
Ворота обрабатывают всю почту, которая течет в и вне области. Схема
маршрутизации внутри области полностью невидима для внешнего
мира.
Это работает очень хорошо с интеллектуально - главной схемой
маршрутизации, описанной выше. Глобальная переменная,
направляющая информацию поддерживается воротами; малый
Главные ЭВМ внутри области получат только малый файл путей,
который перечисляет маршруты внутри их области, и маршрута к хабу
почты. Даже ворота почты не должны иметь информации
маршрутизации для каждой одиночной 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 программ было разработано,
чтобы справиться с именами пункта до восьми символов, и
использование не-алфавитно-цифровых символов типа точек -
полностью вне правил.
Следовательно, некоторое отображение между 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
полностью составное имя и имя UUCP должно быть задано, если mailer
не имеет отдельного способа отображения между этими именами.
Если Вы хотите направлять все сообщения на главные ЭВМ внутри
некоторой области на реле почты, Вы может также определять путь в
pathalias базе данных, давая имя области как целевой, с
предшествующей точкой. Например, если все главные ЭВМ в sub.org
могут быть достигнуты через swim!smurf, pathalias вход мог бы выглядеть
следующим образом:
\&.sub.org swim!smurf!%s
Запись в pathalias файл является допустимой только, когда Вы
имеете пункт который не должен делать много маршрутизации. Если
Вы должны делать маршрутизацию для большого количества главных
ЭВМ, лучший способ - использовать pathalias команду, чтобы создать
файл из файлов карты. Карты могут поддерживаться намного проще,
потому что Вы можете просто добавлять или удалять систему,
редактируя вход карты системы, и вновь создавать файл карты. Хотя
карты, изданные Usenet Проектом не очень используются для
маршрутизации, UUCP сети могут обеспечивать информацию
маршрутизации в их собственном наборе карт.
Файл карты в основном состоит из списка абонентов, печатая
абонентов каждого опроса системы. Имя системы начинается в первом
столбце, и сопровождается отделенным запятой списком связей.
Список может быть продолжен через символ перевода строки, если
следующая строка начинается с метки табуляции. Каждая связь состоит
из имени пункта, сопровождаемого стоимостью, данной в скобках.
Стоимость - арифметическое выражение, состоящеее из чисел и
символических издержек. Строки, начинающиеся знаком мусора
игнорируются.
Например, рассмотрите moria, который опрашивает swim .tobirds.com
два раза в день, и bert.sesame.com только раз в неделю. Кроме того,
связь с bert использует медленный 2400bps модем. Moria издал бы
следующий вход карт:
moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria
Последняя строка делала бы это известным под именем UUCP.
Обратите внимание, что это должно быть DAILY/2, при вызове два
раза в день фактически половины стоимость для этой связи.
Использование информации из таких файлов карты, pathalias
способно вычислить оптимальные маршруты к любому пункту
адресата, перечисленному в файле путей, и производить pathalias базу
данных из этого, которая может использоваться для маршрутизации для
этого абонента.
Pathalias обеспечивает пару других возможностей подобно
скрывающемуся пункту (то есть абонент, доступный только через
ворота) и т.д. См. страницу для pathalias для уточнения, также как для
полного списка издержек связи.
Комментарии в файле карты вообще содержат дополнительную
информацию относительно абонента, описанного в этом. Имеется
жесткий формат, чтобы определить их, так, чтобы это могло быть
восстановлено(отыскано) из карт. Например, программа, называемая
uuwho использует базу данных, созданную из файлов карты, чтобы
отобразить эту информацию приятно форматируемым способом.
Когда Вы регистрируете ваш пункт в организации, которая
распределяет файлы карты, Вы вообще должны заполнить такой вход
карты.
Ниже - типовой вход карты (фактически, это - то для моего пункта):
#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
Незаполненное пространство после первых двух символов -
МЕТКА ТАБУЛЯЦИИ. Значение большинства полей довольно
очевидно; Вы получите детализированное описание в любой области,
в которой Вы регистрируетесь. L поле наиболее забавно: оно задает
вашу географическую позицию в lati-tude/longitude и используется, чтобы
рисовать карты postscript, которые показывают всех абонентов для
каждой страны.
14.6 Конфигурирование elm
Elm замещает " электронную почту " и является одним из наиболее
приемлемых инструментальных средств Unix. Она обеспечивает
полноэкранный интерфейс с возможностью справки. Мы не будем
обсуждать, здесь как использовать elm, и остановимся только на опциях
конфигурации.
Теоретически, Вы можете выполнять неконфигурированный elm, и
все работает хорошо ---, если Вы очень удачливы. Но имеются
несколько опций, которые должны быть установлены.
При запуске elm читает набор переменных конфигурации из elm.rc
файла в /usr/lib/elm. Затем, она будет пытаться читать файл .elm/elmrc в
вашем исходном каталоге. Вы обычно не пишите этот файл
самостоятельно. Он создается когда Вы выбираете "сохранить опции" в
меню опций elm.
Набор опций для частного elmrc файла также доступен в глобальном
elm .rc файла. Большинство установок в вашем частном elmrc файле
отменяет таковые глобального файла.
14.6.1 Глобальные Опции elm
В глобальном elm .rc файле, Вы должны установить опции, которые
относятся к имени вашего host. Например, в Виртуальном
Пивоваренном заводе, файл содержал бы следующее:
#
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Fully qualified domain name hostfullname = vlager.vbrew.com
Этот набор опций ориентирует elm относительно локального
hostname. Хотя эта информация редко используется, Вы должны
установить эти опции.
Обратите внимание, что эти опции воздействуют только в глобальном
файле конфигурации; когда они найдены в вашем частном elmrc, они
будут игнорироваться.
14.6.2 Национальный Набор Символов
Недавно имелись предложения исправить RFC 822 стандарт, чтобы
поддерживать различные типы сообщений, типа простых текстовых,
двоичных данных, файлов Postscript, и т.д. Набор стандартов и RFC,
покрывающий эти аспекты, обычно упоминается как MIME, или
Многоцелевые Расширения Почты Internet. Между прочим, это также
позволяет получателю узнать, использовался ли набор символов
отличный от стандартного ASCII, при написании сообщения. Это
обеспечивается elm до некоторой степени.
Набор символов, используемый Linux внутренне, чтобы представить
символы обычно упоминается как ISO-8859-1, что является именем
стандарта, которому он соответствует. Это также известно как
Латинский -1. Любые символы в сообщении из этого набора символов
должны иметь следующую строку в заголовке:
Content-Type: text/plain; charset=iso-8859-1
Система получения должна распознать это поле и принять
соответствующие меры при отображении сообщения. Значение по
умолчанию для текстовых сообщений - значение charset us-ascii.
Чтобы отображать сообщения с набором символов отличным от
ASCII, elm должен знать, как печатать эти символы. По умолчанию,
когда elm получает сообщение с charset полем отличным от us-ascii, она
пробует отображать сообщение, используя команду, называемую
metamail. Сообщения, которые требуют, чтобы мета почта отобразилась,
показываются с " M " в самом первом столбце в экране краткого обзора.
Так как Linux набор символов - ISO-8859-1, вызов metamail не
необходим для отображения сообщения, использующего этот набор
символов. Если еlm знает, что дисплей понимает ISO-8859-1, она не
будет использовать metamail, а отобразит сообщение непосредственно.
Это может быть выполнено, установкой следующей опции в
глобальном elm .rc:
displaycharset = iso-8859-1
Обратите внимание, что Вы должны установить эти опции даже,
когда Вы никогда не собираетесь посылать или получать сообщения,
которые фактически содержат символы отличные от ASCII. Это -
потому что люди, которые посылают такие сообщения обычно
конфигурируют их mailerом, чтобы поместить соответствующий тип
содержания: поле в заголовке почты по умолчанию, посылают или нет
они только ascii сообщения.
Однако, установки этой опции в elm .rc не достаточно. Проблема
состоит в том, что при отображении сообщения, elm вызывает
библиотечную функцию для каждого символа, чтобы определить
является ли он печатаемым или нет. По умолчанию, эта функция
распознает только символы ASCII, и отображает все другие символы
как "^?". Вы можете преодолеть это, устанавливая переменную среды
LC CTYPE как ISO-8859-1, которая сообщает, что библиотека приняла
символы Latin-1 как печатаемые. Поддержка для этих и других
возможностей доступна начиная с libc-4.5.8.
При посылке сообщений, которые содержат специальные символы
из ISO-8859-1, Вы должны удостовериться, что установлены еще две
переменные в elm .rc файле:
charset = iso-8859-1
textencoding = 8bit
Это заставит elm сообщить набор символов как ISO-8859-1 в
заголовке почты, и посылать это как 8 битовые значения (значение по
умолчанию - все символы 7 бит).
Конечно, любая из этих опций может также быть установлена в
частном elmrc файле вместо глобального.
15. Получение smail и Выполнение
Эта глава даст Вам быстрое введение в установку smail, и краткий
обзор функциональных возможностей, которые он обеспечивает. Хотя
smail в значительной степени совместим с sendmail в поведении, их
файлы конфигурации полностью отличны.
Основной файл конфигурации - /usr/lib/smail/config. Вы всегда
должны редактировать этот файл, чтобы отразить значения,
специфические для вашего пункта. Другие файлы, которые
конфигурируют маршрутизацию и транспортные опции, могут также
использоваться.
По умолчанию, smail передает всю входящую почту немедленно.
Если Вы имеете относительно высокий траффик, Вы может взамен
заставить smail, собирать все сообщения в так называемой очереди, и
обрабатывать их равномерно.
При обработке почты внутри TCP/IP сети, smail - часто
выполняются в daemon режиме: в загрузочное время системы, он
вызывается из rc.inet2, и помещает себя в фон, где ждет входящие TCP
соединения на SMTP порте (обычно порт 25). Это очень полезно
всякий раз, когда Вы ожидаете значительный траффик, потому что smail
не запущен отдельно для каждого входящего соединения.
Smail имеет множество флагов, которые управляют этим
поведением. Удачно что, smail поддерживает ряд стандартных режимов
- операции, которые допускаются, когда Вы вызываете его
специальным именем команды, подобно rmail, или smtpd. Мы
столкнемся с большинством их при обсуждении различных
возможностей smail.
Имеются две связи с smail, который Вы должны иметь при всех
обстоятельствах; а именно /usr/bin/rmail и /usr/sbin/sendmail. Когда Вы
составляете и посылаете сообщение почты средством пользователя
подобно elm, сообщение будет переправлено в rmail для получения. Тот
же самое случается с почтой, приходящей в через UUCP. Некоторые
версии elm, однако, вызывают /usr/sbin/sendmail вместо rmail, так что Вы
нуждаетесь в обоих. Например, если Вы храните smail в /usr/local/bin,
напечатайте в оболочке:
# ln -s /usr/local/bin/smail /usr/bin/rmail
# ln -s /usr/local/bin/smail /usr/sbin/sendmail
Если, который Вы хотите углубиться далее в подробности
конфигурирования smail, пожалуйста, обращаетесь к руководству smail.
Если он не включен в вашу любимую поставку Linux, Вы может
получить его вплоть до исходников.
15.1 UUCP Установки
Чтобы использовать smail в uucp среде, базисная установка довольно
проста. Сначала, Вы должны удостовериться, что Вы имеете две
символических связи к rmail и sendmail, упомянутому выше. Если Вы
ожидаете получать SMTP пакеты от другого абонента, Вы также
должны сделать rsmtp связь к smail.
В smail распределении Vince Skahan, Вы найдете типовой файл
конфигурации. Он называется config.sample и постоянно находится в
/usr/lib/smail. Вы должны копировать его в конфигурации и
редактировать его, чтобы отразить значения, специфические для вашего
пункта.
Примите, что ваш пункт именован swim .tobirds.com, и
зарегистрирован в картах UUCP как swim. Ваш smarthost - ulysses. Тогда
ваш файл конфигурации должен выглядеть следующим образом:
#
# Our domain names
visible domain=two.birds:uucp
#
# Our name on outgoing mails
visible name=swim.twobirds.com #
# Use this as uucp-name as well uucp name=swim.twobirds.com
#
# Our smarthost
smart host=ulysses
Первое утверждение сообщает smail относительно областей,
которым ваш пункт принадлежит. Вставьте их имена здесь, отделяемые
двоеточиями. Если ваше имя пункта зарегистрировано в картах UUCP,
Вы должен также добавить uucp.
При отправке(получении) сообщения почты, smail определяет имя
вашего host, используя hostname системный вызов (2), и проверяет адрес
получателя для этого hostname. Если адрес соответствует одному из
имен, или неквалифицированному hostname, получатель,
рассматривается локальным, и smail пытается передавать сообщение
пользователю.
Видимое имя должно содержать одиночное, полностью
квалифицированное имя области вашего пункта, которое Вы хотите
использовать при выходе почты. Это имя используется при
производстве адреса отправителя для всей почты. Вы должны
удостовериться, чтобы использовать имя, которое smail распознает
относительно локального host (то есть hostname с одной из областей,
перечисленных в атрибуте области).
Последнее утверждение устанавливает путь, используемый для
маршрутизации smart-host (описанный в разделе 14.4). С этой типовой
установкой, smail будет передавать любую почту для отдаленных
адресов интеллектуальному host. Путь, заданный в интеллектуальном
атрибуте пути будет использоваться как маршрут до интеллектуального
host. Так как сообщения будут передан через UUCP, атрибут должен
определить систему, известную вашему UUCP программному
обеспечению. Пожалуйста обратитесь к главе 13. При создании пункта,
известного UUCP.
Имеется одна опция, используемая в вышеупомянутом файле,
который мы не объяснили; это - имя uucp. Причина использовать
опцию: По умолчанию, smail использует значение, возвращенное
hostname (2) для uucp-специфических вещей типа возвращающегося
пути, данного в строке From заголовка. Если ваш hostname не
зарегистрирован в UUCP проекте, Вы должен сообщить, чтобы smail
использовал взамен ваше полностью квалифицированное имя области.
Это может быть выполнено, добавлением опции имени uucp к файлу
конфигурации.
Имеется другой файл в /usr/lib/smail, называемый paths.sample. Это -
пример файла путей. Однако, Вы не будете нуждаться в нем, если Вы
не имеете связей почты больше чем к одному пункту. Если нет, Вы
будете должны написать один непосредственно, или генерировать
один из карт Usenet. Файл путей будет описан позже в этой главе.
Назад | Содержание | Вперед
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
