Эндрю Уэзеролл - Компьютерные сети. 5-е издание

У сообщений, отсылаемых в почтовую систему — стандартный формат, который должен быть образован при помощи информации, предоставленной пользовательским агентом. Самая важная часть в передаче сообщения — это конверт, а самая важная часть конверта — адрес назначения. Этот адрес должен быть в формате, с которым могут работать агенты передачи сообщений.

Ожидаемый формат адреса — это user@dns-address. Так как система доменных имен DNS уже рассматривалась выше в этой главе, сейчас мы не станем подробно останавливаться на данном вопросе. Однако следует отметить, что существуют и другие формы адресации. В частности, адреса стандарта X.400 абсолютно не похожи на DNS-адреса.

X.400 — это стандарт ISO для систем обработки сообщений, который одно время соревновался с SMTP. SMTP победил в этом противостоянии, хотя системы X.400 все еще используются (в основном, за пределами США). Адреса стандарта X.400 абсолютно не похожи на DNS-адреса и состоят из пар атрибут = значение, разделенных слэшами, например:

В этом адресе указано государство, штат, местоположение, личный адрес и имя получателя (Ken Smith). Возможно также использование различных других атрибутов, что делает возможным отправку электронного письма человеку, чьего имени вы не знаете, при условии что вам известны другие атрибуты (например, название компании и должность получателя). Хотя форма адресации X.400 значительно менее удобна, чем DNS, для пользовательских агентов этот вопрос является спорным, так как они поддерживают удобные с точки зрения пользователя псевдонимы (aliases,

иногда говорят — nicknames), с помощью которых он может вводить или выбирать имя адресата и получать корректный электронный адрес. Поэтому обычно пользователю не приходится вводить такие, мягко говоря, странные строки.

Последний вопрос, который мы обсудим в рамках разговора об отсылке почты, — это списки рассылки, позволяющие пользователю рассылать одно и то же сообщение группе получателей при помощи одной команды. Есть два варианта того, как может храниться список рассылки. Первый — локальное хранение пользовательским агентом. В этом случае пользовательский агент может просто послать каждому получателю отдельное сообщение. Помимо этого список может храниться удаленно на агенте передачи сообщений. Тогда сообщения будут тиражироваться в системе передачи сообщений, что позволяет множеству пользователей отсылать письма данному списку. Допустим, у группы исследователей птиц есть список рассылки, называющийся birders (птицеловы), установленный на агенте передачи сообщений meadowlark.arizona.edu. Тогда любое сообщение, посланное по адресу birders@meadowlark.arizona.edu, будет сначала отправляться в университет штата Аризона, а затем рассылаться оттуда в виде отдельных сообщений всем членам списка рассылки, где бы они ни находились. Для отправителя письма список рассылки внешне не отличается от обычного индивидуального адреса. Если отправитель не знает, что birders — это список рассылки, он вполне может подумать, что посылает письмо лично некоему профессору по имени Gabriel O. Birders.

7.2.3. Форматы сообщений

Перейдем теперь от рассмотрения пользовательского интерфейса к формату самих сообщений электронной почты. Чтобы сообщения, отсылаемые пользовательским агентом, обрабатывались агентами передачи сообщений, они должны быть оформлены в соответствии с определенными стандартами. Сначала мы рассмотрим основной ASCII-формат электронного письма стандарта RFC 5322, который является последним вариантом оригинального формата интернет-сообщений, описанного в RFC 822. Затем мы познакомимся с мультимедийным расширением этого первоначального стандарта.

RFC 5322 — формат интернет-сообщений

Сообщения состоят из примитивного конверта (описанного как часть SMTP в RFC 5321), нескольких полей заголовка, пустой строки и, наконец, тела сообщения. Каждое поле заголовка (логически) состоит из одной строки ASCII-текста, содержащей имя поля, двоеточие и (в большинстве случаев) значение поля. Первоначальный RFC 822 был создан несколько десятилетий назад и в нем нет четкого разграничения конверта и заголовка. Хотя частично стандарт был пересмотрен в RFC 5322, целиком обновить его было невозможно, поскольку RFC 822 уже был очень широко распространен. Обычно пользовательский агент формирует сообщение и передает его агенту передачи сообщений, который с помощью одного из полей заголовка создает конверт нового вида, представляющий собой некую старомодную смесь сообщения и конверта.

Основные поля заголовка, связанные с транспортировкой сообщения, перечислены в табл. 7.3. Поле To: содержит DNS-адрес основного получателя. Возможно наличие и нескольких получателей. В поле Cc: указываются адреса дополнительных получателей. С точки зрения доставки, никакой разницы между основным и дополнительными получателями нет. Разница между ними чисто психологическая и, может быть, важна для людей, но совершенно не существует для почтовой системы. Термин Cc: (carbon copy — экземпляр, сделанный «под копирку») несколько устарел, так как при работе с компьютерами копировальная бумага вообще-то не используется, тем не менее он прочно обосновался в электронной почте. Поле Bcc: (Blind carbon copy — слепая копия) аналогично предыдущему, с той разницей, что в последнем случае строка этого поля удаляется из всех экземпляров сообщения, отправленных как основному, так и дополнительным получателям. Это свойство позволяет рассылать одно письмо одновременно нескольким получателям так, что получатели не будут знать, что это письмо послано еще кому-либо кроме них.

Таблица 7.3.Поля заголовка стандарта RFC 5322, связанные с транспортировкой сообщения

Следующие два поля, From: и Sender:, сообщают соответственно, кто составил и отправил сообщение. Это могут быть разные люди. Например, написать письмо может руководитель предприятия, а отослать — его секретарь. В этом случае руководитель будет числиться в поле From:, а секретарь — в поле Sender:. Поле From: является обязательным, тогда как поле Sender: может быть опущено, если его содержимое не отличается от содержимого поля From: . Эти поля нужны на случай, если сообщение доставить невозможно и об этом следует проинформировать отправителя. Кроме того, по адресам, указанным в этих полях, может быть оправлен ответ.

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