Также возможны несколько вариантов сортировки. Самый распространенный — по времени получения; сначала более свежие письма, с маркером, указывающим на то, прочитано сообщение или нет. Поля сводной таблицы и порядок сортировки можно настроить по желанию пользователя.
Пользовательские агенты должны отображать входящие сообщения так, чтобы почту можно было читать. Обычно предоставляется предварительный просмотр письма (см. илл. 7.11), чтобы пользователь мог решить, стоит ли открыть его или пометить как спам. При предварительном просмотре могут использоваться маленькие значки или изображения, чтобы описать содержание письма. Обработка отображения также включает форматирование сообщения таким образом, чтобы оно помещалось на экране, перевод, конвертацию содержания в более удобный формат (например, оцифрованной речи в распознанный текст).
Прочитав сообщение, вы можете решить, что с ним делать. Это называется размещением сообщения (message disposition). Письмо можно удалить, написать ответ, переслать его другому пользователю и оставить в ящике для дальнейшей работы. В большинстве агентов присутствует один почтовый ящик для входящих и набор папок для сохраненной почты. Это позволяет распределять сообщения по разным категориям в зависимости от отправителя, темы и т.д.
Распределение по папкам также может происходить автоматически, до того, как пользователь прочтет сообщение. Например, агент проверяет поля и содержание писем, а также анализирует реакцию пользователя на предыдущие сообщения, чтобы определить, является ли письмо спамом. Многие интернет-провайдеры и компании используют софт, помечающий сообщения как важные или как спам, так что пользовательский агент может распределить их по соответствующим папкам. У провайдеров и компаний есть преимущество: они обрабатывают сообщения огромного количества пользователей, так что у них могут быть списки известных спамеров. Если сотни пользователей получают одно и то же сообщение, вероятно, это спам (хотя с другой стороны, это может быть и письмо от генерального директора для всех сотрудников). Предварительно сортируя письма и помечая часть из них как «похоже на спам», агент может избавить пользователей от массы работы по отделению нужной почты от мусора.
Но какой же спам встречается чаще всего? Спам генерируется сетью взломанных вычислительных устройств — ботнетом (botnet), а его содержание зависит от страны, в которой вы живете. В Азии часто предлагают приобрести поддельные дипломы, в США — дешевые лекарства и другую сомнительную продукцию. В большом количестве предлагаются невостребованные счета в нигерийском банке. Ну а таблетки для увеличения определенных частей тела входят в топ-лист, где бы вы ни жили.
Правила распределения писем по папкам пользователь может установить сам. Каждое правило определяет состояние и действие. Например, оно может гласить, что письмо от руководителя должно перемещаться в папку для немедленного прочтения, а письма от определенного списка людей должны помещаться в другую папку, чтобы их можно было прочитать позже. На илл. 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: