Форматы сообщений электронной почты

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

From: [email protected]

То: [email protected]

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: [email protected]

То: [email protected]

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 РОРЗ - сервер переходит в фазу обновления и производит фактическое удаление переданных сообщений.

Наши рекомендации