Шрифт:
Закладка:
Правила распределения писем по папкам пользователь может установить сам. Каждое правило определяет состояние и действие. Например, оно может гласить, что письмо от руководителя должно перемещаться в папку для немедленного прочтения, а письма от определенного списка людей должны помещаться в другую папку, чтобы их можно было прочитать позже. На илл. 7.11 изображено несколько папок. Самые важные — это Входящие (для почты, которая не была никуда распределена при получении) и Спам (для сообщений, которые программа посчитала нежелательными).
7.2.3. Форматы сообщений
Перейдем от рассмотрения пользовательского интерфейса к формату самих сообщений электронной почты. Чтобы сообщения, отсылаемые пользовательским агентом, обрабатывались агентами передачи сообщений, они должны быть оформлены в соответствии с определенными стандартами. Прежде всего мы рассмотрим базовый ASCII-формат электронного письма стандарта RFC 5322. Это последний вариант оригинального формата интернет-сообщений, описанного в стандарте RFC 822 и его многочисленных обновлениях. Затем мы познакомимся с мультимедийным расширением этого первоначального стандарта.
RFC 5322 — формат интернет-сообщений
Сообщения состоят из примитивного конверта (в RFC 5321 он описан как часть SMTP), нескольких полей заголовка, пустой строки и тела сообщения. Каждое поле заголовка состоит (логически) из одной строки ASCII-текста, содержащей имя поля, двоеточие и значение поля (в большинстве случаев). Первоначальный RFC 822 был создан несколько десятилетий назад, и в нем нет четкого разграничения конверта и заголовка. Хотя частично стандарт был пересмотрен в RFC 5322, целиком обновить его было невозможно, поскольку RFC 822 уже широко применялся. Обычно пользовательский агент формирует сообщение и передает его агенту передачи сообщений, который с помощью одного из полей заголовка создает конверт. Получается несколько старомодное сочетание письма и конверта.
Основные поля заголовка, связанные с транспортировкой сообщения, перечислены на илл. 7.12. Поле To: (Кому) содержит адрес электронной почты основного получателя (их может быть несколько). В поле Cc:(Carbon copy — Копия; буквально «под копирку») указываются адреса дополнительных получателей. С точки зрения доставки никаких отличий между основным и дополнительными получателями нет. Разница между ними чисто психологическая и важна только для людей, но не для почтовой системы. Обозначение Cc: несколько устарело, ведь компьютеры не используют копировальную бумагу, но термин прижился. Поле Bcc: (Blind carbon copy — Скрытая копия) аналогично предыдущему, но в этом случае строка поля удаляется из всех экземпляров сообщения, отправленных как основному, так и дополнительным получателям. Это позволяет рассылать письмо одновременно нескольким получателям, и они не будут знать, что это письмо отправлено кому-то еще.
Поле
Значение
To:
Электронный адрес (адреса) основного получателя (получателей)
Cc:
Электронный адрес (адреса) дополнительного получателя (получателей)
Bcc:
Электронный адрес (адреса) получателей скрытой копии
From:
Автор (авторы) сообщения
Sender:
Электронный адрес отправителя
Received:
Строка, добавляемая каждым агентом передачи сообщений на пути
Return-Path:
Может быть использовано для идентификации обратного пути к отправителю
Илл. 7.12. Поля заголовка стандарта RFC 5322, связанные с транспортировкой сообщения
Следующие два поля, From: (От) и Sender: (Отправитель), сообщают, соответственно, кто составил и отправил сообщение. Это могут быть разные люди. Например, написать письмо может руководитель предприятия, а отослать — его секретарь. В этом случае в поле From: будет указано имя руководителя, а в поле Sender: — имя секретаря. Поле From: является обязательным, тогда как поле Sender: может быть опущено, если его содержимое не отличается от содержимого поля From:. Эти поля нужны на случай, если сообщение доставить невозможно и об этом нужно проинформировать отправителя. Кроме того, на адреса, указанные в этих полях, может быть выслан ответ.
Строка, содержащая поле Received: (Получено), добавляется каждым агентом передачи сообщений на пути следования письма. В это поле помещается идентификатор агента, дата и время получения сообщения, а также другая информация, которая может быть использована для исправления неисправностей в системе маршрутизации. Поле Return-Path: (Обратный путь) добавляется последним агентом передачи сообщений. Предполагалось, что это поле будет сообщать, как добраться до отправителя. Теоретически эта информация может быть собрана из всех полей Received: (кроме имени почтового ящика отправителя), но на практике оно редко заполняется и обычно просто содержит адрес отправителя.
Помимо полей, показанных на илл. 7.12, сообщения стандарта RFC 5322 могут также включать широкий спектр полей заголовка, используемых пользовательским агентом или самим пользователем. Наиболее распространенные поля заголовка приведены на илл. 7.13. Информации в таблице достаточно, чтобы понять назначение полей, поэтому мы не будем рассматривать их подробно.
Поле
Значение
Date:
Дата и время отправки сообщения
Reply-to:
Электронный адрес, на который следует присылать ответ
Message-Id:
Уникальный номер для последующей ссылки на это сообщение
In-Reply-To:
Идентификатор Message-Id сообщения, в ответ на которое отправляется это сообщение
References:
Другие важные ссылки (идентификаторы Message-Id)
Keywords:
Ключевые слова, выбираемые пользователем
Subject:
Краткое изложение сообщения для отображения в одной строке (тема письма)
Илл. 7.13. Некоторые поля, используемые в заголовке сообщения стандарта RFC 5322
Поле Reply-to: (Обратный адрес) иногда применяется в случае, если ни составитель письма, ни его отправитель не хотят получать на него ответ. Например, управляющий отделом сбыта может написать письмо, информирующее клиентов о новом продукте. Это письмо отправляется его секретарем, но в поле Reply-to: указан адрес менеджера отдела продаж, который может ответить на вопросы и принять заказы. Это поле также может пригодиться, если у отправителя есть два электронных адреса и он хочет, чтобы ответы приходили на второй адрес.
Message-Id: (Идентификатор сообщения) — автоматически генерируемое число, которое используется, чтобы связывать сообщения (например, при ответе на письмо) и избежать повторной доставки.
В спецификации RFC 5322 пользователям напрямую разрешается создавать дополнительные заголовки в своих целях. В RFC 822 и последующих стандартах эти заголовки начинаются со строки X-. Гарантируется, что в будущем ни один стандартный заголовок не будет начинаться с этих символов, чтобы избежать конфликтов между официальными и частными заголовками. Иногда умники-студенты включают поля вроде X-Fruit-of-the-Day: («фрукт дня») или X-Disease-of-the-Week: («недуг недели»), что вполне допустимо, хотя и не всегда понятно.
После заголовков идет тело самого сообщения. Пользователь может разместить в нем все, что ему угодно. Некоторые люди завершают свои послания сложными подписями с популярными или малоизвестными цитатами, политическими заявлениями и разнообразными объявлениями (например, «Корпорация АБВ не несет ответственности за высказанное выше мнение. Собственно, она даже не в силах его постичь»).
MIME — многоцелевые расширения интернет-почты
На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений на английском языке, представленных символами ASCII. В таких условиях первоначального стандарта RFC 822 было вполне достаточно: он
