Руководство администратора сети в ОС Linux




.Смешивание UUCP и RFC 2


Самое лучшее исправление против проблем маршрутизации почты в 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.




Содержание  Назад  Вперед