| Сети. Протокол Интернет для работы с сообщениями IMAP | |
|
|
| |
|
Протокол Интернет для работы с сообщениями IMAP
Протокол IMAP 4.1 (INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1, V.Crispin, RFC-2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143. Протокол IMAP представляет собой альтернативу POP-3. Также как и последний он работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.
Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.
1.1 Протокольный отправитель клиента и протокольный получатель сервера
Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например A0001, A0002 и т.д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку. Имеется два случая, когда строка, посланная клиентом, не представляет собой законченную команду. В первом - аргумент команды снабжается кодом, определяющим число октетов в строке (см. описание литеральных строк в разделе “Форматы данных”). Во втором - аргументы команды требуют отклика со стороны сервера (см. описание команды authenticate). В обоих вариантах сервер посылает запрос продолжения команды, если он готов. Такой отклик сервера начинается с символа "+". Отправитель может послать отклик завершения и в случае некоторых других команд (если одновременно исполняется несколько команд) или если данные не имеют меток. В любом случае, ожидается запрос продолжения, клиент предпринимает в ответ соответствующие действия и читает следующий отклик сервера. Во всех вариантах клиент должен завершить отправку одной команды прежде чем послать новую. Протокольный приемник IMAP 4.1 сервера читает строку команды, пришедшей от клиента, осуществляет ее разбор, выделяет ее параметры и передает серверу данные. По завершении команды сервер посылает отклик.1.2 Протокольный отправитель сервера и протокольный получатель клиента
Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс "*" и называются непомеченными откликами. Данные сервера могут быть посланы в ответ на команду клиента или отправлены сервером по своей инициативе. Формат данных не зависит от причины посылки.Отклик указывает на успешное выполнение операции или на ее неудачу. Отклик использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (указывает на успешное выполнение), no (отмечает неуспех) или bad (указывает на протокольную ошибку, например, не узнана команда или зафиксирована синтаксическая ошибка).
Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера. Он должен предпринять действия, в соответствии с первым символом метки "*" или "+".
Клиент должен быть готов принять любой отклик сервера в любое время. Это касается и не запрошенных данных, присланных сервером. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов.
Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами.
Каждому сообщению ставится в соответствие 32-битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Сообщения, приходящие позднее имеют больший код UID, чем полученные ранее.
В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [IMAP-DISC].
UID ассоциируется с почтовым ящиком и посылается в виде кода uidvalidity отклика (ok) на фазе выбора почтового ящика. Если UID из предыдущей сессии по какой-то причине не может быть использован, UID должен быть инкрементирован.
UID сообщения не должно изменяться в пределах сессии, его не следует изменять и от сессии к сессии. Однако если невозможно сохранить UID сообщения в последующей сессии, каждая следующая сессия должна иметь новый уникальный код идентификатора, который больше чем любой UID использованный ранее.
Атрибут порядкового номера сообщения
Этот атрибут определяет порядковый номер сообщения в почтовом ящике, начиная с 1. Последующее сообщение всегда имеет значение этого атрибута на 1 большее, чем у предшествующего.
Допускается изменение порядкового номера сообщения на протяжении сессии. Например, когда сообщение удаляется из почтового ящика, номера всех последующих сообщений изменяются. Аналогично, новому сообщению может быть присвоен номер удаленного сообщения.
Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии.
Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа "\". Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:
| \seen | Сообщение прочитано |
| \answered | На сообщение послан ответ |
| \flagged | Сообщение "помечено" как срочное, требующее особого внимания |
| \deleted | Сообщение помечено как стертое для последующего удаления посредством expunge |
| \draft | Сообщения не является законченным (помечено, как проект). |
| \recent | Сообщение только что положено в почтовый ящик. Эта сессия является первой, где фигурирует данное сообщение; для последующих сессий это сообщение не будет иметь флага \recent. Флаг не может быть изменен клиентом. |
Если невозможно определить, является ли эта сессия первой для данного сообщения, его следует считать относящимся к текущей сессии. Ключевое слово определяется реализацией сервера. Ключевые слова не начинаются с символа "\". Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов.
Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола [SMTP], это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append.
Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, доставить заголовок и тело сообщения или даже часть тела сообщения.
2. Состояние и диаграмма исполнения
Сервер IMAP 4.1 находится в одном из четырех состояний. Большинство команд допустимо только во вполне определенных состояниях. Если клиент пытается реализовать команду в неправильном состоянии, это рассматривается как протокольная ошибка. В этом случае сервер откликнется командой bad или no в зависимости от реализации конкретной программы.
В состоянии без аутентификации клиент должен предоставить имя и пароль, прежде чем станет доступно большинство команд. Переход в это состояние производится при установлении соединения, если только для данного соединения не была проведена предварительная аутентификация.
В состоянии аутентификации клиент идентифицирован и должен выбрать почтовый ящик, прежде чем ему станут доступны команды для работы с сообщениями. Переход в это состояние происходит при установлении соединение с предварительной аутентификацией, когда выданы все необходимые идентификационные данные или при ошибочном выборе почтового ящика.
В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика. В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.
IMAP 4.1 использует текстовые команды и отклики. Данные в IMAP 4.1 могут иметь одну из следующих форм: атом, число, строка, список, заключенный в скобки или NIL.
Атом состоит из одного или более неспециализированных символов.
Число состоит из одной или более цифр и характеризует некоторое числовое значение.
Строка может иметь одну из двух форм: литерал или строка в кавычках. Литеральная форма является основной формой строки. Строка в кавычках является альтернативной формой, исключающей избыточность литеральной формы за счет ограничений, налагаемых на символы, используемые в строке.
Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных.
Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой (<">). Пустая строка представляется как "" или как литерал {0}, за которым следует последовательность CRLF.
Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.
4.1. Команды клиента - любое состояние
Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.
Аргументы: отсутствуют.
Отклики: Необходим немаркированный отклик: CAPABILITY.
Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с "IMAP 4.1" в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с "AUTH=" указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора "blurdybloop" могут быть описаны как "AUTH=XBLURDYBLOOP", а не "XAUTH=BLURDYBLOOP" или "XAUTH=XBLURDYBLOOP".
Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации.
Аргументы: отсутствуют.
Отклики: никакого специального отклика на эту команду не требуется.
Команда NOOP ничего не делает и всегда успешно завершается.
Так как любая команда может прислать немаркированные данные об изменении состояния, команда NOOP может использоваться, как периодический запрос нового сообщения или информации об изменении статуса в периоды неактивности. Команда NOOP может также использоваться для сброса таймера прерывания сессии сервером из-за отсутствия активности.
Аргументы: отсутствуют.
Отклики: необходим немаркированный отклик BYE.
Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.
4.2. Команды клиента - в состоянии без аутентификации
В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.
Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени "anonymous". Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.
По завершении аутентификации невозможно вернуться непосредственно в состояние “без аутентификации”. В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии “без аутентификации” возможны команды: AUTHENTICATE и LOGIN.
Аргументы: имя механизма аутентификации.
Отклики: может быть запрошена дополнительная информация.
Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.
Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.
Аргументы: имя пользователя, пароль.
Отклики: команда не требует какого-либо специального отклика.
Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом.
4.3. Команды клиента в состоянии "аутентификация осуществлена"
В состоянии "аутентификация осуществлена" разрешены команды манипуляции почтовыми ящиками, как объектами-атомами. Команды SELECT и EXAMINE реализует выбор почтового ящика и переход в состояние "выбрано" .
В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии "аутентификация осуществлена" допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND.
Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.
Команда SELECT осуществляет выбор почтового ящика, так чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные:
FLAGS - флаги, определенные для почтового ящика.
OK [UIDVALIDITY
Сервер должен также послать "невидимый" код отклика внутри немаркированного сообщения OK, который представляет собой порядковый номер первого невидимого сообщения в почтовом ящике.
Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить.
Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом "[READ-WRITE]".
Аргументы: имя почтового ящика.
Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.
Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется как "только для чтения". Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика "[READ-ONLY]".
Аргументы: имя почтового ящика.
Отклики: на эту команду не посылается каких-либо откликов.
Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем, существующего почтового ящика, является ошибкой . Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO.
Если имя почтового ящика имеет суффикс с символом сепаратора иерархии сервера (в соответствии с тем, что получено при выполнении команды LIST), то это является декларацией клиента о намерении создать почтовый ящик с именем в рамках указанной иерархии. Реализации сервера, которые не требуют этой декларации, должны ее игнорировать.
Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE. Другими словами, попытка создания "foo/bar/zap" на сервере, для которого символ "/" является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали.
Аргументы: имя почтового ящика.
Отклики: команда не требует каких-либо откликов.
Результат: OK - команда завершена;
NO - ошибка при выполнении команды: не удается стереть ящик с этим именем;
BAD - команда неизвестна или неверен аргумент.
Команда DELETE навечно удаляет почтовый ящик с указанным именем. При этом присылается маркированный отклик OK только в том случае, когда ящик уничтожен. Ошибкой считается попытка стереть INBOX или ящик с несуществующим именем.
Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая.
Аргументы: имя существующего почтового ящика, имя нового почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Команда RENAME изменяет имя почтового ящика. Маркированный отклик OK присылается лишь в случае, когда почтовый ящик переименован. Считается ошибкой попытка переименовать не существующий почтовый ящик или присвоить ящику уже имеющееся имя. Любая ошибка при переименовании вызовет маркированный отклик NO.
Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование "foo" в "zap" переименует "foo/bar" (предполагая, что "/" является иерархическим разделителем) в "zap/bar".
Значение наибольшего использованного уникального идентификатора имени старого почтового ящика должно быть сохранено, так чтобы новый создаваемый с тем же именем почтовый ящик не использовал идентификатора своего предшественника, если только он не имеет другого значения UID.
Переименование INBOX разрешено, но имеет свою специфику. Оно перемещает все сообщения в почтовый ящик с новым именем, оставляя INBOX пустым. Если реализация сервера поддерживает иерархические системы имен INBOX, это никак не сказывается на переименовании INBOX.
Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Результат: OK - процедура подписки завершена;
NO - подписка не прошла: подписка для данного имени невозможна;
BAD - команда неизвестна или неверен аргумент.
Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку "активных" или "подписных" ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки.
Сервер может проверить аргумент команды SUBSCRIBE, чтобы проконтролировать его корректность для данного почтового ящика. Однако он не должен в одностороннем порядке удалять существующее имя почтового ящика из подписного листа, даже если ящика с таким именем более не существует.
Аргументы: имя почтового ящика.
Отклики: эта команда не требует каких-либо специфических откликов.
Результат: OK - ликвидация подписки прошла успешно;
NO - ликвидация подписки не прошла: это невозможно для данного имени;
BAD - команда неизвестна или неверен аргумент.
Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка "активных" или "подписных" почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно.
Аргументы: имя,
имя почтового ящика может содержать символы подмены (wildcard).
Отклики: немаркированные отклики LIST.
Команда LIST возвращает субнабор имен из полного набора, доступного клиенту. Присылается нуль или более немаркированных откликов LIST, содержащих атрибуты имен, иерархические разделители и имена.
Команда LIST должна возвращать данные быстро без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут.
Аргумент, содержащий пустую строку образца имени (""), указывает, что имя почтового ящика интерпретируется также, как это делает команда SELECT. Присланные имена почтовых ящиков должны соответствовать полученному шаблону имени. Непустой аргумент является шаблоном имени почтового ящика или уровеня иерархии и указывает на контекст, в котором интерпретируется имя. Пустой аргумент имени ("") представляет собой специальный запрос, требующий присылки иерархического разделителя и корневого имени. Значение, возвращаемое в качестве корневого имени, может быть нулем, если шаблону не соответствует никакая иерархия. Иерархический разделитель присылается во всех случаях. Это позволяет клиенту получить иерархический разделитель даже в случае, когда нет почтовых ящиков, соответствующих данному имени..
Любая часть аргумента шаблона, которая включена в интерпретированную форму, должна предшествовать интерпретированной форме. Она должна иметь тот же формат, что и аргумент шаблона имени. Это правило позволяет клиенту определить, соответствует ли присланное имя почтового ящика контексту шаблона. Без этого правила, клиент должен был бы знать семантику имен сервера.
Ниже приведены некоторые примеры того, как могут интерпретироваться образцы и имена почтовых ящиков на серверах базирующихся на UNIX:
| Шаблон | Имя почтового ящика | Интерпретация |
| ~smith/Mail/ | foo.* | ~smith/Mail/foo.* |
| Archive/ | % | archive/% |
| #news. | comp.mail.* | #news.comp.mail.* |
| ~smith/Mail/ | /usr/doc/foo | /usr/doc/foo |
| archive/ | ~fred/Mail/* | ~fred/Mail/* |
Символ "*" представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ "%" подобен "*", но он не соответствует иерархическому разделителю. Если символ "%" является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера таким образом позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard).
Аргументы: имя-шаблон,
имя почтового ящика может содержать символы подмены (wildcards).
Отклики: немаркированный отклик: LSUB
Команда LSUB возвращает субнабор имен из списка пользователя, который декларирован как "активный" или "подписной". При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.
Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует.
Аргументы: имя почтового ящика, статусная информация имен.
Отклики: немаркированные отклики: STATUS.
Результат: OK - команда успешно выполнена;
NO - команда не прошла: нет статусной информации для данного имени;
BAD - команда неизвестна или неверен аргумент.
Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности команда STATUS не должна вызывать потерю флага \Recent).
Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении.
В отличии от команды LIST, команда STATUS не гарантирует быстрого отклика. В некоторых реализациях сервер обязан открыть почтовый ящик в режиме "только чтение", чтобы получить нужные статусные данные. Кроме того, команда STATUS не допускает символов подмены в шаблоне имени. В настоящее время определены следующие статусные данные, которые могут быть запрошены:
| MESSAGES | Число сообщений в почтовом ящике |
| RECENT | Число сообщений с установленным флагом \Recent |
| UIDNEXT | Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантируется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже если оно после этого стерто. |
| UIDVALIDITY | Уникальный валидатор почтового ящика |
| UNSEEN | Число сообщений, не имеющих установленного флага \Seen |
Аргументы: имя почтового ящика,
опционно - флаг списка со скобками,
опционно - строка даты и времени,
литерал сообщения
Отклики: команда не требует какого-либо специального отклика
Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.
Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:".
Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде.
Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также "незапрашиваемыми данными".
Определенные данные от сервера должны записываться клиентом при получении. Такие данные несут критическую информацию, которая влияет на интерпретацию всех последующих команд и откликов (например, создание или уничтожение сообщений).
Прочие данные сервера следует записывать для последующих ссылок, если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться.
Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии "выбрано". В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.
Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.
5.1. Отклики сервера - отклики состояния
Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE - всегда не маркированы.
Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:
| ALERT | Текстовое сообщение, содержащее специальное предупреждение, которое должно быть представлено пользователю в форме, привлекающей внимание. |
| NEWNAME | За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика. |
| PARSE | Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике. |
| PERMANENTFLAGS | Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике. |
| READ-ONLY | Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only. |
| READ-WRITE | Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write. |
| TRYCREATE | Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE |
| UIDVALIDITY | Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора. |
| UNSEEN | Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen. |
Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс "X", если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются.
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.
Немаркированная форма используется также как один из трех видов оповещения об установлении начального соединения. Эта форма указывает, что еще не выполнена аутентификация и необходима команда LOGIN.
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка отмечает команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера. Текстовое сообщение описывает условия.
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация, и команда LOGIN не нужна.
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:
Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT.
Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение.
Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение.
Как одно из трех возможных сообщений при установлении соединения, уведомляя, что сервер не может установить соединение с данным клиентом. Сервер немедленно разрывает соединение.
Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.
5.2. Отклики сервера - сообщения о состоянии сервера и почтового ящика
Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя.
Содержимое: список воз.
Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.
Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".
Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей.можностей.
Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1"
Содержимое: атрибуты имени, иерархический разделитель, имя.
Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.
Определено четыре атрибута имени:
| \Noinferiors | Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем. |
| \Noselect | Не допускается использование данного имени для именования почтового ящика, который может быть выбран. |
| \Marked | Почтовый ящик помечен сервером как "interesting"; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран. |
| \Unmarked | Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран. |
Если сервер не может определить, является ли почтовый ящик "интересным", или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.
Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.
Содержимое: атрибуты имени, иерархический разграничитель, имя.
Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.
Содержимое: имя, статусный список, заключенный в скобки.
Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.
Содержимое: нуль или более чисел.
Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH - их уникальные идентификаторы. Числа отделяются друг от друга пробелами.
Содержимое: список флагов, заключенный в скобки.
Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.
Последующее является записью для соединения IMAP 4.1.
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin"
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {350}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray gray@cac.washington.edu
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin KLENSIN@INFOODS.MIT.EDU
S: Message-Id: B27397-0100000@cac.washington.edu
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed