Почтовые протоколы POP3 и IMAP

DELE msg ( msg — номер сообщения)

Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется, пока сессия не войдет в режим UPDATE.

Пример использования команды:

К: DELE 1
С: +OK message 1 deleted
...
К: DELE 2
С: -ERR message 2 already deleted

NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.

RSET (не использует каких-либо аргументов)

Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик. Например:

К: RSET
С: +OK maildrop has 2 messages (320 octets)

Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии UPDATE.

Ряд команд не входят в перечень обязательных (являются опционными).

TOP msg n, где msg — номер сообщения, а n — число строк (применяется только в режиме TRANSACTION).

При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение.

UIDL [msg], где msg — номер сообщения является опционным (Unique-ID Listing).

Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения (unique-id listing). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды:

К: UIDL
С: +OK
С: 1 whqtswO00WBw418f9t5JxYwZ
С: 2 QhdPYR:00WBw1Ph7x7

USER name, где name характеризует почтовый ящик сервера.

Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика — команду PASS. Команда может вызвать следующие отклики:

Примеры использования команды USER:

К: USER frated
С: -ERR sorry, no mailbox for frated here (почтового ящика нет)
...
К: USER mrose
С: +OK mrose is a real hoopy frood

PASS string (string — пароль для доступа к почтовому серверу)

Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики:

Пример диалога при использовании команды PASS:

К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: -ERR maildrop already locked
...
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: +OK mrose's maildrop has 2 messages (320 octets)

APOP name digest, где name — идентификатор почтового ящика, а digest — дайджест сообщения — MD5 (RFC-1828). Команда используется только на стадии авторизации.

Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822], и должен быть уникальным для всех заголовков уведомлений. Так, для UNIX-приложений синтаксис временной метки должен иметь вид:

<process-ID.clock@hostname>

где process-ID представляет собой десятичное значение PID процесса, clock — десятичное показание системных часов, а hostname — полное имя домена, где размещен сервер POP3.

Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр name семантически идентичен параметру name команды USER. Параметр digest вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки), за которой следует строка пароля, известная только клиенту и серверу. Параметр digest содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII-символов. Сервер, получив команду APOP, проверяет принятый дайджест и, если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик, и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но ни в коем случае оба метода попеременно.

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

Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822].

Протокол Интернет для работы с сообщениями IMAP

Протокол IMAP 4.1 (Internet Message Access Protocol — version 4rev1, V.Crispin, RFC-2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143 (смотри также http://book.itep.ru/4/44/imap4443.htm). Протокол IMAP представляет собой альтернативу POP-3. Так же, как и последний, он работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.

В отличие от POP3, IMAP хранит почтовые сообщения у себя "вечно" (пока клиент сам не пожелает их стереть).

Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту — данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера, имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.

Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например A0001, A0002 и т.д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку. Имеется два случая, когда строка, посланная клиентом, не представляет собой законченную команду. В первом — аргумент команды снабжается кодом, определяющим число октетов в строке (см. описание литеральных строк в разделе "Форматы данных"). Во втором — аргументы команды требуют отклика со стороны сервера (см. описание команды authenticate ). В обоих вариантах сервер посылает запрос продолжения команды, если он готов. Такой отклик сервера начинается с символа "+".

Замечание. Если вместо этого сервер детектирует ошибку в команде, посылается отклик завершения bad с меткой, требующей игнорирования команды и предотвращения посылки клиентом каких-либо еще запросов.

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

Протокольный приемник IMAP 4.1 сервера читает строку команды, пришедшей от клиента, осуществляет ее разбор, выделяет ее параметры и передает серверу данные. По завершении команды сервер посылает отклик.

Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс "*" и называются непомеченными откликами.

Данные сервера могут быть посланы в ответ на команду клиента или отправлены сервером по своей инициативе. Формат данных не зависит от причины посылки.

Отклик указывает на успешное выполнение операции или на ее неудачу. Отклик использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (указывает на успешное выполнение), no (отмечает неуспех) или bad (указывает на протокольную ошибку, например, не узнана команда или зафиксирована синтаксическая ошибка).

Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера. Он должен предпринять действия в соответствии с первым символом метки "*" или "+".

Клиент должен быть готов принять любой отклик сервера в любое время. Это касается и не запрошенных данных, присланных сервером. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов.

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

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

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

В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [ IMAP -DISC].

UID ассоциируется с почтовым ящиком и посылается в виде кода uidvalidity отклика (ok) на фазе выбора почтового ящика. Если UID из предыдущей сессии по какой-то причине не может быть использован, UID должен быть инкрементирован.

UID для данного почтового ящика должен всегда изменяться монотонно. Если порядок записей изменен вне рамок IMAP, необходимо перегенерировать UID для данного почтового ящика, так как порядок старых значений UID в этом случае уже не будет монотонным.

Еще одной причиной несохранения UID может служить стирание старого и создание нового почтового ящика с тем же именем. Так как имя почтового ящика не изменилось, клиент может не знать об этом и пытаться использовать старые UID. Хорошим значением UID можно считать 32-битное представление даты и времени создания почтового ящика. Вполне приемлемо и значение 1, если имеется гарантия, что это значение никогда не будет использовано повторно, даже в случае стирания и создания нового почтового ящика с тем же именем.

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

Атрибут порядкового номера сообщения определяет порядковый номер сообщения в почтовом ящике, начиная с 1. Последующее сообщение всегда имеет значение этого атрибута, на 1 большее, чем у предшествующего.

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

Номера сообщений могут использоваться при вычислениях, касающихся указателей. Например, если сообщение 287 в почтовом ящике, содержащем 523 сообщения, имеет UID 12345, существует 286 сообщений с меньшим значением UID и 236 сообщений с большими UID.

Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии.

Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа "\". Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:

Если невозможно определить, является ли эта сессия первой для данного сообщения, его следует считать относящимся к текущей сессии. Ключевое слово определяется реализацией сервера. Ключевые слова не начинаются с символа "\". Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов.

Системный флаг \recent имеет статус флага сессии. Флаг \recent не может использоваться в качестве аргумента команды store и по этой причине не может быть изменен вообще.

Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола SMTP, это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append.

Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, IMAP 4.1 позволяет осуществлять передачу части текста. Можно отдельно доставить заголовок и тело сообщения или даже часть тела сообщения.

Состояние и диаграмма исполнения

Сервер IMAP 4.1 находится в одном из четырех состояний. Большинство команд допустимо только во вполне определенных состояниях. Если клиент пытается реализовать команду в неправильном состоянии, это рассматривается как протокольная ошибка. В этом случае сервер откликнется командой bad или no в зависимости от реализации конкретной программы.

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

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

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

Формат данных

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

Атом состоит из одного или более неспециализированных символов.

Число состоит из одной или более цифр и характеризует некоторое числовое значение.

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

Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных.

Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов, за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой ("). Пустая строка представляется как "" или как литерал {0}, за которым следует последовательность CRLF.

Замечание. Даже если число октетов равно нулю, клиент, передающий литерал, должен подождать прихода команды продолжения.

8-битовая текстовая и двоичная почта поддерживается посредством шифрования [MIME-IMB]. Реализации IMAP 4.1 могут передавать 8-битные или многооктетные символы в литералах, но должны это делать, только когда определен [CHARSET]. Если даже определена кодировка BINARY, незакодированные двоичные строки не могут быть разрешены. Реализации программ должны перекодировать двоичные данные в текстовую форму, такую, как BASE64, прежде чем их пересылать. Строка с несколькими символами CTL может также рассматриваться как двоичная.

Структуры данных представляются в виде списков, помещенных в скобки, элементы списка разделяются пробелами. Такой список может включать в себя другие списки в скобках. Пустой список выглядит как () — список в скобках с нулевым числом членов.

Специальный атом NIL представляет собой указание на отсутствие каких-то определенных данных типа строка или список в скобках. Его следует отличать от пустой строки "" или пустого списка в скобках ().

Операционные соображения

Интерпретация имен почтовых ящиков является не зависящей от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для первичного почтового ящика данного пользователя на данном сервере (значение безразлично к использованию строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо.

В соответствии с соглашением, первый иерархический элемент любого имени почтового ящика, который начинается с символа #, укаывает на пространство имен остальной части имени. Например, реализации, которые предлагают доступ к группам новостей USENET, могут использовать пространство имен #news, чтобы отделить пространство имен групп новостей от имен других почтовых ящиков. Таким образом, группа новостей comp.mail.misc будет иметь имя почтового ящика #news. comp.mail.misc, а имя comp.mail.misc может относиться к другому объекту (например, к почтовому ящику пользователя).

Согласно договоренности, имена международных почтовых ящиков специфицированы в соответствии с модифицированной версией кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций было устранение следующих проблем, связанных с UTF-7.

В модифицированном UTF-7 печатные символы US-ASCII, за исключением , представляются в исходном виде — то есть, символами со значениями октетов 0x20-0x25 и 0x27-0x7E. Символ (0x26) представляется в виде двухоктетной последовательности "-". Все другие символы (значения октетов 0x00-0x1F, 0x7F-0xFF и все уникодные 16-битовые октеты) представляются в модифицированной кодировке BASE64, с дополнительными видоизменениями из [UTF-7]. Модифицированная BASE64 не должна использоваться для представления любых печатных символов US-ASCII, которые должны представлять самих себя.

Символ применяется для перехода к модифицированной кодировке BASE64, а "-" — для возврата назад к US-ASCII. Все имена начинаются с US-ASCII и должны завершаться US-ASCII (то есть, имя, которое заканчивается уникодным 16-битовым октетом, должно быть завершено символом "-"). Примером может служить имя почтового ящика, в котором смешаны фрагменты текста на английском, японском и китайском языках: ~peter/mail/ZeVnLIqe-/U,BTFw-

В любое время сервер может послать данные, которые клиент не запрашивал. Иногда такое поведение системы является необходимым. Например, агенты, внешние по отношению к серверу, могут положить сообщения в почтовый ящик, изменить флаги сообщения в почтовом ящике (возможен одновременный доступ в почтовый ящик нескольких агентов) или даже удалить сообщения из почтового ящика. Сервер должен автоматически послать уведомление об изменении размера почтового ящика, если такое изменение произошло в процессе выполнения команды. Сервер должен автоматически послать уведомление об изменении флагов сообщений, не требуя соответствующего запроса клиента. Имеются специальные правила для оповещения клиента сервером об удалении сообщений, чтобы избежать ошибок синхронизации (смотри также описание EXPUNGE). Программа клиента должна своевременно фиксировать изменения размера почтового ящика. Она не должна полагаться на то, что любая команда после начального выбора почтового ящика возвращает значение его размера.

Реализациям сервера разрешается посылать непомеченные отклики (за исключением EXPUNGE), если в это время не выполняется ни одной команды. Реализации, которые посылают такие отклики, должны учитывать соображения управления трафиком. В частности, они должны либо (1) проверить, что размер данных не превосходит транспортные возможности, либо (2) использовать неблокирующую запись.

Если сервер имеет таймер выгрузки в случае длительной пассивности, тогда такой таймер должен быть настроен на время, по крайней мере, 30 минут. Получения любой команды от клиента в течение этого периода должно быть достаточно для сброса этого таймера.

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

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

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

Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды, отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной:

FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH

Ниже представлены примеры последовательностей, не требующих ожидания завершения предшествующих инструкций:

FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE

Команды клиента

Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.

Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.

Команда CAPABILITY

Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с IMAP 4.1 в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с AUTH=, указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора blurdybloop могут быть описаны как AUTH=XBLURDYBLOOP, а не XAUTH=BLURDYBLOOP или XAUTH=XBLURDYBLOOP.

Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации.

Пример:

C: abcd CAPABILITY
S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
S: abcd OK CAPABILITY completed

Команда NOOP

Команда NOOP ничего не делает и всегда успешно завершается.

Так как любая команда может прислать немаркированные данные об изменении состояния, команда NOOP может использоваться как периодический запрос нового сообщения или информации об изменении статуса в периоды неактивности. Команда NOOP может также применяться для сброса таймера прерывания сессии сервером из-за отсутствия активности.

Пример:

C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

Команда LOGOUT

Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.

Пример:

C: A023 LOGOUT
S: * BYE IMAP 4.1 Server logging out
S: A023 OK LOGOUT completed
(Сервер и клиент разорвали соединение)

Команды клиента в состоянии без аутентификации

В состоянии без аутентификации команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.

Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени anonymous. Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.

По завершении аутентификации невозможно вернуться непосредственно в состояние без аутентификации. В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии без аутентификации возможны команды: AUTHENTICATE и LOGIN.

Команда AUTHENTICATE

Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [ IMAP -AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.

Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.

Механизм защиты обеспечивает целостность и конфиденциальность соединения. Если механизм защиты согласован, то в дальнейшем он используется для всех сообщений, проходящих через данное соединение. Механизм защиты начинает действовать сразу после ввода последовательности CRLF, которая завершает аутентификационный обмен для клиента, и прихода CRLF маркированного отклика OK сервера. Раз механизм защиты вступил в силу, поток октетов команд и откликов заносится в буферы шифрованного текста. Каждый буфер передается через соединение в виде потока октетов, который начинается с четырех октетов, содержащих длину последующих данных. Максимальный размер буфера для текста-шифра определяется выбранным механизмом защиты.

Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант.

Команда LOGIN

Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом.

Пример:

C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed

Команды клиента в состоянии "аутентификация осуществлена"

В состоянии "аутентификация осуществлена" разрешены команды манипуляции почтовыми ящиками как объектами-атомами. Команды SELECT и EXAMINE реализуют выбор почтового ящика и переход в состояние "выбрано".

В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "аутентификация осуществлена" допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND.

Команда SELECT

Команда SELECT осуществляет выбор почтового ящика, так, чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные:

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

Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить.

Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом [READ-WRITE].

Если клиенту не позволено модифицировать почтовый ящик, но разрешен доступ для чтения, почтовый ящик выбирается в режиме только для чтения и сервер должен перед посылкой текста передать маркированный отклик OK в ответ на команду SELECT с кодом отклика [READ-ONLY]. Доступ "только для чтения", тем не менее, отличается от команды EXAMINE, при нем некоторые почтовые ящики позволяют изменять постоянное состояние отдельных флагов пользователя. Сетевые новости из файла .newsrc являются примером того, как некоторые состояния могут изменяться для почтовых ящиков типа "только для чтения".

Пример:

C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed

Команда EXAMINE

Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется "только для чтения". Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика [READONLY].

Команда CREATE

Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем существующего почтового ящика является ошибкой. Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO.

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

Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE. Другими словами, попытка создания foo/bar/zap на сервере, для которого символ "/" является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали.

Когда новый почтовый ящик создан с именем стертого почтового ящика, то его идентификатор должен быть больше использованного его предшественником, если только новая версия ящика не имеет другого значения UID.

Пример:

C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed

Замечание: интерпретация этого примера зависит от того, является ли символ "/" иерархическим сепаратором. Если "/" — иерархический сепаратор, создается новый иерархический уровень owatagusiam с новым членом иерархии этого уровня blurdybloop. В противном случае создаются два почтовых ящика на одном и том же уровне иерархии.

Команда DELETE

Команда DELETE навечно удаляет почтовый ящик с указанным именем. При этом присылается маркированный отклик OK только в том случае, когда ящик уничтожен. Ошибкой считается попытка стереть INBOX или ящик с несуществующим именем.

Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая. Например, если почтовый ящик foo имеет иерархическую структуру foo.bar (предполагается, что "." является иерархическим сепаратором), удаление foo не должно удалять foo.bar. Считается ошибкой попытка удаления имени, которому соответствуют нижележащие иерархические уровни, имеющие атрибут \Noselect.

Разрешено удалять имена, которым соответствуют нижележащие иерархические уровни, не имеющие атрибута имени \Noselect. В этом случае все сообщения из этого почтового ящика также будут удалены, а имя получит атрибут \Noselect.

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

Команда RENAME

Команда RENAME изменяет имя почтового ящика. Маркированный отклик OK присылается лишь в случае, когда почтовый ящик переименован. Считается ошибкой попытка переименовать несуществующий почтовый ящик или присвоить ящику уже имеющееся имя. Любая ошибка при переименовании вызовет маркированный отклик NO.

Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование foo в zap переименует foo/bar (предполагая, что "/" является иерархическим разделителем) в zap/bar.

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

Переименование INBOX разрешено, но имеет свою специфику. Оно перемещает все сообщения в почтовый ящик с новым именем, оставляя INBOX пустым. Если реализация сервера поддерживает иерархические системы имен INBOX, это никак не сказывается на переименовании INBOX.

Команда SUBSCRIBE

Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку активных или подписных ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки.

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

Замечание: это требование возникает потому, что некоторые серверы могут удалить почтовый ящик с известным именем, например, systemalerts, после того как срок годности его содержимого истек, с тем, чтобы создать его вновь при появлении новых сообщений.

Команда UNSUBSCRIBE

Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка активных или подписных почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно.

Команда LIST

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

Команда LIST должна возвращать данные быстро, без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут.

Аргумент, содержащий пустую строку образца имени (""), указывает, что имя почтового ящика интерпретируется так же, как это делает команда SELECT. Присланные имена почтовых ящиков должны соответствовать полученному шаблону имени. Непустой аргумент является шаблоном имени почтового ящика или уровня иерархии и указывает на контекст, в котором интерпретируется имя. Пустой аргумент имени ("") представляет собой специальный запрос, требующий присылки иерархического разделителя и корневого имени. Значение, возвращаемое в качестве корневого имени, может быть нулем, если шаблону не соответствует никакая иерархия. Иерархический разделитель присылается во всех случаях. Это позволяет клиенту получить иерархический разделитель даже в случае, когда нет почтовых ящиков, соответствующих данному имени.

Шаблон и имя почтового ящика интерпретируются по-разному в зависимости от реализации. В каноническом варианте анализ происходит слева направо.

Любая часть аргумента шаблона, которая включена в интерпретированную форму, должна предшествовать интерпретированной форме. Она должна иметь тот же формат, что и аргумент шаблона имени. Это правило позволяет клиенту определить, соответствует ли присланное имя почтового ящика контексту шаблона. Без этого правила клиент должен был бы знать семантику имен сервера.

Ниже приведены некоторые примеры того, как могут интерпретироваться образцы и имена почтовых ящиков на серверах базирующихся на UNIX:

Первые три примера демонстрируют интерпретацию в контексте аргумента шаблона. Заметьте, что ~smith/Mail не должно преобразоваться во что-то подобное /u2/users/smith/Mail, иначе для клиента было бы невозможно определить, соответствовала ли интерпретация контексту шаблона.

Символ "*" представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ "%" подобен "*", но он не соответствует иерархическому разделителю. Если символ "%" является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера, таким образом, позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard). Например, сервер на основе UNIX может ограничить интерпретацию "*" так, что начальный символ "/" будет приводить к несоответствию имени шаблону.

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

Команда LSUB

Команда LSUB возвращает субнабор имен из списка, который пользователь, декларировал как активный или подписной. При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.

Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если именя не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа, даже если ящика с таким именем более не существует.

Команда STATUS

Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности, команда STATUS не должна вызывать потерю флага \Recent).

Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении.

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

Команда APPEND

Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.

Если специфицировано date_time, в результирующем сообщении должна быть установлена внутренняя дата, в противном случае, внутренняя дата и время результирующего сообщения будут установлены по умолчанию равными текущим значениям. Если команда append по какой-то причине не прошла, почтовый ящик должен быть возвращен в состояние, которое он имел до команды APPEND.

Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не создавать автоматически новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика [TRYCREATE] в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND.

Если в настоящее время почтовый ящик выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS. Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK).

Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [ SMTP ].

Команды клиента в состоянии выбор сделан

В состоянии выбор сделан разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.

Команда CHECK

Команда CHECK осуществляет проверку выбранного почтового ящика. Проверка относится к любым характеристикам, зависящим от реализации (например, выявление положения почтового ящика в памяти сервера и на диске). Если сервер не поддерживает таких возможностей, команда эквивалентна NOOP.

Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK.

Команда CLOSE

Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние "аутентификация выполнена". Никакого немаркированного отклика EXPUNGE не посылается.

Никаких сообщений не удаляется и никаких флагов ошибки не возвращается, если почтовый ящик был выбран командой EXAMINE или находился в режиме "только для чтения".

Даже если почтовый ящик выбран, команды SELECT, EXAMINE или LOGOUT могут быть использованы без предварительного исполнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT безоговорочно закрывают выбранный в данный момент почтовый ящик без удаления сообщений. Однако когда удалено много сообщений, последовательность CLOSE-LOGOUT или CLOSE-SELECT значительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, так как здесь не посылается никаких немаркированных откликов EXPUNGE (которые клиент, вероятно, проигнорирует).

Команда EXPUNGE

Команда EXPUNGE навечно удаляет из выбранного почтового ящика все сообщения, которые помечены флагами \Deleted. Прежде чем выдать клиенту сигнал OK, посылается немаркированный отклик EXPUNGE для каждого из удаляемых сообщений.

Пример:

C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed

Замечание: в этом примере сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются.

Команда SEARCH

Команда SEARCH ищет почтовый ящик, который отвечает выбранным критериям отбора. Критерий отбора состоит из одного или более ключей поиска. Немаркированный отклик SEARCH от сервера содержит список номеров сообщений, которые соответствуют критериям отбора.

Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающая заданным критериям. Например, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994.

Опционная спецификация [CHARSET] состоит из слова "CHARSET", за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII. US-ASCII должно поддерживаться всегда, но могут применяться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD).

Для всех ключей поиска, которые используют строки, сообщение соответствует ключу, если строка является частью строки поля в сообщении. Соответствие не должно зависеть от набора строчными или прописными символами. Стандартными ключами поиска являются следующие слова и выражения (таблица 1.11).

Пример:

C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed

Команда FETCH

Команда FETCH извлекает данные, соответствующие сообщению в почтовом ящике. В качестве доставляемых данных может выступать отдельный атом или список элементов, помещенных в скобки. В настоящее время определены следующие типы данных, которые могут быть доставлены:

ALL: Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
BODY: Нерасширяемая форма BODYSTRUCTURE.
BODY[<section>]<< partial >>

BODY — текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен:

HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT.

Пустая спецификация относится ко всему сообщению, включая заголовок. Каждое сообщение имеет номер, по крайней мере, одной части.

Сообщения не-[MIME-IMB] и несоставные сообщения [MIMEIMB] без инкапсуляции имеют только часть 1.

Частям составных сообщений присваиваются последовательные номера в порядке появления. Если конкретная часть является составным сообщением, то его части должны быть выделены точкой, за которой следует номер части.

Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT]MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка. Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях вставляется разграничивающая пустая строка между заголовком и телом сообщения.

Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей:

HEADER ([RFC-822] заголовок сообщения)
TEXT MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.HEADER ([RFC-822] заголовок сообщения)
3.TEXT ([RFC-822] текстовое тело сообщения)
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/MIXED
4.1 IMAGE/GIF
4.1.MIME ([MIME-IMB] заголовок для IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2.HEADER ([RFC-822] заголовок сообщения)
4.2.TEXT ([RFC-822] текстовое тело сообщения)
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT

Имеется возможность доставить субстроку определенного текста. Это делается путем присоединения к спецификатору требующейся части открытой угловой скобки ("<"), положения первого нужного октета, точки, максимального требуемого числа октетов и закрывающей угловой скобки. Если начальный октет находится за пределами текста, возвращается пустая строка.

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

Замечание: это означает, что запрос BODY[]<0.2048> сообщения длиной 1500 октетов пришлет BODY[]<0> с литералом размером 1500, а не BODY[].

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

Команда STORE

Команда STORE заносит данные в почтовый ящик. В нормальной ситуации команда STORE возвращает обновленную версию данных с немаркированным откликом FETCH. Суффикс .SILENT в имени информационного элемента блокирует немаркированный отклик FETCH, и сервер должен предполагать, что клиент определил обновленное значение сам или ему обновленное значение не нужно.

Замечание: вне зависимости от того используется или нет суффикс .SILENT, сервер должен послать немаркированный отклик FETCH, если внешние причины вызвали изменение флагов сообщения.

В настоящее время определены следующие элементы данных.

Пример:

C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH FLAGS (\Deleted\Seen)
S: * 3 FETCH FLAGS (\Deleted)
S: * 4 FETCH FLAGS (\Deleted\Flagged \Seen)
S: A003 OK STORE completed

Команда COPY

Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика. Флаги и внутренняя дата сообщения должны быть сохранены в копии.

Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика [TRYCREATE] в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.

Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик в состояние, которое он имел до выполнения COPY.

Пример:

C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed

Команда UID

Команда UID имеет две формы. В первой она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений.

Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению набора порядковых номеров сообщений 1:100 и набора UID 443:557.

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

Число после "*" в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID. Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH.

Пример:

C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed

Отклики сервера

Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:".

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

Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также незапрашиваемыми данными.

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

Прочие данные сервера следует записывать для последующих ссылок; но если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться.

Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии выбрано. В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В нормальной ситуации эта часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.

Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.

Отклики сервера — отклики состояния

Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE — всегда не маркированы.

Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента, помимо условий OK/NO/BAD. Эти данные определяют, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время заданы следующие коды откликов.

Отклик OK

Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.

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

Отклик NO

Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.

Отклик BAD

Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка определяет команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера. Текстовое сообщение описывает условия.

Отклик PREAUTH

Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация и команда LOGIN не нужна.

Отклик BYE

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

Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта) заключается в том, что соединение в последнем случае разрывается немедленно.

Отклики сервера — сообщения о состоянии сервера и почтового ящика

Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя.

Отклик CAPABILITY

Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, который содержится в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом IMAP 4.1.

Имя возможности, которое начинается с AUTH=, указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1.

Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".

Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от IMAP 4.1, они должны игнорировать неизвестные имена возможностей.

Отклик LIST

Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду. Определено четыре атрибута имени.

Если сервер не может определить, является ли почтовый ящик интересным, или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.

Имя представляет собой однозначную иерархию слева-направо и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд типа SELECT, которые требуют ввода имени почтового ящика.

Пример: S: * LIST (\Noselect) "/" ~/Mail/foo

Отклик LSUB

Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.

Пример: S: * LSUB () "." #news.comp.mail.misc

Отклик STATUS

Отклик STATUS является результатом выполнения команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.

Пример: S: * STATUS spam_mess (MESSAGES 315 UIDNEXT 52111)

Отклик SEARCH

Отклик SEARCH является результатом выполнения команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH — их уникальные идентификаторы. Числа отделяются друг от друга пробелами.

Пример: S: * SEARCH 1 2 3

Отклик FLAGS

Отклик FLAGS является результатом выполнения команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, — это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.

Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

Отклик EXISTS

Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом выполнения команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.

Пример: S: * 23 EXISTS

Отклик RECENT

Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом выполнения команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).

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

Корректным способом идентифицировать последние сообщения является рассмотрение флагов \Recent или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.

Пример: S: * 5 RECENT

Отклик EXPUNGE

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

Порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи снизу-вверх, пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи сверху вниз, пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.

Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера. Информация отклика EXPUNGE должна записываться клиентом.

Пример: S: * 44 EXPUNGE

Отклик FETCH

Отклик FETCH возвращает данные о сообщении клиенту. Данные объединяются в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера, например, об изменении флагов. В настоящее время существуют следующие информационные элементы:

BODY Форма BODYSTRUCTURE без расширения данных.
BODY[<section>]<<origin_octet>>

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

Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[ ]<0> может быть укорочено, но BODY[ ] никогда не укорачивается.

Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.

Нетекстовые данные, такие, как двоичные, должны передаваться закодированными в текстуальном формате, например, BASE64. Чтобы получить исходные двоичные данные, клиент должен декодировать полученную последовательность.

BODYSTRUCTURE — список, заключенный в скобки, который описывает [MIME-IMB], и структура тела сообщения.

Эта структура формируется сервером путем разбора полей заголовка [MIME-IMB] и подстановки при необходимости значений по умолчанию.

Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: (TEXT PLAIN (CHARSET US-ASCII) NIL NIL 7BIT 2279 48)

Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой. Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).

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

Список параметров тела, заключенный в скобки.

Список содержит пары атрибут/значение [например, (foo bar baz rag), где bar представляет собой значение foo, а rag является значением baz] как это определено в [MIME-IMB].

Размещение тела

Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.

Язык тела

Строка или список в скобках, определяющие язык, так, как это задано в [LANGUAGE-TAGS].

Тип тела

Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].

Субтип тела

Строка, описывающая имя субтипа, как это определено в [MIMEIMB].

Список параметров тела, заключенный в скобки

Список пар атрибут/значение, заключенный в скобки, [например, (foo bar baz rag), где bar является значением foo, а rag — значением baz], как это описано в [MIME-IMB].

Идентификатор тела

Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].

Описание тела

Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].

Шифрование тела

Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].

Размер тела

Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным.

Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.

Тип тела TEXT сразу после базовых полей содержат размер тела в строках. Заметьте, что этот размер отражает размер фрагмента после выполнения транспортного кодирования.

Данные расширения следуют после базовых полей и полей, перечисленных выше. Указанные расширения никогда не транспортируются при передаче тела, но могут быть пересланы при доставке BODYSTRUCTURE. Данные расширения, если они присутствуют, должны быть упорядочены.

Эти расширения для несоставной части тела располагаются в следующем порядке.

MD5 тела

Строка, содержащая значение MD5 тела, как это описано в [MD5].

Размещение тела

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

Язык тела

Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].

ENVELOPE — список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения. Он формируется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.

Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.

Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [ SMTP ] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.

Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.

Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from. Кроме того, определены следующие информационные объекты.

Отклики сервера — запрос продолжения команды

Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.

Этот отклик используется командой AUTHORIZATION, чтобы передать данные от сервера клиенту и запросить дополнительные данные у клиента. Этот отклик применяется также, если аргументом какой-то команды является литерал.

Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.