1.1.2. Протоколы электронной почты (smtp и pop)

Протокол прикладного уровня SMTP, описанный в документе RFC 2821, составляет основу службы электронной почты Интернета. Теперь рассмотрим подробнее, каким образом осуществляется передача сообщения между почтовыми серверами. Любопытно отметить, что протокол SMTP по своей сути напоминает непосредственное общение между двумя людьми.

Итак, сначала SMTP-клиент пытается установить TCP-соединение с портом 25 сервера; если сервер не отвечает, попытка повторяется позднее. После того как соединение установлено, клиент и сервер обмениваются рукопожатиями на прикладном уровне. В ходе процедуры рукопожатия клиент определяет адреса почтовых ящиков отправителя и получателя сообщения. По завершении рукопожатия начинается процесс передачи сообщения от клиента к серверу. Поскольку передача осуществляется с помощью протокола TCP, гарантируется надежная доставка данных. Если в очереди клиента имеются другие сообщения, предназначенные этому же серверу, все они пересылаются последовательно через одно ТСР-соединение. После передачи всех сообщений клиент закрывает соединение с сервером.

Рассмотрим пример обмена сообщениями между SMTP-клиентом (C) и SMTP-сервером (S). Хост клиента имеет имя my.ru, а хост сервера — gukit.edu. (Строки, помеченные голубым цветом, передаются клиентом в свой сокет в той же кодировке ASCII, в которой они приведены ниже; то же самое касается строк, помеченных желтым цветом и относящихся к серверу.)

Итак, после установления ТСР-соединения обмен может происходить следующим образом:

220 gukit.edu

НЕLO gukit.edu

250 Hello my.ru, pleased to meet you

MAIL FROM: <cat@my.ru>

250 cat@my.ru... Sender ok

RCPT TO: <dog@gukit.edu>

250 dog@gukit.edu. Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

Hochesh' sosisku?

Prihodi v gosti!

.

250 Message accepted for delivery

QUITS: 221 gukit.edu closing connection

В приведенном примере клиент послал почтовому серверу gukit.edu сообщение «Hochesh' sosisku? Prihodi v gosti!» с почтового сервера my.ru. Клиент использовал пять различных команд: HELO, MAIL FROM, RCPT TO, DATA и QUIT. Смысл этих команд вполне понятен. Кроме того, клиент использовал символ точки, указывающий на конец сообщения. Сервер посылает ответ на все команды клиента. Ответ включает код и (необязательно) описание на английском языке. Протокол SMTP поддерживает постоянные соединения: Если клиенту необходимо отправить несколько сообщений подряд, все сообщения передаются через одно TCP-соединение. Передача каждого нового сообщения начинается с команды MAIL FROM: my.ru, а заканчивается одиночным символом точки. После того как все сообщения посланы, клиент генерирует команду QUIT.

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

Обычное электронное письмо помимо текста самого письма может содержать различную дополнительную информацию: почтовый адрес адресата, почтовый адрес отправителя, дату создания письма. Подобная информация содержится в заголовке письма, предшествующем его телу. Некоторые ключевые слова заголовка являются обязательными, другие — не обязательными. Примерами обязательных ключевых слов являются 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 РОРЗ - сервер переходит в фазу обновления и производит фактическое удаление переданных сообщений.