Nets2010 (1131259), страница 55
Текст из файла (страница 55)
Поначалу возможности электронной почты сводились к передаче файлов с одним ограничением, что первая строка файла должна содержать адрес получателя. Со временем такой подход оказался очень ограниченным в силу следующих обстоятельств:
-
Посылать одно и то же сообщение сразу нескольким получателям было не удобно.
-
Сообщение не имело внутренней структуры, что усложняло его обработку на машине.
-
Отправитель никогда не знал, получено сообщение или нет.
-
Если, отправляясь в командировку, кто-то хотел перенаправить свои сообщения кому-то другому, это было не возможно.
-
Интерфейс пользователя был неудобен. Он требовал от пользователя сначала работать в редакторе файлов, затем переходить в систему отправки файлов.
-
Было невозможно отправить вперемешку и текст, и голос и видео.
Исторически первыми системами были системы в архитектуре TCP/IP, описанные в RFC 821 и 822. В 1984 появилось решение Х.400 в рамках эталонной модели OSI/ISO. Десять лет спустя Х.400 использовалось лишь в единичных организациях, почти везде использовалось решение Sendmail.
7.4.1. Архитектура и сервис
Архитектура почтовой системы состоит из двух основных компонентов - агента пользователя и агента передачи сообщений. Первый отвечает за интерфейс с пользователем, составление и отправку сообщений. Второй – за доставку сообщения от отправителя к получателю.
Обычно почтовая система поддерживает пять базовых функций:
-
Композиция. Обеспечивает создание сообщений и ответов. Хотя для формирования тела сообщения может быть использован любой текстовый редактор, система обеспечивает заполнение многочисленных полей заголовка сообщения. Например, если формируется ответ, система автоматически выделит адрес из исходного сообщения и подставит его как адрес получателя.
-
Передача. Эта функция обеспечивает передачу сообщения от отправителя к получателю без вмешательства пользователей.
-
Отчет перед отправителем о доставке: было ли сообщение доставлено? Было ли отвергнуто? Было ли потеряно? Для многих приложений эти отчеты крайне важны.
-
Показ сообщения является существенной функцией почтовой службы. Часто она должна выполнять перекодировку, изменять формат и т.д.
-
Размещение - это последний этап, на котором определяют, что делать с сообщением: надо ли его уничтожить после прочтения (или до), если сохранить, то где. Поиск интересующего сообщения, перенаправление сообщения, повторное прочтение ранее полученного сообщения – все это относится к данной функции.
7.4.2. Агент пользователя
Агент пользователя – обычно программа, имеющая множество команд для получения, составления сообщения и ответа на сообщение, а также для работы с почтовым ящиком. Некоторые агенты используют командную строку, некоторые - графический интерфейс.
7.4.2.1. Отправка почты
Чтобы послать сообщение, пользователь должен предоставить адрес назначения, само сообщение и другие параметры, например, приоритетность, секретность и т.п. Для создания сообщения может быть использован любой текстовый процессор либо текстовый редактор, встроенный в агент пользователя. Все параметры должны быть заданы в формате, который понимает и с которым может работать агент пользователя. Большинство агентов пользователя ожидает адрес назначения в формате DNS: mailbox@location.
Агент пользователя также поддерживает лист рассылки. Этот лист позволяет рассылать одно и то же сообщение сразу нескольким пользователям. Причем сообщение размножается не обязательно самим агентом, а там, где поддерживается лист рассылки.
7.4.2.2. Чтение почты
Прежде чем агент пользователя (далее АП) что-либо высветит на экране при загрузке, он просмотрит почтовый ящик на предмет того, что нового туда поступило. Затем он высветит на экране его содержимое с краткой аннотацией каждого сообщения.
После того как содержимое ящика показано пользователю, последний может выполнять любую из имеющихся команд. Типичный состав команд показан в таблице 7-50.
Таблица 7-50. Типичный состав команд почтового ящика
| Команда | Параметр | Описание |
| h | № | Отобразить заголовки на экране |
| c |
| Отобразить только текущий заголовок |
| t | № | Вывести сообщение на экран |
| s | address | Отправить сообщение |
| f | № | Переслать сообщение |
| a | № | Ответить на сообщение |
| d | № | Удалить сообщение |
| u | № | Восстановить ранее удаленное сообщение |
| m | № | Переместить сообщение в другой почтовый ящик |
| k | № | Оставить сообщение после выхода |
| r | mailbox | Просмотреть другой почтовый ящик |
| n |
| Перейти к следующему сообщению |
| b |
| Вернуться к предыдущему сообщению |
| g | № | Перейти к конкретному сообщению, но не отображать его |
| e |
| Выйти и обновить почтовый ящик |
7.4.3. Формат сообщений
Рассмотрим формат самого сообщения. Начнем с формата по RFC 822, а потом перейдем к мультимедийному расширению этого документа.
7.4.3.1. RFC 822
Сообщение состоит из простейшего конверта, полей заголовка, пустой строки и тела сообщения. Каждая строка заголовка – это строка ASCII-текста, содержащая название поля, двоеточие и какое-то значение. Стандарт 822 не различал четко заголовок и конверт. В современных почтовых системах это различие проведено лучше, и агент пользователя имеет дело с заголовком, а агент передачи – с конвертом, который он формирует на основе заголовка.
Важные поля заголовка перечислены в таблице 7-51.
Таблица 7-51. Поля заголовка RFC 822
| Заголовок | Значение |
| Поля, относящиеся к транспортировке сообщения | |
| To: | Адрес основного получателя |
| Cc: | Адрес дополнительного получателя |
| Bcc: | Адрес для «слепых» копий |
| From: | Создатель данного сообщения |
| Sender: | Адрес отправителя |
| Received: | Строка, добавляемая каждым агентом на пути сообщения |
| Return-Path: | Может использоваться для определения обратного пути к отправителю |
| Некоторые поля, используемые в заголовке сообщения | |
| Date: | Дата и время отправки сообщения |
| Reply-To: | Адрес, на который нужно отправлять ответ |
| Message-Id: | Уникальный номер сообщения для использования в дальнейшем |
| In-Reply-To: | Идентификатор сообщения, ответом на которое является текущее сообщение |
| References: | Другие релевантные идентификаторы сообщения |
| Keywords: | Ключевые слова, выбранные пользователем |
| Subject: | Краткий отрывок сообщения для отображения одной строкой |
7.4.3.2. MIME – Multipurpose Internet Mail Extension
Когда Интернет только начинал развиваться, почтовые системы способны были передавать только текстовые сообщения на английском языке в формате ASCII. Для этих целей RFC 822 подходило вполне. В наши дни такой подход уже не годится. Необходимо, чтобы почтовая система умела работать:
-
с сообщениями на европейских языках (французском, немецком и т.д.)
-
с сообщениями не в латинском алфавите (русском, арабском и т.д.)
-
с сообщениями не в алфавите (японский, китайский)
-
с сообщениями, не содержащими текст (звук, видео, графика)
MIME – многоцелевое расширение почтовой службы в Internet. Основная идея MIME – расширение RFC 822 в целях введения структуры в тело сообщения и правил кодировки ASCII-сообщений. Естественно, что это повлияло на программы доставки и отправки сообщений.
MIME определяет пять новых заголовков, показанных в таблице 7-52. Первый сообщает агенту пользователя, что он имеет дело с MIME-сообщением, и то, какая версия MIME используется. Второй и третий характеризуют сообщение. Например, второе поле можно использовать для фильтрации сообщений.
Таблица 7-52. Пять заголовков RCF 822, определенных в MIME
| Заголовок | Значение |
| MIME-Version: | Идентифицирует версию MIME |
| Content-Description: | Строка, описывающая содержимое сообщения |
| Content-Id: | Уникальный идентификатор |
| Content-Transfer-Encoding: | Способ подготовки тела письма к передаче |
| Content-Type: | Тип сообщения |
Заголовок Content_Transfer_Encoding определяет, как сообщение должно быть подготовлено для передачи через сеть. Для этого используется пять основных схем. Простейшая схема – для передачи ASCII-текста – 7 бит на символ. Однако для учета национальных алфавитов используется 8 битная схема. Однако ни первая, ни вторая схемы не должны превышать 1000 символов в строке.
Сложная ситуация с передачей двоичных данных. Для корректной передачи такого типа данных (исполняемый код программ) используется схема base64 encoding. Эта схема разбивает сообщение на блоки по 24 бита. Каждый блок разбивается на 4 группы по 6 бит каждая. Можно указать и какую-то особую схему в поле Content-Transfer-Encoding.
Последнее поле заголовка указывает тип сообщения. Возможные значения этого поля указаны в таблице 7-53.
Таблица 7-53. Типы и подтипы сообщений MIME
| Тип | Подтип | Описание |
|
Text | Plain | Неформатированный текст |
| Richtext | Текст с простым форматированием | |
|
Image | Gif | Изображение в формате GIF |
| Jpeg | Изображение в формате JPEG | |
| Audio | Basic | Звук |
| Video | Mpeg | Фильм в формате MPEG |
|
Application | Octet-stream | Неинтерпретируемая последовательность байтов |
| Postscript | Готовый к печати документ в формате PostScript | |
|
Message | Rfc822 | Сообщение MIME RFC 822 |
| Partial | Сообщение перед передачей было разбито на несколько частей | |
| External-body | Непосредственно сообщение следует передать через сеть | |
|
Multipart | Mixed | Независимые части в определенной последовательности |
| Alternative | Вышеупомянутое сообщение в различных форматах | |
| Parallel | Части сообщения необходимо просматривать вместе | |
| Digest | Каждая часть является самостоятельным сообщением RFC 822 |
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
