su13@pochta.ru

| Первый | Второй | Третий | Четвёртый | Пятый | Шестой | Седьмой |


//

Как работает маршрутизация почты?

Процесс направления сообщения на машину получателя называется маршрутизацией routing. Кроме нахождения пути от пункта посылки до адресата, этот процесс включает проверку ошибок, а также оптимизацию стоимости и быстродействия.

Имеется большое различие между способом маршрутизации дескрипторов пункта UUCP и способом маршрутизации в Internet. В Internet, основная работа направления данных на машину получателя (если только известен адрес IP) выполнен IP уровнем работы с сетями, в то время как в зоне UUCP, маршрут должен быть задан пользователем или сгенерирован средством передачи почты.

Маршрутизация почты в Internet

В Internet от машины адресата зависит полностью, выполняется ли любая специфическая маршрутизация почты вообще. По умолчанию сообщение должно быть передано машине адресата непосредственно, что оставляет фактическую маршрутизацию данных транспортому уровню IP.

Большинство машин будет обычно направлять всю почту доступному серверу почты, который способен обработать все это движение. Чтобы объявить это обслуживание, сервер создает так называемую запись MX для их локальной области в базе данных DNS. MX замещает обменник почты ( Mail Exchanger) и заявляет, что серверная машина желает действовать как механизм продвижения данных почты для всех машин в этой области. MX-записи могут также использоваться, чтобы обработать трафик для машин, которые не соединены с Internet напрямую, подобно UUCP сетям или сетям компаний с машинами, хранящими конфиденциальную информацию.

MX-записи также имеют приоритет (preference), связанный с ними. Это положительное целое число, которое позволяет определить очередность посылки почты. Если для одной машины доступны несколько почтовых серверов, обмен будет производиться через тот, приоритет которого меньше. Сервер с большим приоритетом будет задействован только в случае неудачи. Если машина сама является почтовым сервером, она не будет посылать письма серверам с приоритетом выше, чем у нее. Такой подход позволяет избежать зацикливания передачи почты.

Предположим, что организация Foobar Inc хочет всю свою почту обрабатывать своей машиной mailhub. Они будут иметь примерно такую MX-запись в базе данных DNS:
green.foobar.com.        IN   MX      5    mailhub.foobar.com.

Это объявляет mailhub.foobar.com как обработчик почты для домена green.foobar.com со значением приоритета 5. Машина, которая хочет передать сообщение joe@green.foobar.com, проверит DNS и найдет MX-запись, указывающую на mailhub. Если нет никакого MX с приоритетом меньше, чем 5, сообщение будет передано на mailhub.

Дальнейшую информацию по маршрутизации почты (например, для случаев, когда не работают MX-записи) рекомендую посмотреть в RFC-974.

Маршрутизация почты в UUCP

Маршрутизация почты в UUCP-сетях намного более сложна, чем в Internet, потому что транспортное программное обеспечение не выполняет никакой маршрутизации. В более ранние времена вся почта должна была быть адресована, используя пути bang. Они определяли список машин для передачи сообщения, отделяемые метками восклицания, и с последующим именем пользователя. Чтобы адресовать письмо пользователю Janet на машине moria, Вы использовали бы путь eek!swim!moria!janet. Это послало бы почту с Вашей системы на eek, оттуда на swim и в заключение на moria.

Очевидный недостаток этой методики состоит в том, что требуется, чтобы Вы помнили многое о сетевой топологии. Намного хуже то, что изменения в сетевой топологии, подобные удаляемым связям или удаляемым машинам, могут привести к прекращению хождения почты просто потому, что Вы не знали об изменении. И в заключение, в случае, если Вы посылаете письма в различные места, Вы должны модифицировать все эти маршруты.

Первым шагом в идентификации имен машин было основание The UUCP Mapping Project. Он размещен в Rutgers University и регистрирует все официальные UUCP-имена, наряду с информацией относительно их соседей UUCP и их географическего расположения, создавая уверенность, что никакой hostname не используется дважды. Информация, собранная Mapping Project, издана как Usenet Maps, которые распространяются регулярно через Usenet. Типичная запись в карте (при удалении комментариев) походит на это:
moria
        bert(DAILY/2),
        swim(WEEKLY)

Эта запись говорит, что moria имеет связь с bert, которую она вызывает дважды в день, и со swim, которую она вызывает еженедельно. Мы вернемся к формату файлов карты позже.

Используя информацию связности, обеспеченной картами, Вы можете автоматически генерировать полные пути от Вашей машины до любого пункта адресата. Эта информация обычно сохраняется в файле paths, также называемом базой данных pathalias. Если карты устанавливают, что Вы можете достигать bert через ernie, то запись pathalias для moria, сгенерированная из отрывка карты выше, выглядит следующим образом:
moria           ernie!bert!moria!%s

Если Вы теперь дадите адрес janet@moria.uucp Вашему MTA, он выберет маршрут, показанный выше, и пошлет сообщение на ernie с адресом bert!moria!janet.

