Для электронной почты адрес состоит из, по крайней мере, имени машины,
обрабатывающей почту определенного человека, и идентификатора пользователя,
распознаваемого этой системой. Это может быть имя входа в систему получателя,
но это не обязательно. Есть и другие почтовые схемы адресации. Например, в
X.400 используется более общий набор "атрибутов", которые используются,
чтобы найти машину получателя в каталоге сети X.500.
Способ интерпретации машинного имени зависит от сети, к которой Вы
подключены.
Абоненты Internet твердо придерживаются стандарта RFC-822, который требует
записи [email protected], где
host.domain задает полное доменное имя машины
назначения. В середине знак @. Поскольку эта запись не включает маршрут до
машины адресата, но дает взамен уникальное hostname (имя машины), она
называется абсолютным адресом.
Вы увидете, что в Internet использование RFC-822 распространяется не
только на почту, а также проникает в другие услуги, например новости. Мы
обсудим как RFC-822 используется для новостей в
главе 20.
В оригинале среды UUCP распространенная форма была
path!host!user (путь!машина назначения!
пользователь), где path описывал
последовательность машин для достижения машины адресата
(host). Эта конструкция называется записью
bang path, потому что метка восклицания называется
"bang". Сегодня много uucp-подобных сетей приняли стандарт RFC-822 и понимают
этот тип адреса.
Другие сети имеют различные способы адресации. Decnet-сети, например,
используют два двоеточия как разделитель адресов, производя адрес так:
host::user. Стандарт X.400 использует совсем
другую схему, описывая получателя (без связи с машиной!) набором пар свойств,
например, страна и организация.
В сети FidoNet каждый пользователь идентифицирован кодом, подобным
2:320/204.9, состоящим из четырех чисел,
обозначающих: зону (2 для Европы), сеть (320 для Парижа), узел и указатель
(машину индивидуального пользователя). Fidonet-адреса могут быть отображены
на RFC-822; вышеупомянутое написали бы как
[email protected].
При работе с почтой часто возникает необходимость обмена почтой между
системами с разными системами адресации. Конечно, есть ряд шлюзов, которые
обеспечивают хождение почты, но это приводит к проблемам задания адресов.
Я не буду рассматривать шлюзы подробно, но давайте изучим некоторые из
осложнений адресации, которые могут возникать, когда используются шлюзы.
Основная проблема: смшивание UUCP стиля bang-path и формата RFC-822.
Эти два типа адресации соединить не так-то просто. Допустим, есть адрес
domainA!user@domainB. Неизвестно, что важнее:
знак @ или путь. Другими словами: мы должны
послать сообщение на domainB, который
отправляет его на domainA!user, или письмо
надо послать domainA, который отошлет его
user@domainB?
Адреса, в которых операторы адресации смешаны, называются гибридными
(hybrid addresses). В только что приведенном примере
считается, что знак @ важнее пути. Запись
domainA!user@domainB означает послать
сообщение сначала на domainB.
Имеется способ определить маршруты RFC822-совместимыми способами:
<@domainA,@domainB:user@domainC >
обозначает адрес пользователя user в
домене domainC, где
domainC должен быть достигнут через domainA
и domainB (именно в этом порядке!).
Этот тип адресов часто называется адресом, направленным источником
(source routed). Положиться на это поведение не очень
хорошая идея, поскольку изменения в RFC, описывающие маршрутизацию почты,
рекомендуют, чтобы маршрутизация источника в адресе почты игнорировалась, а
взамен должна быть сделана попытка доставить письмо непосредственно
удаленному адресату.
Когда имеется оператор адреса %
(например, user%domainB@domainA), письмо
будет сначала послано domainA, который
превратит знак процента в знак @. Теперь
адрес user@domainB, и почтовая программа
передаст Ваше сообщение на domainB, который
перешлет его пользователю user. Этот тип
адреса иногда упоминается как "Ye Olde ARPAnet Kludge" и его использование не
приветствуется. Однако, много средств транспортировки почты генерируют этот
тип адреса.
Но лучше всего использовать адрес именно в виде абсолютного адреса RFC-822
[email protected], если это позволяет
Ваша система.
