Протокол IMAP4

Протокол IМАР4 (Internet Message Access Protocol, Version 4, Протокол доступа к электронной почте Internet, версия 4) позволяет клиентам получать Доступ и манипулировать сообщениями электронной почты на сервере.

Существенным отличием протокола IMAP4 от протокола РОРЗ является то, что IMAP4 поддерживает работу с системой каталогов (или папок) сообщений. IMAP4 позволяет управлять каталогами (папками) удаленных сообщений так же, как если бы они располагались на локальном компьютере. IMAP4 позволяет клиенту создавать, удалять и переименовывать почтовые ящики, проверять наличие новых сообщений и удалять старые. Благодаря тому что IMAP4 поддерживает механизм уникальной идентификации каждого сообщения в почтовой папке клиента, он позволяет читать из почтового ящика только сообщения, удовлетворяющие определенным условиям или их части, менять атрибуты сообщений и перемещать отдельные сообщения.

Структура папок в значительной степени зависит от типа почтовой системы, но в любой системе у клиента есть специальный каталог INBOX, куда попадают поступающие клиенту сообщения.

Принципы работы

Протокол IMAP4 работает поверх транспортного протокола, который обеспечивает надежный и достоверный канал передачи данных между клиентом и сервером IMAP4. При работе по TCP, IMAP4 использует 143-й порт. Команды и данные IMAP4 передаются по транспортному протоколу в том виде, в каком их отправляет сервер или пользователь.

Принцип передачи данных IMAP4 такой же, как и у других подобных протоколов. Сначала клиент и сервер обмениваются приветствиями. Затем клиент отправляет на сервер команды и данные. Сервер, соответственно, передает клиенту ответы на обработку команд и данных. После завершения обмена канал закрывается.

Если сервер использует таймер контроля времени соединения, он должен быть установлен не менее чем на 30-минутный промежуток "неактивности" клиента, т. е. если сервер в течение 30 минут получает хотя бы одну команду, таймер сбрасывается.

Весь обмен данными между клиентом и сервером организован в виде строк, завершающихся символами <CRLF>, либо в виде последовательности байт заданной длины. Каждая команда клиента начинается с идентификатора или тега команды. Тег, как правило, представляет собой короткую строку, состоящую из букв и цифр, (например, А0001, А0002 и т. д.). Тег является уникальным идентификатором данной команды клиента. Ответы сервера или следующие команды клиента могут ссылаться на данную команду по ее тегу.

Каждая команда клиента начинается с новой линии. В тех случаях, когда команда передает поток данных заданной длины или когда команда требует ответа с сервера, для того чтобы продолжить работу (например, при аутентификации), она может занимать несколько строк.

Строки данных, передаваемые с сервера в ответ на команду клиента, могут не содержать тег, а содержать символ "*". Это означает, что они являются

промежуточными строками потока данных ответа, а идентификатор их команды содержится в последней строке потока. В такой поток данных не может вклиниться другая команда.

Если сервер обнаружил ошибку в команде, он отправляет уведомление BAD клиенту с тегом неправильной команды. Если команда успешно обработана — возвращается уведомление ОК с тегом команды. Если команда вернула отрицательный результат, например, в случае невозможности выполнить данную команду — возвращается уведомление NO с тегом невыполненной команды.

Важной особенностью протокола IMAP является то, что взаимодействие клиента с сервером не строится по принципу "запрос-ответ", в котором каждая из сторон "ходит" по очереди. Клиент может отправить новую команду на сервер, не дожидаясь ответа на предыдущую, естественно, когда эти команды не взаимосвязаны или ответ одной не повлияет на результат другой. Сервер может обрабатывать несколько команд одновременно и отвечать на каждую из них по ее окончанию. При этом ответ на более позднюю команду может поступить раньше, поэтому ответ сервера всегда содержит тег той команды, к которой он относится.

Для работы в таком режиме, клиент и сервер должны фиксировать весь поток данных обмена, поскольку как сервер так и клиент в своих запросах и ответах могут ссылаться на команды и данные, введенные на предыдущих стадиях сессии обмена.

Для того чтобы обеспечить гибкость и многофункциональность операций работы с сообщениями, почтовые системы IMAP присваивают сообщениям определенные атрибуты.

Атрибуты сообщений системы IMAP

Каждое сообщение в почтовой системе для работы с IMAP имеет уникальный идентификатор, по которому можно получить доступ к этому сообщению. Уникальный идентификатор UID представляет собой 32-битное число, которое идентифицирует сообщение в данной папке. Каждому сообщению, попавшему в папку, присваивается максимальное число из UID-сообщений, попавших в данную папку ранее. Уникальные идентификаторы сообщений сохраняются от сессии к сессии и могут использоваться, например, для синхронизации каталогов мобильных пользователей.

Каждая папка в системе также имеет уникальный действительный идентификатор (UIDVALIDITY). Вместе с UID-сообщение эта пара образует 64-битное число, идентифицирующее каждое сообщение. Если UID-сообщение сохраняется постоянным, то UIDVALIDITY данной папки в текущей сессии Должен быть больше, чем в предыдущей сессии.

Кроме уникального идентификатора, сообщение в системе IMAP имеет порядковый номер, т. е. все сообщения в данном почтовом ящике последовательно нумеруются. Если в почтовый ящик добавляется новое сообщение, ему присваивается номер на 1 больше количества сообщении в почтовом ящике. При удалении какого-либо сообщения из данной папки порядковые номера всех сообщений пересчитываются, поэтому порядковый номер сообщения может меняться во время сессии. Большинство команд IMAP4 работают с порядковыми номерами сообщений, а не с UID.

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

Кроме того, на сервере IMAP хранятся дата и время получения сообщения сервером. Например, если сообщение получено по SMTP, то фиксируется дата и время доставки по адресу назначения, общий размер сообщения, состав конверта (заголовка) сообщения (не путать с конвертом SMTP), структура сообщения (MIME-структура).

Основные команды

IMAP4 — гибкий и многофункциональный протокол с широкими возможностями. Он обслуживает более 20 различных команд клиента по управлению состоянием своей почты. Подробное описание всех команд и ответов IМАР4-сервера вы можете найти, в RFC-2060. Далее будут описаны только некоторые из клиентских команд, и на примерах их обработки показана общая схема взаимодействия клиента и сервера IMAP4.

IMAP4 поддерживает текстовые команды и ответы сервера, т. е. ASCII-последовательности символов. Строка команды или данных завершается последовательностью <CRLF>. 8-битные данные, в соответствии с спецификацией MIME, не могут передаваться по IMAP4 в "открытом" виде. Как правило, реализации IMAP4 перед передачей двоичных данных кодируют их base64.

Так же как и РОРЗ-сервер, 1МАР4-сервер обрабатывает команды в зависимости от одного из четырех состояний, в котором он находится:

1. Состояние вне аутентификации, в котором клиент должен для начала работы зарегистрироваться в сервере.
2. Состояние аутентификации, в котором клиент может выбрать для работы папку с сообщениями.
3. Состояние работы с почтовой папкой, в котором клиент производит основную работу с сообщениями.
4. Состояние отсоединения, в котором сервер завершает транзакцию работы клиента.

Далее при описании команд, символом "S:" будет обозначаться поток данных от сервера IMAP4, а символом "С:" — поток данных от клиента.

S * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

S * OK [PERMANENT FLAGS (\Deleted \Seen \*)] Limited

S А142 OK [READ-WRITE] SELECT completed

Сервер IМАР4, прежде чем подтвердить завершение обработки команды, передает клиенту атрибуты данного каталога. В показанном выше примере: