Форматы сообщений электронной почты
Обычное электронное письмо помимо текста самого письма может содержать различную дополнительную информацию: почтовый адрес адресата, почтовый адрес отправителя, дату создания письма. Подобная информация содержится в заголовке письма, предшествующем его телу. Некоторые ключевые слова заголовка являются обязательными, другие — не обязательными. Примерами обязательных ключевых слов являются From: и То:, а не обязательных — Subject:. Команды представляют собой часть процедуры рукопожатия, а строки заголовка — часть передаваемого сообщения. Типичный заголовок сообщения выглядит следующим образом:
From: cat@my.ru
То: dog@gukit.edu
Subject: Priglashenie v gosti.
После заголовка следует пустая строка, а за ней начинается тело сообщения в кодировке ASCII.
Передача сообщений с аудио-, видео- и прочей информацией, формат которой не соответствует ASCII, требует включения в сообщение специальных заголовков. Такой стандарт носит название многоцелевых расширений почты Интернета (Multipurpose Internet Mail Extensions, MIME).
Двумя наиболее важными MIME-заголовками, предназначенными для поддержки мультимедиа, являются Content-Type: и Content-Transfer-Encoding:. Заголовок Content-Type: позволяет агенту получателя произвести соответствующую обработку данных сообщения. Так, например, если сообщение содержит изображение в формате JPEG, агент получателя вызовет процедуру декомпрессии файлов JPEG. Информация, указанная в поле Content-Transfer-Encoding, позволяет подобрать нужную кодировку для правильного отображения полученных данных. Всего в настоящее время выделено 7 типов данных. Среди них:
· Text – этот тип указывает агенту получателя на то, что тело сообщения содержит текстовую информацию. Очень часто встречающейся парой тип/подтип является text/plain. Подтип plain означает простой текст, то есть текст не содержит команд или директив форматирования. Другой часто встречающейся парой является text/html. Подтип html указывает на то, что программа чтения почты должна интерпретировать теги, включенные в сообщение. Это позволяет отобразить сообщение в виде web-страницы, содержащей различные шрифты, гиперссылки, апплеты и т. д.
· Image– этот тип указывает на то, что информация, находящаяся в теле сообщения, является изображением. Двумя наиболее распространенными парами тип/подтип для изображений являются image/gif и image/jpeg. Распознавая каждый из этих подтипов, агент пользователя применяет соответствующий метод декомпрессии изображения.
· Application– это тип для всех данных, которые нельзя отнести к другим шести типам. Как правило, сюда попадают данные, предназначенные для обработки различными прикладными программами. Так, например, если включить в сообщение документ Microsoft Word, агент отправителя присвоит ему пару арplication/msword. При обработке сообщения агент получателя вызовет приложение Microsoft Word и передаст ему декодированные данные.
· Multipart. Подобно тому, как web-страница может включать в себя различные типы данных (текст, изображения, апплеты и т. д.), тело сообщения также может состоять из разнородной информации.
Примером сообщения, генерируемого агентом после отправки, может служить следующее:
From: dog@gukit.edu
То: cat@my.ru
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content -Type: image/jpeg
(base64 encoded data……
………………………….
base64 encoded data)
Агент отправителя dog кодировал JPEG изображение методом base64.
Агент получателя сначала обнаружит строку Content-Transfer-Encoding: base64 и декодирует тело сообщения методом base64, затем агент увидит строку Content -Type: image/jpeg и произведёт jpeg-декомпрессию данных.
После получения сообщения со стандартными заголовками, сервер добавляет в начало заголовка строку Received:, содержащую адреса отправителя (From), получателя (То) и время получения сообщения сервером.
Base64 - это специальный метод кодирования информации в 64-разрядный код (6 бит), широко используемый в приложениях электронной почты для кодирования данных. Весь диапазон закодированных символов укладывается в английский алфавит в верхнем и нижнем регистре — символы (A—Z, a—z), цифры (0—9), и символы «+» и «/», с символом «=» в качестве специального кода суффикса.
Иногда сервер генерирует запросы или сообщения в формате Base64. В этом случае клиент должен высылать ответ или сообщение тоже закодированное в формат Base64.
POP
Протокол РОРЗ является одним из самых простых протоколов доступа к электронной почте. Но с весьма ограниченной функциональностью. Протокол начинает действовать после того, как агент пользователя (клиент) устанавливает ТСР-соединение с портом 110 почтового сервера, и подразумевает выполнение трех основных фаз: авторизации, транзакции и обновления. Во время авторизации агент передает серверу имя пользователя и пароль для того, чтобы сервер предоставил агенту доступ к сообщениям электронной почты. В фазе транзакции пользователь получает сообщения, а также может пометить сообщения, предназначенные для удаления, и получить почтовую статистику. Наконец, фаза обновления наступает после того, как клиент посылает команду quit и закрывает РОРЗ-сеанс. Почтовый сервер производит удаление сообщений, помеченных пользователем.
Во время РОРЗ-транзакции агент пользователя посылает почтовому серверу команды, на каждую из которых сервер реагирует посылкой одного из двух ответных сообщений: +ОК (иногда с последующей передачей данных сервера клиенту) и -ERR, указывающего на ошибку в команде клиента.
Авторизация включает в себя две возможные команды: user <имя пользователя> и pass <пароль>. Для того чтобы проиллюстрировать действие этих команд, предположим, что вы устанавливаете соединение с РОРЗ-сервером через порт 110. Если mailServer — имя вашего почтового сервера, то процесс авторизации в программе Telnet будет выглядеть следующим образом:
telnet pop.mailServer.ru 110
+OK РОРЗ server ready
User user
+OK
Pass 1234
+ok user successfully logged on
Если какая-либо из команд будет введена неверно, сервер выдаст сообщение -ERR.
Теперь обратимся к фазе транзакции. Как правило, агент пользователя, использующий протокол РОРЗ, в зависимости от настроек может автоматически удалять или не удалять сообщения после их приема; при этом во время транзакции будут применяться различные команды. Если загруженные сообщения необходимо удалять, агент посылает серверу команды list, retr и dele. Пусть, например, в почтовом ящике пользователя находятся два сообщения. Ниже приведен диалог клиента и сервера во время транзакции:
list
1 1498
2 2912
.
retr 1
(Horoshajа pogoda!!!)
.
dele 1
retr 2
(V trave sidel kuznechik,
sovsem kak ogurechik,
zelenen'kii on byl... )
.
dele 2
quit
+0K P0P3 server signong off
Сначала агент пользователя получает от сервера список сообщений с указанием размера каждого сообщения, а затем последовательно принимает и удаляет сообщения с сервера. Во время транзакции агентом используются лишь четыре команды: list, retr, dele и quit. Синтаксис этих команд описан в документе RFC 1939. После обработки команды quit РОРЗ - сервер переходит в фазу обновления и производит фактическое удаление переданных сообщений.