Формирование файла paths из полных карт Usenet не очень хорошая идея. Информация в них обычно искажается и иногда устаревает. Следовательно, только ряд систем использует полные всемирные карты-UUCP, чтобы формировать свой файл paths. Многие сайты хранят только данные о своем окружении и посылают данные системам с более полными картами сети для дальнейшей передачи. Такая схема называется smart-host routing.

UUCP и RFC-822

Самое лучшее решение проблем маршрутизации почты в UUCP-сетях: принятие системы имен доменов в UUCP-сетях. Конечно, Вы не можете сделать запрос серверу преобразования имен по UUCP. Однако, многие UUCP-абоненты сформировали малые домены, которые внутренне координируют маршрутизацию. В картах эти области объявляют одну или две машины как их шлюз почты так, чтобы не было записи карты для каждой машины в области. Шлюз обрабатывает всю почту области. Схема маршрутизации внутри области (домена) полностью невидима для внешнего мира.

Это очень хорошо работает со схемой smart-host routing маршрутизации, описанной выше. Глобальная информация маршрутизации поддерживается шлюзом, а машины внутри области получают только маленький файл paths, который перечисляет маршруты внутри их области и маршрут к хабу почты. Даже шлюз почты не должен иметь информации маршрутизации для каждой 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, которые действуют как их smart-host routing. Посылка сообщений через 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-стиля из адреса, который определяет имя домена. Некоторые почтовые программы имеют для этого специальные файлы: sendmail, например, использует uucpxtable.

Обратное преобразование (domainizing)) иногда требуется при посылке почты из UUCP-сети в Internet. Как только отправитель почты использует имя домена в адресе назначения, этой проблемы можно избежать. не удаляя имя области из адреса конверта при пересылке сообщения на smart-host. Однако, все еще есть абоненты UUCP, которые не являются частью домена. Они обычно определяются добавлением псевдодомена uucp.

База данных pathalias обеспечивает направляющую информацию в uucp-сетях. Типичная запись походит на эту (имя сервера и путь отделяются метками табуляции):
moria.orcnet.org  ernie!bert!moria!%s
moria             ernie!bert!moria!%s

Это направляет любое сообщение к moria через ernie и bert . Полное доменное имя moria и его имя в UUCP должны быть заданы, если почтовая программа не имеет отдельного способа связи имен.

Если Вы хотите направлять все сообщения на машины внутри некоторой области на сервер почты, Вы можете также определять путь в базе данных pathalias, давая имя области как целевой с предшествующей точкой. Например, если все машины в sub.org могут быть достигнуты через swim!smurf, запись pathalias могла бы выглядеть следующим образом:
.sub.org        swim!smurf!%s

Запись в файл pathalias является допустимой только, когда Вы имеете сервер, который не должен делать много маршрутизации. Если Вы должны делать маршрутизацию для большого количества машин, лучший способ использовать команду pathalias, чтобы создать файл из файлов карты. Карты могут поддерживаться намного проще, потому что Вы можете просто добавлять или удалять систему, редактируя запись карты системы, и вновь создавать файл карты. Хотя карты, изданные Usenet Mapping Project, не очень хороши для маршрутизации, UUCP-сети могут обеспечивать информацию маршрутизации в их собственном наборе карт.

Файл карты в основном состоит из списка абонентов, печатая абонентов каждого опроса системы. Имя системы начинается в первом столбце и сопровождается отделенным запятой списком связей. Список может быть продолжен через символ перевода строки, если следующая строка начинается с метки табуляции. Каждая связь состоит из имени машины, сопровождаемого стоимостью, данной в скобках. Доступность определяется выражением, состоящим из чисел с ключевыми словами, например, DAILY или WEEKLY. Строки, начинающиеся знаком #, игнорируются.

Например, рассмотрим moria, который опрашивает swim.twobirds.com два раза в день, и bert.sesame.com только раз в неделю. Кроме того, связь с bert использует медленный модем на 2400bps. Машина moria издаст следующую запись карты:
moria.orcnet.org
        bert.sesame.com(DAILY/2),
        swim.twobirds.com(WEEKLY+LOW)
moria.orcnet.org = moria

Последняя строка делает moria известной под именем UUCP. Обратите внимание, что для этой связи должно быть DAILY/2, при вызове два раза в день.

Используя информации из таких файлов карты, pathalias способна вычислить оптимальные маршруты к любому адресату, перечисленному в файле путей, и создать базу данных pathalias, которая может использоваться для маршрутизации до этого абонента.

Команда pathalias обеспечивает пару других возможностей, подобно скрывающемуся пункту (то есть абонент, доступный только через шлюз) и т.д. См. man-страницу 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 наиболее забавно: оно задает Вашу географическую позицию в latitude/longitude и используется, чтобы рисовать карты postscript, которые показывают всех абонентов для каждой страны.

GNU OCXE GNU LINUX
Сайт управляется системой uCoz