<<
>>

RFC 822

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

Основные поля заголовка, связанные с транспортировкой сообщения, перечислены в табл. 7.4. Поле То: содержит DNS-адрес основного получателя. Возможно наличие и нескольких получателей. В поле Сс: указываются адреса дополнительных получателей.

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

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

Поле Значение

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

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

Поле Return-Path: добавляется последним агентом передачи сообщений. Предполагалось, что это поле будет сообщать, как добраться до отправителя. Теоретически, эта информация может быть собрана из всех полей Received: заголовка (кроме имени почтового ящика отправителя), однако на практике оно редко заполняется подобным образом и обычно просто содержит адрес отправителя.

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

Таблица 7.5. Некоторые поля, используемые в заголовке сообщения стандарта ЯРС 822

Поле Reply-to: иногда используется в случае, если ни составитель письма, ни его отправитель не хотят получать на него ответ.

Например, управляющий отделом сбыта пишет письмо, информирующее клиента о новом продукте. Это письмо отправляется его секретарем, но в поле Reply-to: указан адрес менеджера отдела продаж, который может ответить на вопросы и принять заказы.

В документе RFC 822 открыто сказано, что пользователям разрешается изобретать собственные заголовки для своих нужд при условии, что эти заголовки начинаются со строки Х-. Гарантируется, что в будущем никакие стандартные заголовки не будут начинаться с этих символов, чтобы избежать конфликтов между официальными и частными заголовками. Иногда умники-студенты включают поля вроде X-Fruit-of-the-Day: (сегодняшний плод) или X-Disease-of-the-Week: (недуг недели), использование которых вполне законно, хотя их смысл и не всегда понятен.

После заголовков идет тело самого сообщения. Пользователь может разместить в нем все, что ему угодно. Некоторые люди завершают свои послания сложными подписями, включающими рисунки, созданные из ASCII-символов, популярными и малоизвестными цитатами, политическими заявлениями и разнообразными объявлениями (например, «Корпорация АБВ не несет ответственности за высказанное выше мнение. Собственно, она даже не в силах постичь его»).

<< | >>
Источник: Э. ТАНЕНБАУМ. КОМПЬЮТЕРНЫЕ СЕТИ 4-Е ИЗДАНИЕ. 2003

Еще по теме RFC 822:

  1. Статья 822. Преобладающие права арендатора жилья
  2. 1.3.
  3. Статья 821. Срок договора аренды жилья
  4. § 3. Товарный и коммерческий кредит
  5. 1. Понятие кредитного договора
  6. 15.2. Кредитный договор
  7. 4. Договоры товарного и коммерческого кредита
  8. 1.2.
  9. 1. Понятие жилищного законодательства и договора найма жилища
  10. 1. Понятие договора займа
  11. § 1. Понятие направленности обязательства
  12. § 27 Действие давности на обязательства. – Погашение права на иск. – Начало исчисления давности. – Открытие права на иск. – Исчисление давности в срочных и бессрочных договорах, при периодическом исполнении, по обязательствам главным и зависящим. – Перерыв давности – признанием долга. – Постановления русского закона о сем предмете.
  13. Т
  14. Словарь ____________терминов
  15. Л.О. Доліненко, В.О. Доліненко, С.О. Сарновська. Цивільне право України, 2006