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

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

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.

1. UTF-7 использует символ "+" для смещения; это вызывает конфликт с обычным применением "+" в именах почтовых ящиков, в частности, в именах групп новостей USENET.
2. Кодировка UTF-7 базируется на BASE64, где используется символ "/", что вступает в конфликт с применением "/" в качестве популярного иерархического разделителя.
3. UTF-7 запрещает использование "\"; что противоречит применению "\" в качестве популярного разделителя.
4. UTF-7 запрещает использование "~", это вступает в конфликт с тем, что некоторые серверы рассматривают этот символ как указатель на базовый каталог (home).
5. UTF-7 допускает разнообразные формы представления одних и тех же строк, в частности, печатные символы US-ASCII могут использоваться в закодированной форме.

В модифицированном 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