Книга: TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

16.5 Идентификация получателя и обмен сообщениями

16.5 Идентификация получателя и обмен сообщениями

В Интернете получатель почтового сообщения идентифицируется по имени с использованием следующего общего формата:

локальная_часть@имя_домена

Этот формат очень гибок. Многие годы в Интернете предпочитали формат с использованием имен:

идентификатор_пользователя@имя_хоста

Например:

[email protected].

В настоящее время применяется более удобный формат:

имя-фамилия@имя_почтового_домена

Например:

[email protected]

В этом случае Mary-Smith — это не идентификатор пользователя, а jcn.com — не имя хоста. Применяются локальные имена, назначенные в системе почтового обмена. Как же тогда доставлять почту адресату? Механизм почтовой доставки зависит от системы имен доменов. Его работа будет сводиться к следующему:

? Один или несколько компьютеров назначаются в качестве систем почтовой доставки для данной организации.

? Для системы почтовой доставки выбирается логическое имя, обычно имя домена организации, которое и включается в базу данных DNS.

? Программа агента пересылки сообщения (MTA) будет просматривать в адресе сообщения часть, связанную с именем почтового домена, и на ее основе извлекать из DNS реальные имена и адреса системы почтового обмена получателя. Затем туда будет направлено сообщение.

Ниже представлен пример выполняемых действий. Запускается программа nslookup и запрашивается идентификатор системы почтовой доставки (Mail Exchanger) компании Cisco. Как можно заметить, реально выведены сведения о двух системах — hubbub.cisco.com и beasley.cicso.com. Для большей доступности своих почтовых служб многие компании запускают несколько систем почтового обмена.

Отметим выведенные значения предпочтения (preference), равные 5 и 10. Более предпочтительным для отправки почты будет сервер с меньшим номером (hubbub). Именно с ним нужно попытаться соединиться. Если же это будет невозможно, попробуем соединиться с beasley. Реально сами значения предпочтения не имеют никакого смысла, важно только соотношение между ними.

> nslookup
Default Server: DEPT-GW.cs.YALE.EDU
Address: 128.36.0.36
> set type = mx
> cisco.com
Cisco.com preference = 5,  mail exchanger = hubbub.cisco.com
Cisco.com preference = 10, mail exchanger = beasley.cisco.com
Hubbub.cisco.com  inet address = 198.92.30.32
Beasley.cisco.com inet address = 171.69.2.135
Dennis.cisco.com  inet address = 171.69.2.132
Nsl.barrnet.net   inet address = 131.119.245.5
Noc.near.net      inet address = 198.112.8.2
Noc.near.net      inet address = 192.52.71.21

Следующий запрос показывает, как некоторые организации реализуют дополнительный слой безопасности. Отметим наличие сразу трех систем почтового обмена, две из которых фактически принадлежат провайдеру UUNET:

> clarinet.com
Server: DEPT-GW.cs.YALE.EDU
Address: 128.36.0.36
Clarinet.com preference = 10,  mail exchanger = looking.clarinet.com
Clarinet.com preference = 100, mail exchanger = relay1.uu.net
Clarinet.com preference = 100, mail exchanger = relay2.uu.net
Looking.clarinet.com inet address = 192.54.253.1
Relay1.uu.net        inet address = 192.48.96.5
Relay2.uu.net        inet address = 192.48.96.7
>

Компания Clarinet могла бы организовать свою сеть так, чтобы поступающая почта сначала направлялась на одну из систем UUNET, а затем передавалась на looking.clarinet.com.

На рис. 16.6 показано, как это можно сделать. Фильтрующий маршрутизатор нужно установить на блокирование всех соединений, за исключением связи с системой почтовой доставки провайдера UUNET. Внешняя система попробует соединиться с наиболее предпочтительным сайтом looking.clarinet.com. Однако маршрутизатор предотвратит такое соединение. Поэтому в следующей попытке почта будет направлена на один из менее предпочтительных сайтов relay1 или relay2. Теперь система UUNET сможет переслать почту системе почтового обмена компании Clarinet.

Рис. 16.6. Пересылка почтового сообщения по пути следования

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

Возникает еще одна проблема — маршрутизация почты через систему почтового обмена. Предположим, что пользователи хоста sales.clarinet.com имеют почтовые идентификаторы в виде имя_пользователя@sales.clannet.com. Что нужно сделать с адресами, подобными [email protected]? Проблему решит несколько дополнительных элементов в базе данных DNS компании Clarinet:

*.clarinet.com. IN MX 10  looking.clarinet.com.
*.clarinet.com. IN MX 100 relay1.uu.net
*.clarinet.com. IN MX 100 relay2.uu.net

Подстановочный символ звездочки (*) в этих элементах позволит направить на систему почтового обмена компании сообщения, адресованные в старом стиле (идентификатор_пользователя@имя_хоста).

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

Оглавление книги