Network Working Group Request for Comments: 2060 Obsoletes: 1730 Category: Standards Track
M. Crispin
University of Washington
December 1996
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Протокол IMAP v.4, rev. 1
Статус документа
Этот документ содержит предлагаемый стандарт протокола (standards track protocol) для сообщества Internet и являет­ся запросом к обсуждению в целях развития стандарта. Информацию о текущем состоянии стандартизации протокола можно найти в Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.
Тезисы
Протокол IMAP4rev1 (Internet Message Access Protocol, Version 4rev1) обеспечивает клиентам возможность доступа и манипуляций с почтовыми сообщениями на сервере. IMAP4rev1 разрешает манипуляции с удаленными папками со­общений, называемыми почтовыми ящиками (mailboxes), как с локальными почтовыми ящиками. IMAP4rev1 также позволяет offline-клиентам синхронизировать почтовые ящики с сервером (см. [IMAP-DISC]).
IMAP4rev1 включает операции создания, удаления и переименования почтовых ящиков, проверки наличия новых со­общений, удаления сообщений навсегда, установки и сброса флагов, разбора [RFC-822] и [MIME-IMB]; поиска и се­лективной выборки атрибутов сообщений, текста или их фрагментов. Доступ к сообщениям в IMAP4rev1 обеспечива­ется по номерам сообщений, которые просто присваиваются по порядку или задаются с обеспечением уникальности каждого номера.
Протокол IMAP4rev1 поддерживает один сервер. Механизм настройки конфигурации для поддержки множества сер­веров IMAP4rev1 обсуждается в работе [ACAP].
IMAP4rev1 не поддерживает функций передачи почты, для решения таких задач служат транспортные почтовые про­токолы типа [SMTP].
При разработке IMAP4rev1 учитывалось требование совместимости с [IMAP2] и неопубликованным протоколом IMAP2bis. По мере разработки IMAP4rev1 от некоторых возможностей ранних версий протоколов пришлось отказать­ся. Устаревшие команды, отклики и форматы данных, с которыми реализация IMAP4rev1 может встретиться при ра­боте с ранними версиями, описаны в [IMAP-OBSOLETE]. Другие вопросы совместимости с IMAP2bis (наиболее рас­пространенный вариант ранних протоколов) обсуждаются в работе [IMAP-COMPAT]. Полное рассмотрение вопросов совместимости с редкими (и практически вымершими) вариантами [IMAP2] приводится в [IMAP-HISTORICAL] – этот документ представляет в основном исторический интерес.
4.1. Атом (Atom) ...................................................................................................................................................................................... 6
http://rfc.com.ru                                                                                                                               http://rfc.com.ru
C.  Предметный указатель .......................................................................................................................................................................... 31
http://rfc.com.ru                                                                          2                                                    http://rfc.com.ru
Спецификация протокола IMAP4rev1
1. Как работать с документом
1.1. Структура документа
Этот документ представляет протокол с точки зрения разработчика клиента или сервера IMAP4rev1. Кроме обзора главе 2, документ не содержит каких-либо материалов, помогающих понять работу протокола. Главы 3 - 5 содержат общий контекст и определения, используемые IMAP4rev1.
В главах 6, 7 и 9 описаны команды, отклики и синтаксис, соответственно. Соотношения между ними таковы, что поч­ти невозможно разобраться с протоколом, рассматривая команды, отклики и синтаксис по отдельности. В частности, не следует пытаться вывести синтаксис команд, прочтя лишь их описание – обратитесь к главе, описывающей синтак­сис.
1.2. Используемые соглашения
В примерах обозначения C: и S: показывают строки, передаваемые клиентом и сервером, соответственно. Термины, используемые для обозначения уровня требований, растолкованы ниже.
1. MUST - необходимо
Это слово, а также термины требуется (обязательно) и нужно (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.
2. MUST NOT - недопустимо
Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.
3. SHOULD - следует
Это слово, а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от вы­полнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.
4. SHOULD NOT - не следует
Эта фраза и глагол не рекомендуется (NOT RECOMMENDED) используются применительно к особенностям или функциям, которые допустимы и могут быть полезными, но могут вызывать проблемы. При реализации таких оп­ций следует учитывать возможность возникновения проблем и принимать взвешенное решение.
5. MAY - возможно
Это слово, а также прилагательное необязательный (дополнительно) обозначают элементы, реализация которых является необязательной. Одни разработчики могут включать такие опции в свою продукцию для расширения возможностей, а другие - опускать в целях упрощения. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспе­чиваться за счет некоторого ущерба функциональности). Включающие опцию реализации должны быть готовы (естественно, без использования такой опции) к взаимодействию с реализациями, которые такую опцию не под­держивают. Термин «пользователь» (User) используется для обозначения человека, а слово «клиент» обозначает пользовательские программы.
Термин «соединение» (Connection) описывает всю последовательность операций взаимодействия между клиентом и сервером от момента организации связи и до ее завершения. Термины «сеанс» или «сессия» (Session) обозначают по­следовательность операций обмена между клиентом и сервером с момента выбора почтового ящика (команда SELECT или EXAMINE) и до отмены этого выбора (команда SELECT или EXAMINE для другого почтового ящика, команда CLOSE или разрыв соединения).
Символом будем называть 7-битовый символ из набора US-ASCII, если явно не указано иное. Другие символьные на­боры обозначаются с использованием CHARSET, как описано в [MIME-IMT] и определено в [CHARSET]. Опция CHARSET имеет дополнительную семантику, описанную в вышеупомянутых работах.
2. Обзор
2.1. Канальный уровень
Протокол IMAP4rev1 предполагает наличие гарантированного потока данных (например, от TCP). При использовании транспортного протокола TCP сервер IMAP4rev1 прослушивает порт 143.
2.2. Команды и отклики
Соединение IMAP4rev1 включает организацию связи между клиентом и сервером, стартовое приветствие сервера и операции взаимодействия между клиентом и сервером (команды клиента, данные от сервера, отклики сервера). Все взаимодействие между клиентом и сервером происходит в форме обмена текстовыми строками, завершающимися последовательностью CRLF. Получатель IMAP4rev1 (клиент или сервер) читает строку или последовательность из за­данного числа октетов, следующих за ней.
2.2.1. Передатчик клиента и приемник сервера
Взаимодействие начинается с команды клиента. Каждая команда начинается с префикса-идентификатора (обычно ко­роткая последовательность букв и цифр типа A0001, A0002 и т. п.), называемого тегом (tag). Теги генерируются кли­ентом для каждой команды.
3
Существует два случая, когда строка от клиента не содержит полной команды – в одном случае сопровождаются счетчиком октетов (см. описание String в главе 4. Форматы данных), в другом – аргументы команды требуют отклика от сервера (см. описание команды AUTHENTICATE). В обоих случаях сервер передает в ответ на команду соответст­вующий отклик с запросом продолжения команды (если сервер готов к приему имеющихся у клиента данных и ос­тавшейся части команды) 1. Эти отклики начинаются с префикса "+".
Приемник IMAP4rev1 на сервере читает строку команды от клиента, разбирает ее, отделяя команду от аргументов, и передает серверу, а тот генерирует отклик о завершении команды.
2.2.2. Приемник клиента и передатчик сервера
Данные, передаваемые сервером клиенту и отклики о состоянии, не показывающие завершение команды, передаются с префиксом "*" и называются откликами без пометок (untagged).
Данные от сервера могут передаваться в результате клиентской команды, а могут генерироваться по инициативе сер­вера. Между этими данными нет никакой синтаксической разницы.
Отклик от сервера о завершении команды показывает результат операции. Он помечается тегом клиентской команды, послужившей началом операции. Таким образом, при одновременной обработке множества команд тег в отклике сер­вера позволяет идентифицировать команду, с которой связан отклик. Существуют три варианта откликов о заверше­нии команды - OK (успешное завершение), NO (неудача) и BAD (ошибка протокола – например, нераспознанная ко­манда или некорректный синтаксис).
Приемник IMAP4rev1 у клиента читает строку отклика от сервера и предпринимает в ответ на нее действия, в зависи­мости от префикса в отклике (тег, "*" или "+"). Клиент должен быть постоянно готов к восприятию любых откликов от сервера. Принятые от сервера данные следует записывать, чтобы впоследствии клиент мог обращаться к сохранен­ным данным, не запрашивая их у сервера повторно. В некоторых случаях данные должны записываться. Этот вопрос более подробно рассматривается ниже (см. 7. Отклики сервера).
2.3. Атрибуты сообщения
Кроме текста каждое сообщение содержит набор связанных с ним атрибутов. Эти атрибуты можно отыскивать вместе с текстом сообщения или независимо от него.
2.3.1. Номера сообщений
Доступ к сообщениям IMAP4rev1 обеспечивается по одному из двух номеров – идентификатору сообщения или уни­кальному идентификатору.
2.3.1.1. Уникальный идентификатор сообщения (UID)
32-битовый идентификатор, присваиваемый каждому сообщению и совместно с уникальным идентификатором кор­ректности (см. ниже) образующий 64-битовое значение, для которого гарантируется уникальность в масштабе почто­вого ящика. Уникальные номера для каждого почтового ящика выделяются строго по нарастанию – каждое новое со­общение имеет значение UID, превышающее идентификаторы добавленных ранее сообщений.
В отличие от порядковых номеров уникальные идентификаторы не обязаны следовать непрерывно и сохраняются только в течение одного сеанса. Это позволяет клиенту ресинхронизировать свое состояние по отношению к преды­дущему сеансу (например, для отключенных или сеансовых клиентов). Вопросы синхронизации обсуждаются в рабо­те [IMAP-DISC].
С каждым почтовым ящиком связывается уникальный идентификатор корректности, который передается в коде UIDVALIDITY неотмеченных откликов OK при выборе почтового ящика. Если уникальные идентификаторы из пре­дыдущего сеанса не могут использоваться в данной сессии, новое значение уникального идентификатора корректно­сти должно быть больше, чем использованное в предыдущем сеансе значение.
Note: Значения уникальных идентификаторов для почтового ящика должны строго возрастать. Если физически сообщения сохраняются агентом, отличным от IMAP, в ином порядке или неупорядочены, это требует регенерации уникальных идентификаторов для почтового ящика, поскольку прежние уникальные идентификаторы не будут идти строго по возрастанию в результате изменения порядка. Другим случаем регенерации уникальных идентификаторов являются системы, в которых при хранении сообщений не поддерживается механизм уникальной идентификации. Признавая, что это может быть неприемлемо для некоторых серверных сред, настоящая спецификация настоятельно рекомендует использовать системы хранения сообщений, позволяющие избежать этой проблемы. Другой причиной невозможности использования прежних идентификаторов является случай, когда почтовый ящик удаляется и вместо него позднее создается новый ящик с таким же именем. Поскольку имена ящиков совпадают, кли­ент может не знать о том, что это новый ящик, если уникальные идентификаторы корректности не отличаются. Эф­фективным выходом будет использование в качестве уникальных идентификаторов корректности 32-битовое пред­ставление даты и времени создания почтовых ящиков. Можно использовать и константы (например, 1), если обеспе­чивается невозможность их повторного использования даже в случаях удалением или переименования почтовых ящи­ков с последующим созданием ящика с прежним именем.
Уникальный идентификатор сообщения недопустимо изменять в течение сеанса и не следует менять между сессия­ми. Однако, если для следующего сеанса сохранение уникального идентификатора невозможно, новое значение должно быть больше предыдущего.
1 Если сервер обнаруживает в команде ошибку, он передает соответствующий отклик (BAD completion response) с тегом, соответ­ствующим команде (как описано ниже) для отказа от выполнения команды и предотвращения передачи клиентом продолжения. Сервер может также передавать отклики о завершении некоторых других команд (если обрабатывается множество команд одно­временно) или неотмеченные (untagged) данные. В любом случае запрос н продолжение команды сохраняется и клиент в ответ на этот запрос выполняет соответствующие действия. Во всех случаях клиент должен передать всю команду (включая все отклики на запросы продолжения команды и сами команды продолжения) до инициализации новой команды.
4
2.3.1.2. Порядковый номер сообщения
Относительные номера сообщений (от 1 до текущего числа писем в ящике). Номера должны упорядочиваться в соот­ветствии с увеличением уникальных идентификаторов. При добавлении каждого нового сообщения ему присваивает­ся следующий свободный номер (на 1 больше последнего из использованных номеров).
Порядковые номера сообщений могут изменяться в течение сеанса. Например, при полном удалении письма из ящика порядковые номера всех последующих сообщений уменьшаются.
Кроме идентификации сообщений в смысле доступа к ним, порядковые номера могут использоваться в расчетах. На­пример, при получении неотмеченного отклика EXISTS 11 после того, как был получен неотмеченный отклик 8 EXISTS, позволяет вычислить, что были получены три новых сообщения - 9, 10, 11. Другой пример: если сообщение с номером 287 в ящике, содержащем 523 письма, имеет UID 12345, значит 286 сообщений имеют меньшие значения UID, а 236 – большие UID.
2.3.2. Флаги сообщения
С сообщением связывается список (возможно пустой) именованных маркеров (флагов). Установка флагов обеспечи­вается их включением в список, сброс – удалением из списка. Протокол IMAP4rev1 поддерживает два типа флагов – для сессии и постоянные.
Имена системных флагов определяются настоящей спецификацией (см. таблицу). Все системные флаги начинаются с символа "\". Некоторые из системных флагов (\Deleted и \Seen) используют специальную семантику.
Сообщение было прочитано.
На сообщение был отправлен ответ.
Флаг важности сообщения.
Сообщение «удалено» для последующего уничтожения с помощью EXPUNGE.
Сообщение не закончено (помечено как черновик - draft).
Сообщение недавно доставлено в почтовый ящик. Этот сеанс является первым, в котором это сообщение появилось. Следующие сеансы не будут устанавливать флаг \Recent для этого сообщения. Это флаг не может быть изменен клиентом.
Если невозможно определить, является ли сеанс для данного сообщения первым, сообщение следует рас­сматривать как новое (установить флаг).
Если с одним почтовым ящиком одновременно организовано более одного соединения, невозможно оп­ределить для каких сеансов будет установлен флаг \Recent.
Имена флагов задаются разработчиками сервера и не должны начинаться с символа "\". Серверы могут позволять
клиенту определять новые имена флагов в почтовом ящике (см. описание отклика PERMANENTFLAGS).
Флаги могут быть постоянными или сеансовыми (для каждого флага это определяется независимо). К постоянным от-
носятся те флаги, клиент сохраняются после завершения сеанса, т. е. в следующем сеансе они будут иметь те же зна­чения. Изменения сеансовых флагов сохраняются только в течение сеанса. Флаг \Recent представляет собой специаль­ный случай сеансового системного флага (этот флаг не может использоваться в качестве аргумента команды STORE).
2.3.3. Внутренняя дата сообщения
Внутренние значения даты и времени сообщения на сервере. Это не дата и время заголовка [RFC-822], а дата и время приема сообщения. Для сообщений, доставленных по протоколу SMTP, в этот атрибут следует включать дату и время окончательной доставки сообщения, в соответствии с [SMTP]. Для сообщений, доставленных с помощью команды IMAP4rev1 COPY, в этот атрибут следует включать внутренние значения даты и времени отправителя. Для сообще­ний, поступивших в результате использования команды IMAP4rev1 APPEND, в этот атрибут следует включать дату и время, указанные в описании команды APPEND. Во всех других случаях значение атрибута определяется используе­мой реализацией.
2.3.4. Размер сообщения [RFC-822]
Число октетов в сообщении, выраженное в формате [RFC-822].
2.3.5. Структура конверта
Разобранное представление информации из конверта [RFC-822] (не следует путать с конвертом [SMTP] сообщения.
2.3.6. Структура тела сообщения (Body Structure)
Разобранное представление структуры информации [MIME-IMB] в сообщении.
2.4. Текст сообщения
Кроме извлечения полного текста сообщения [RFC-822] протокол IMAP4rev1 позволяет извлекать отдельные части текста (в честности, заголовок [RFC-822], тело сообщения [RFC-822], часть тела [MIME-IMB] заголовок [MIME-IMB]).
3. Состояния сервера и команды
Сервер IMAP4rev1 может находиться в одном из 4 состояний. Большая часть команд применима в любом из состоя­ний сервера. Если клиент пытается использовать недоступную в данном состоянии сервера команду, возникает прото­кольная ошибка и сервер возвращает отклик BAD или NO (в зависимости от реализации сервера).
3.1. Состояние Non-Authenticated
В этом состоянии клиент должен свои полномочия прежде, чем передавать какие-либо команды. Это состояние явля­ется первым после организации соединения, если соединение не аутентифицировано заранее.
http://rfc.com.ru                                                                5                                                               http://rfc.com.ru
3.2. Состояние Authenticated
В этом состоянии полномочия клиента уже проверены и клиент должен выбрать почтовый ящик для работы, прежде, чем подавать серверу какие-либо команды для работы с сообщениями. Это состояние возникает при организации се­анса клиентом с предварительной аутентификацией или после предъявления клиентом корректных полномочий, а также после ошибок при выборе почтового ящика.
3.3. Состояние Selected
В этом состоянии уже выбран почтовый ящик для работы.
3.4. Состояние Logout
В этом состоянии соединение завершается и сервер разрывает связь. Данное состояние может вводиться по запросу
клиента или по инициативе сервера.
+ -------------------------------------- +
| начало соединения и приветствие |
|| (1) || (2) VV
+ ----------------- +
|non-authenticated|
+ ----------------- +
(7) || (4)
(3)
VV
w
+ ---------------- +
| authenticated |<=++
+ ---------------- +
(7) || (5)
(6)
VV
+ -------- +
++
|selected|=
+ -------- +
|| (7) VV VV VV
+ ----------------------------------
| logout и завершение соединения + ----------------------------------
w
I
(1) Соединение без предварительной аутентификации (приветствие OK)
(2) Соединение с предварительной аутентификацией (приветствие PREAUTH)
(3) Отвергнутое соединение (приветствие BYE)
(4) Успешное выполнение команды LOGIN или AUTHENTICATE
(5) Успешное выполнение команды SELECT или EXAMINE
(6) Команда CLOSE или ошибка при выполнении команды SELECT или EXAMINE
(7) Команда LOGOUT, отключение (shutdown) сервера или разрыв соединения.
4. Форматы данных
Протокол IMAP4rev1 использует текстовые команды и отклики. Данные IMAP4rev1 могут передаваться в оной из описанных ниже форм: атом (atom), число, строка, список в скобках, NIL.
4.1. Атом (Atom)
Атом состоит из одного или нескольких символов общего назначения.
4.2. Число
Число содержит одну или более десятичных цифр, представляющих числовое значение.
4.3. Строка
Строки могут использовать одну из двух возможных форм - литеральную (буквальную – literal) или квотированную (строка в кавычках - quoted string). Литеральная форма представляет собой общую форму представления строк. Кво­тированные строки позволяют упростить обработку за счет сужения используемого в них набора символов. Литеральная строка представляет собой последовательность (возможно, пустую) октетов (включая символы CR и LF), начинающуюся со счетчика октетов в форме {число октетов} за которым следуют символы CRLF. Для строк, переда­ваемых сервером клиенту, октеты данных следуют сразу же после CRLF. Для строк, передаваемых от клиента к сер­веру, клиент должен сначала получить от сервера подтверждение с запросом на продолжение команды (эти запросы описаны ниже) и только после этого передавать данные и оставшуюся часть команды.
Квотированная строка представляет собой последовательность (возможно, пустую) 7-битовых символов, включая CR и LF, заключенную в кавычки ("). Пустые строки представляются как "" (только кавычки) или {0}CRLF (литеральная строка с 0 октетов)2.
4.3.1. 8-битовые и двоичные строки
8-битовые текстовые и бинарные данные поддерживаются с помощью транспортного кодирования содержимого [MIME-IMB]. Реализации IMAP4rev1 могут передавать 8-битовые и мультиоктетные символы в литералах, но делать это следует только в случаях задания [CHARSET] (набор символов).
2 Клиент должен получать запрос на продолжение даже при передаче литеральной строки нулевой длины.
6
Хотя бинарные данные определены спецификацией, их некодированная передача не допускается. Бинарными назы­вают строки с символами NUL. Реализации должны преобразовывать бинарные данные в текстовый формат (напри­мер, BASE64) до их передачи. Строки с большим числом символов CTL, также могут считаться бинарными.
4.4. Список в скобках (Parenthesized List)
Структуры данных представляются в форме заключенных в скобки списков (parenthesized list) – последовательность элементов, разделенных пробелами, ограничивается с обеих сторон скобками. Списки могут содержать внутри себя другие списки в скобках. Пустой список представляется в виде ().
4.5. Пустой формат (NIL)
Специальный атом NIL используется для представления несуществующих данных определенного типа, представляе­мых как строка или список в скобках, в отличие от пустой строки - "" или списка ().
5. Работа протокола
5.1. Именование почтовых ящиков
Интерпретация имен почтовых ящиков зависит от реализации. Однако почтовый ящик с независимым от регистра именем INBOX зарезервирован в качестве основного почтового ящика пользователя на данном сервере.
5.1.1.Иерархия имен
Желательно экспортировать иерархические имена почтовых ящиков – имена должны записываться со снижением уровня иерархии слева направо и односимвольным разделителем между иерархическими уровнями. Разделитель для всех переходов между уровнями должен быть один.
5.1.2. Соглашение о пространстве имен
По этому соглашению первый иерархический элемент любого имени почтового ящика должен начинаться с символа #, идентифицирующего пространство имен (namespace) остальной части имени. Это позволяет различать разные типы почтовых хранилищ (mailbox store), каждый из которых имеет свое пространство имен.
Например, реализация, предлагающая доступ к конференциям USENET может использовать пространство #news для отделения имен конференций USENET от других почтовых ящиков. В результате конференция comp.mail.misc будет иметь почтовый ящик #news.comp.mail.misc, а имя comp.mail.misc может указывать на иной объект (например, почто­вый ящик пользователя).
5.1.3. Соглашение об использовании других языков в именах
В соответствии с этим соглашение имена почтовых ящиков могут использовать символы других языков с обновлен­ной версией кодирования UTF-7, описанной в работе [UTF-7]. Обновление было предпринято с целью разрешения пе­речисленных ниже проблем UTF-7:
1.    UTF-7 использует знак "+" для смещения (shifting), что не позволяет применять "+" в именах почтовых ящиков (в частности, с названиях конференций USENET.
2.    UTF-7 использует кодирование BASE64, применение символа "/" в котором конфликтует с использованием "/" в качестве разделителя иерархических уровней.
3.    UTF-7 запрещает некодированное представление символа "\", что не позволяет использовать его в качестве разде­лителя иерархических уровней.
4.    UTF-7 запрещает некодированное представление символа "~", используемого в некоторых серверах в качестве индикатора домашнего каталога.
5.    UTF-7 допускает множество альтернативных форм представления одной строки (в частности, печатные символы US-ASCII можно представлять в кодированной форме).
В обновленном варианте UTF-7 печатные символы US-ASCII (за исключением "&") представляют себя, т. е., символы с кодами 0x20 - 0x25 и 0x27 - 0x7e. Символ "&" (0x26) представляется 2-октетной последовательностью "&-". Все прочие символы (0x00 - 0x1f, 0x7f - 0xff, 16-битовые символы Unicode) представляются с использованием модифици­рованного кода BASE64 (в соответствии с [UTF-7] "," используется взамен "/"). Обновленное кодирование BASE64 недопустимо использовать для представления любых печатных символов US-ASCII. Символ "&" используется для перехода к модифицированному кодированию BASE64, а "-" для перехода к US-ASCII. Все имена начинаются с сим­вола US-ASCII и должны заканчиваться символом US-ASCII (т. е., имя из символов Unicode должно завершаться зна­ком "- "). В качестве примера приведем имя, содержащее текст на английском, японском и китайском языках -~peter/mail/&ZeVnLIqe-/&U,BTFw-
5.2. Обновление размеров и статуса сообщений
В любой момент сервер может передать данные, которых клиент не запрашивал. Иногда такая передача может даже требоваться. Например, агенты (не сервер) могут добавлять сообщения в почтовый ящик (например, доставка новой почты), менять флаги сообщений в почтовых ящиках (например, одновременный доступ к почтовому ящику несколь­ких агентов) и даже удалять сообщения. Сервер должен передавать обновленные данные о размере почтового ящика, если таковые обнаружены в процессе обработки команды. Серверу следует автоматически передавать обновленную информацию о флагах без явного запроса на такое обновление со стороны клиента. Для передачи уведомлений об удалении почты существуют специальные правила, позволяющие избежать ошибок при синхронизации (см. 7.4.1. Отклик EXPUNGE).
7
Независимо от используемого в реализации клиента способа запоминания полученных от сервера данных, клиент должен записывать обновления размера почтового ящика. Недопустимо предполагать, что любая команда после на­чального выбора почтового ящика будет возвращать его размер.
5.3. Отклики при отсутствии обрабатываемых команд
Серверу разрешается передавать непомеченные отклики (за исключением EXPUNGE) при отсутствии обрабатывае­мых команд. Реализации серверов, передающие такие отклики, должны принимать во внимание вопросы управления потоком данных. В частности, сервер должен (1) убедиться, что размер передаваемы данных не превышает макси­мальный размер окна, доступный нижележащему транспортному уровню или (2) использовать запись без блокировки (non-blocking write).
5.4. Таймер автоматического отключения
Если сервер использует автоматическое отключение по таймеру в случае отсутствия активности, значение таймера ав­томатического отключения должно быть не менее 30 минут. Получив от клиента любую команду, серверу следует сбросить таймер.
5.5. Обработка множества команд
Клиент может передавать новые команды, не дожидаясь отклика о завершении обработки предыдущих команд, с уче­том правил однозначности (см. ниже) и управления потоком данных на нижележащем уровне. Сервер может начать обработку новой команды до завершения обработки прежних, учитывая правила однозначности. Однако все отклики с запросами на продолжение команды и продолжения команд должны быть согласованы до того, как будет передана следующая команда.
Правило однозначности связано с возможной зависимостью результатов выполнения команды от результатов завер­шения предшествующих команд. Для клиентов недопустимо передавать команду без ожидания, если результаты мо­гут быть неоднозначными. Если сервер видит возможность неоднозначности, он должен выполнять команды в задан­ном клиентом порядке.
Тривиальным случаем возникновения неоднозначности является ситуация, когда результаты выполнения одной ко­манды напрямую воздействуют на результат другой (например, команды 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
6. Команды клиента
В этой главе описаны команды протокола IMAP4rev1. Все команды организованы по состояниям, для которых воз­можно использование этих команд (например, команды, корректные для состояний authenticated и selected, перечисле­ны в числе команд для состояния authenticated).
Аргументы команд указываются ключевым словом "Аргументы:" в описании команды и рассмотрены здесь только с функциональной точки зрения, а синтаксис аргументов описан в главе «Формальный синтаксис». Некоторые команды ведут к генерации сервером специфического отклика – эти отклики помечены ключевым словом "Отклик:" в описании команды. Дополнительная информация об откликах содержится в глава «Отклики» и «Фор­мальный синтаксис». По любой команде клиента сервер может передавать в ответ данные.
Ключевое слово "Результат:" в описании команды указывает на возможные помеченные (tagged) отклики о состоянии и специфическую интерпретацию таких откликов.
6.1. Команды клиента для любого состояния
Команды CAPABILITY, NOOP и LOGOUT могут использоваться во всех состояниях.
6.1.1. Команда CAPABILITY
Аргументы: не используются
Отклик: требуется непомеченный отклик CAPABILITY
Результат: OK – успешное завершение
BAD – команда не поддерживается. Команда CAPABILITY запрашивает у сервера список поддерживаемых возможностей. Сервер должен передавать один непомеченный отклик CAPABILITY, указывая в списке возможностей по крайней мере IMAP4rev1, и только по­ток возвращать помеченный отклик OK. Возвращаемый список возможностей не зависит от пользователя или состоя­ния соединения, следовательно, не возникает необходимости использования команды CAPABILITY более одного раза в каждом соединении.
8
Имена возможностей, начинающихся с AUTH=, показывают, что сервер использует механизм аутентификации. Все такие имена, по определению, являются частью данной спецификации. Например, аутентификация с помощью экспе­риментального метода blurdybloop будет обозначаться возможностью AUTH=XBLURDYBLOOP, но не XAUTH=BLURDYBLOOP или XAUTH=XBLURDYBLOOP.
Имена других возможностей указывают на расширения, пересмотры или изменения данной спецификации. Дополни­тельная информация приведена ниже при описании откликов CAPABILITY. В данной спецификации не определяется никаких дополнительных возможностей сверх базовой возможности IMAP4rev1, поддерживаемой автоматически без каких-либо запросов со стороны клиента.
Информация о расширениях и экспериментальных возможностях приводится в параграфе 6.5. Команды клиента – экспериментальные/расширения.
Пример:                   C
S S
abcd CAPABILITY
* CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4
abcd OK CAPABILITY completed
6.1.2. Команда NOOP
Аргументы: не используются
Отклик: для этой команды не существует специфических откликов (см. ниже)
Результат: OK – команда выполнена
BAD – команда не поддерживается или некорректны аргументы Команда NOOP всегда завершается успешно, поскольку она не делает ничего. Поскольку любая команда может воз­вращать обновленное состояние как непомеченные данные, команду NOOP можно использовать для периодического получения обновлений во время бездействия клиента. Можно также использовать команду NOOP для сброса таймера бездействия на сервере. Пример: C: a002 NOOP
S: a002 OK NOOP completed
a047 NOOP
* 22 EXPUNGE
* 23 EXISTS
* 3 RECENT
* 14 FETCH (FLAGS (\Seen \Deleted)) a047 OK NOOP completed
6.1.3. Команда LOGOUT Аргументы: не используются Отклик: Требуется непомеченный отклик BYE Результат: OK - команда выполнена
BAD - команда не поддерживается или некорректны аргументы Команда LOGOUT информирует сервер о намерении клиента закончить работу. Сервер должен передать непомечен­ный отклик BYE до передачи отмеченного отклика OK, а потом закрыть соединение. Пример: C: A023 LOGOUT
S: * BYE IMAP4rev1 Server logging out
S: A023 OK LOGOUT completed Сервер и клиент закрыли соединение.
6.2. Клиентские команды – состояние Non-Authenticated
В состоянии, когда аутентификация еще не произведена, команда AUTHENTICATE или LOGIN позволяет провести аутентификацию и перейти в состояние authenticated. Команда AUTHENTICATE обеспечивает общий механизм для различных методов аутентификации, а LOGIN использует традиционную пару «имя пользователя – пароль», переда­ваемую в виде текста.
Для некоторых почтовых ящиков сервер может позволять работу без аутентификации. По соглашения команда LOGIN может использоваться с именем пользователя anonymous (безымянный). Пароль является обязательным. Па­роль и права доступа для анонимного пользователя зависят от реализации.
После аутентификации (включая анонимную) соединение не может быть переведено в состояние non-authenticated. В дополнение к универсальным командам (CAPABILITY, NOOP, LOGOUT), данное состояние поддерживает коман­ды AUTHENTICATE и LOGIN.
6.2.1. Команда AUTHENTICATE
Аргументы: имя механизма аутентификации
Отклик: могут быть запрошены дополнительные данные
Результат: OK – аутентификация завершена успешно, текущее состояние authenticated
NO – неудача при аутентификации – неподдерживаемый механизм, нет полномочий BAD - команда не поддерживается или некорректны аргументы, аутентификации не произошло. Команд AUTHENTICATE показывает серверу механизм аутентификации (типа описанного в работе [IMAP-AUTH]). Если сервер поддерживает этот механизм, выполняется обмен данными для проверки полномочий (аутентификации клиента). Можно также согласовать дополнительный механизм защиты для последующего обмена данными. Если запрошенный метод аутентификации не поддерживается, серверу следует отвергать команду AUTHENTICATE, пере­давая помеченные отклик NO.
http://rfc.com.ru                                                                9                                                              http://rfc.com.ru
 
Процесс аутентификации включает в себя обмен данными, состоящими из вопросов сервера и ответов клиента, - на­бор вопросов зависит от реализации. to the authentication mechanism. Вопрос сервера включает запрос продолжения команды, состоящий из маркера "+", за которым следует строка в формате BASE64. Отклик клиента представляет со­бой строку в коде BASE64. Если клиент хочет прервать обмен данными аутентификации, он просто передает строку, содержащую один символ "*". Получив такой ответ, сервер должен отвергнуть команду AUTHENTICATE и передать отмеченный отклик BAD.
Механизм защиты обеспечивает целостность и конфиденциальность соединения. Если такой механизм согласован, он применяется ко всем данным, передаваемым через соединение. Механизм защиты начинает работать сразу после по­лучения последовательности CRLF,завершающей аутентификацию клиента и последовательности CRLF, завершаю­щей отклик OK. После включения механизма защиты поток октетов команд и откликов обрабатывается в буферах шифрования. Содержимое каждого буфера передается через соединение как поток октетов, которому предшествует 4-оектетное поле размера. Максимальный размер шифрованного буфера определяется используемым механизмом. Механизм аутентификации является необязательным. Механизм защиты также необязателен и аутентификация мо­жет быть реализована без дополнительной защиты. Если команда AUTHENTICATE завершается отказом с откликом NO, клиент может попытаться использовать иной механизм аутентификации в следующей команде AUTHENTICATE или может попытаться войти в систему по команде LOGIN. Иными словами, клиент может запрашивать механизмы аутентификации в порядке снижения уровня предпочтений вплоть до команды LOGIN, как последней попытки. Пример: S: * OK KerberosV4 IMAP4rev1 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C3: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT+nZImJjnTNHJUtxAA+o0KPKf HEcAFs9a3CL5Oebe/ydHJUwYFdWwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
6.2.2. Команда LOGIN
Аргументы: имя пользователя, пароль
6.2.2. Команда LOGIN
Аргументы: имя пользователя, пароль
Отклик: для этой команды не существует специфических откликов
Результат: OK – вход в системы завершен, состояние authenticated
NO – неудача – имя пользователя или пароль отвергнуты
BAD - команда не поддерживается или некорректны аргументы Команда LOGIN используется для представления клиента серверу и передачи пароля в виде открытого текста. Пример: C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed
6.3. Команды клиента – состояние Authenticated
После успешного завершения аутентификации становятся доступными команды для работы с почтовыми ящиками как атомами. Команды SELECT и EXAMINE позволяют выбирать почтовые ящики и переводят соединение в состоя­ние selected.
В дополнение к универсальным командам (CAPABILITY, NOOP, LOGOUT) после успешной аутентификации под­держиваются команды SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, APPEND.
6.3.1. Команда SELECT
Аргументы: имя почтового ящика
Отклик: обязательно непомеченный отклик FLAGS, EXISTS, RECENT
дополнительно OK непомеченный отклик UNSEEN, PERMANENTFLAGS Результат: OK – выбор завершено, состояние selected
NO – отказ при выборе, состояние authenticated (нет почтового ящика или доступа к нему) BAD - команда не поддерживается или некорректны аргументы Команда SELECT выбирает почтовый ящик и обеспечивает доступ к хранящимся в нем сообщениям. До возврата кли­енту отклика сервер должен передать клиенту следующие непомеченные данные для определения начального состоя­ния почтового ящика:
FLAGS                               определяет флаги почтового ящика (см. описание отклика FLAGS).
<n> EXISTS                       число сообщений в почтовом ящике (см. описание отклика EXISTS).
<n> RECENT                     число сообщений с установленным флагом \Recent (см. описание отклика RECENT).
OK [UIDVALIDITY <n>] уникальный идентификатор корректности (см. описание отклика UID). Серверу следует также передать код UNSEEN в непомеченном отклике OK, показывающий порядковый номер перво­го непрочитанного сообщения в почтовом ящике.
Если клиенту не разрешается вносить постоянные изменения в те или иные флаги, указанные в непомеченном отклике FLAGS, серверу следует передать код PERMANENTFLAGS в непомеченном отклике OK, указывающий какие флаги клиент не может изменить.
В каждом соединении может быть выбран только один почтовый ящик и для работы с несколькими ящиками требует­ся соответствующее число соединений. При выборе нового почтового ящика команда SELECT автоматически отменя­ет текущий выбор. Следовательно, если выбран почтовый ящик, то после неудачного использования команды
Этот отклик на самом деле является одной строкой.
10
SELECT этот выбор будет отменен.
Если клиенту позволено изменять почтовый ящик, серверу следует перед текстом помеченного отклика OK помещать код [READ-WRITE]. Если клиенту не разрешено менять содержимое почтового ящика, но открыт доступ для чтения почты, почтовый ящик выбирается в режиме чтения (read-only) и сервер должен перед текстом отклика OK на коман­ду SELECT поместить код [READ-ONLY]. Доступ для чтения по команде SELECT отличается от использования ко­манды EXAMINE тем, что некоторые почтовые ящики read-only могут позволять изменение перманентного состояния отдельным пользователям (при наличии общего запрета. Новости, промаркированные в файле .newsrc на сервере, яв­ляются примером такой ситуации (некоторые пользователи могут менять состояние почтовых ящиков с атрибутом read-only). Пример: 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
6.3.2. Команда EXAMINE Аргументы: имя почтового ящика Отклик: обязательно непомеченный отклик FLAGS, EXISTS, RECENT
дополнительно OK непомеченный отклик UNSEEN, PERMANENTFLAGS Результат: OK – проверка завершена, состояние selected
NO – неудачная проверка, состояние authenticated (нет почтового ящика или доступа к нему) BAD - команда не поддерживается или некорректны аргументы Команда EXAMINE идентична команде SELECT и возвращает такие же результаты, однако открывает выбранный почтовый ящик только для чтения (read-only). Не допускается перманентного изменения состояния почтового ящика. Текст отмеченного отклика OK на команду EXAMINE должен начинаться с кода [READ-ONLY]. Пример: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed
6.3.3. Команда CREATE Аргументы: имя почтового ящика
Отклик: для этой команды не существует специфических откликов Результат: OK – успешное завершение
NO – невозможно создать почтовый ящик с указанным именем BAD - команда не поддерживается или некорректны аргументы Команда CREATE создает почтовый ящик с заданным именем. Отклик OK возвращается только при успешном созда­нии почтового ящика. При попытке создать почтовый ящик INBOX4 или с другим уже используемым именем возни­кает ошибка. В результате любой ошибки будет возвращаться помеченный отклик 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 Отметим, что интерпретация приведенного примера зависит от того, возвращает ли сервер символ "/" по команде LIST. Если "/" служит разделителем, создается новый уровень с именем blurdybloop в иерархии owatagusiam. В про­тивном случае создаются два почтовых ящика на одном уровне иерархии.
6.3.4. Команда DELETE Аргументы: имя почтового ящика Отклик: для этой команды не существует специфических откликов
4 Независимо от регистра символов. Прим. перев.
http://rfc.com.ru                                                               11                                                              http://rfc.com.ru
Результат: OK – успешное удаление
NO – невозможно удалить почтовый ящик с указанным именем
BAD - команда не поддерживается или некорректны аргументы Команда DELETE навсегда удаляет указанный почтовый ящик. При попытке удаления ящика INBOX5 или отсутст­вующего почтового ящика возникает ошибка.
Недопустимо с помощью команды DELETE удалять внутренние уровни иерархии имен. Например, почтовый ящик foo является внутренним в иерархии foo.bar (предполагается, что "." служит разделителем уровней), удаление foo не­допустимо следует удалять foo.bar. Ошибка произойдет и при попытке удаления имени, имеющего подчиненные уровни и атрибут \Noselect (см. описание отклика LIST). Допускается удалять имена с подчиненными уровнями, кото­рые не имеют атрибута \Noselect. В таких случаях все сообщения из почтового ящика, а имя приобретает атрибут \Noselect.
Максимальное значение уникального идентификатора для удаляемого ящика должно сохраняться, чтобы при созда­нии нового ящика с этим именем не возникало повторного использования идентификаторов, если для нового ящика не задается другое значение уникального идентификатора корректности (см. описание команды UID). Пример: C: A682 LIST "" *
* LIST () "/" blurdybloop
* LIST (\Noselect) "/" foo
* LIST () "/" foo/bar A682 OK LIST completed A683 DELETE blurdybloop A683 OK DELETE completed A684 DELETE foo
A684 NO Name "foo" has inferior hierarchical names A685 DELETE foo/bar A685 OK DELETE Completed A686 LIST "" *
* LIST (\Noselect) "/" foo A686 OK LIST completed A687 DELETE foo A687 OK DELETE Completed A82 LIST "" *
* LIST () "." blurdybloop
* LIST () "." foo
* LIST () "." foo.bar
A
A
A
A8
A8
A8
*
A8
A8
*
A8
5 OK LIST completed
6 LIST "" %
LIST (\Noselect) "." foo 6 OK LIST completed
6.3.5. Команда RENAME
Аргументы: имя существующего почтового ящика, имя нового почтового ящика Отклик: для этой команды не существует специфических откликов Результат: OK – успешная смена имени
NO – не удалось изменить имя (нет такого почтового ящика или новое имя уже используется)
BAD - команда не поддерживается или некорректны аргументы Команда RENAME служит для изменения имени почтового ящика. Помеченный отклик OK возвращается только по­сле успешного изменения имени. Попытка переименовать несуществующий почтовый ящик или задать в качестве но­вого уже используемое имя приводит к ошибке. В случае любой ошибки возвращается помеченный отклик NO. При замене имени почтового ящика, имеющего нижележащие уровни, их имена также должны изменяться. Напри­мер, при смене имени foo на zap имя foo/bar ("/" является разделителем уровней) должно стать zap/bar. Максимальное значение уникального идентификатора для ящика, имя которого изменяется, должно сохраняться, чтобы при создании нового ящика с этим именем не возникало повторного использования идентификаторов, если для нового ящика не задается другое значение уникального идентификатора корректности (см. описание команды UID). Допускается переименование почтового ящика INBOX при выполнении определенных условий – все сообщения из INBOX перемещаются в почтовый ящик с новым именем и создается заново пустой почтовый ящик INBOX. Если реализация сервера поддерживает иерархию имен в INBOX, на эту иерархию не действует переименование INBOX. Пример: C: A682 LIST "" *
S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo
5 Независимо от регистра символов. Прим. перев.
12
А6
А6
А6
А6
А6
А6 *
LIST () "/" foo/bar
82 OK LIST completed
83 RENAME blurdybloop sarasoop
83 OK RENAME completed
84 RENAME foo zowie
84 OK RENAME Completed
85 LIST "" * LIST () "/" sarasoop LIST (\Noselect) "/" zowie LIST () "/" zowie/bar 85 OK LIST completed 32 LIST "" * LIST () "." INBOX LIST () "." INBOX.bar
32 OK LIST completed
33 RENAME INBOX old-mail
33 OK RENAME completed
34 LIST "" * LIST () "." INBOX LIST () "." INBOX.bar LIST () "." old-mail 34 OK LIST completed
А6
Z4 *
*
Z4 Z4 Z4 Z4
Z4
6.3.6. Команда SUBSCRIBE Аргументы: имя почтового ящика.
Отклик: для этой команды не существует специфических откликов Результат: OK – успешное завершение
NO – отказ – невозможна подписка для указанного имени
BAD - команда не поддерживается или некорректны аргументы Команда SUBSCRIBE добавляет указанное имя почтового ящика в число «активных» или «подписанных» ящиков, список которых возвращается по команде LSUB. Отмеченный отклик OK возвращается только при успешной подпис­ке.
Сервер может проверять существование почтового ящика, указанного в команде SUBSCRIBE. Однако для сервера недопустимо по своей воле удалять имена почтовых ящиков из списка даже в тех случаях, когда ящика уже нет6. Пример: C: A002 SUBSCRIBE #news.comp.mail.mime S: A002 OK SUBSCRIBE completed
6.3.7. Команда UNSUBSCRIBE Аргументы: имя почтового ящика
Отклик: для этой команды не существует специфических откликов Результат: OK – успешный отказ от подписки
NO – неудача
BAD - команда не поддерживается или некорректны аргументы Команда UNSUBSCRIBE служит для удаления указанного почтового ящика из числа «активных» или «подписанных» ящиков, список которых возвращается по команде LSUB. Отмеченный отклик OK возвращается только при успешном удалении из списка.
Пример: C: A002 UNSUBSCRIBE #news.comp.mail.mime S: A002 OK UNSUBSCRIBE completed
6.3.8. Команда LIST
Аргументы: база, имя почтового ящика (возможны шаблоны) Отклик: непомеченный отклик LIST Результат: OK – список получен
NO – отказ – невозможно вернуть список с заданной базой или именем
BAD - команда не поддерживается или некорректны аргументы Команда LIST возвращает заданное подмножество полного набора имен, доступных клиенту. В ответ на команду воз­вращается некоторое число (возможно, 0) помеченных откликов LIST, содержащих атрибуты имени, разделитель уровней иерархии и имя (см. описание отклика LIST).
Данные по команде LIST следует возвращать быстро лишних задержек. Например, не следует выполнять расчет со­стояний \Marked или \Unmarked и выполнять другие действия – если каждое имя потребует 1 сек., то на обработку 1200 будет потрачено 20 минут!
Пустая база ("") reference name argument indicates that the имя почтового ящика is interpreted as by SELECT. Возвра­щаемые имена почтовых ящиков должны соответствовать указанному шаблону имени. Непустая ссылка задает имя почтового ящика или уровень иерархии и контекст, в котором интерпретируется имя почтового ящика (в зависимости от реализации). Пустое ("") имя почтового ящика задает специальный случай для возврата разделителя уровней иерархии и корневого
6 Это требование связано с тем, что некоторые серверы могут удалять почтовые ящики с хорошо известными именами (например, system-alerts) после истечения срока действия его содержимого и потом восстанавливать почтовый ящик при необходимости.
http://rfc.com.ru                                                              13                                                             http://rfc.com.ru
имени для заданной базы. Возвращаемое корневое значение может быть пустым, если база не имеет корня или задана пустая база. Разделитель уровней возвращается в любом случае. Это позволяет клиенту определить разделитель даже при отсутствии почтового ящика с указанным именем.
База и имя почтового ящика преобразуются (в зависимости от реализации) в каноническую форму с однозначным представлением иерархии слева направо. Возвращаемое имя почтового ящика будет иметь эту форму. Любую часть базы в преобразованной форме следует указывать как префикс, сохраняя указанную в аргументе коман­ды форму базы для этого префикса. Это правило позволяет клиентам определять относится ли возвращенное имя поч­тового ящика к контексту базы и обнаружить пересечение имени с базой. Без этого правила клиент будет получать ис­каженную информацию о контексте имен. Для примера в таблице показано несколько вариантов интерпретации базы и имени почтового ящика серверами на основе 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/*
Первые три строки показывают реализацию в контек­сте базы. Отметим, что ~smith/Mail не следует преоб­разовать во что-либо иное, типа /u2/users/smith/Mail, поскольку клиент не сможет определить, что интерпре­тация происходила в контексте базы. Символ "*" является шаблоном и соответствует любым
символам (в произвольном количестве) в этой позиции. Символ "%" подобен "*", но не соответствует разделителям уровней иерархии. Если символ "%" указан последним в шаблоне имени почтового ящика, возвращаются также соответствующие уровни иерархии. Если эти уровни не явля­ются почтовыми ящиками, которые можно выбрать, возвращается атрибут \Noselect (см. описание отклика LIST). Серверам разрешается «прятать» доступные почтовые ящики при использовании шаблонов в некоторых ситуациях. Например, серверы на основе UNIX могут ограничивать действие шаблона "*" так, чтобы начальный символ "/" не да­вал соответствия.
Специальное имя INBOX включается в выходной список команды LIST, если ящик INBOX поддерживается сервером для данного пользователя и строка INBOX (в верхнем регистре) соответствует базе и имени почтового ящика с задан­ными в команде шаблонами. Критерием включения ящика INBOX является возможность его выбора по команде SELECT. Пример: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed
6.3.9. Команда LSUB
Аргументы: база, имя почтового ящика (возможны шаблоны) Отклик: непомеченный отклик LSUB Результат: OK – успешное завершение
NO - неудача
BAD - команда не поддерживается или некорректны аргументы Команда LSUB возвращает подмножество имен из набора, объявленного пользователем «активным» или «подписан­ным». LSUB возвращает 0 или больше помеченных откликов. Аргументы LSUB имеют такую же форму, как аргумен­ты команды LIST.
Сервер может проверить существование подписанных имен. Если имя не существует, его следует возвращать с фла­гом \Noselect в отклике LSUB. Для серверов недопустимо самовольное удаление имени почтового ящика из списка активных, даже если ящик больше не существует. Пример: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
6.3.10. Команда STATUS
Аргументы: имя почтового ящика, имена элементов состояния Отклик: непомеченный отклик STATUS Результат: OK – успешное завершение
NO – неудача – для заданного имени нет данных о состоянии
BAD - команда не поддерживается или некорректны аргументы Команда STATUS запрашивает сведения о состоянии указанного почтового ящика. Команда не меняет выбранный почтовый ящик и не влияет на состояние каких-либо сообщений в ящике, для которого запрашивается состояние (в частности, при использовании команды STATUS недопустим сброс флага \Recent). Команда STATUS является альтернативой открытию второго соединения IMAP4rev1 и использованию команды
14
EXAMINE, позволяя получать данные о состоянии без организации специального соединения IMAP4rev1.
В отличие от LIST команда STATUS не гарантирует быстрого отклика. В некоторых реализациях сервер должен от­крыть почтовый ящик в режиме read-only (только чтение) для получения некоторых данных о состоянии. Кроме того,
в отличие от LIST команда STATUS не допускает использования шаблонов.
Определенные на сегодняшний день элементы состояния включают:
MESSAGES число сообщений в почтовом ящике.
RECENT            число сообщений с флагом \Recent.
UIDNEXT          значение UID, которое будет использовано для следующего сообщения в почтовом ящике. Гаранти-
руется неизменность этого значения пока в ящик не будет добавлено новое сообщение. Гарантирует­ся также изменение значения при получении нового письма, даже если это сообщение будет потом исключено.
UIDVALIDITY значение уникального идентификатора корректности для почтового ящика.
UNSEEN           число сообщений, для которых не установлен флаг \Seen.
Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: A042 OK STATUS completed
6.3.11. Команда APPEND
Аргументы: имя почтового ящика, [заключенный в скобки список флагов]7, [строка даты/времени], сообщение
Отклик: для этой команды не существует специфических откликов
Результат: OK – успешное добавление
NO – ошибка – невозможно добавить сообщение в указанный ящик, ошибка в флагах, дате или тексте BAD - команда не поддерживается или некорректны аргументы Команда APPEND добавляет переданный ей аргумент как новое сообщение в конце указанного почтового ящика. Для аргументов следует использовать синтаксис [RFC-822]. В сообщении допускаются 8-битовые символы. Серверы, не­способные корректно сохранять 8-битовые символы, должны обеспечивать обратимое преобразование 8-битовых данных команды APPEND в 7-битовые с использованием транспортного кодирования содержимого [MIME-IMB]. От­метим, что эти правила могут иметь исключения – например, при использовании команды APPEND для сохранения черновиков сообщений можно опустить строки заголовка [RFC-822]. Однако использоваться такие исключения должны с осторожностью.
Если присутствует список флагов в скобках, в добавленном сообщении следует установить заданные флаги (по умол­чанию флаги отсутствуют).
Если указана дата и время, для добавленного сообщения следует установить заданные значения даты и времени (по умолчанию устанавливаются текущая дата и время).
Если при добавлении произошла какая-то ошибка, почтовый ящик должен быть восстановлен в исходном виде (как до команды APPEND) – частичная добавка сообщения недопустима.
Если указанного почтового ящика не существует, сервер должен возвратить сообщение об ошибке; автоматическое создание почтового ящика недопустимо. Кроме тех случаев, когда указанный почтовый ящик не может быть создан, сервер должен добавлять код [TRYCREATE] перед текстом помеченного отклика NO, намекая клиенту на возмож­ность использования команды CREATE и повтора APPEND при удачном создании почтового ящика. Если почтовый ящик в данный момент выбран, следует выполнить действия как при обычном получении нового со­общения. В частности, серверу следует незамедлительно уведомить клиента с помощью непомеченного отклика EXISTS. Если сервер не делает этого, клиент может ввести команду NOOP (или CHECK) после одной или нескольких команд APPEND. Пример: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed Отметим, что команда APPEND не используется для доставки почты, поскольку она не обеспечивает механизма пере­дачи информации из конвертов [SMTP].
6.4. Команды клиента – состояние Selected
В состоянии selected поддерживаются команды для работы с сообщениями в почтовом ящике.
В дополнение к универсальным командам (CAPABILITY, NOOP, LOGOUT), и командам после аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, APPEND) поддерживаются команды CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, UID.
7 В квадратных скобках указаны необязательные параметры. Прим. перев.
http://rfc.com.ru                                                               15                                                              http://rfc.com.ru
 
6.4.1. Команда CHECK Аргументы: не используются
Отклик: для этой команды не существует специфических откликов Результат: OK – проверка завершена успешно
BAD - команда не поддерживается или некорректны аргументы Команда CHECK запрашивает выполнение контрольной операции (checkpoint) для выбранного почтового ящика. Кон­трольная операция может быть любым действием, связанным с почтовым ящиком) и определяется используемой реа­лизацией (примером такой контрольной операции может служить сброс содержимого почтового ящика из памяти сер­вера на диск). Выполнение контрольной операции может занимать достаточно много времени. Если сервер не под­держивает контрольных операций, команда CHECK становится эквивалентом команды NOOP.
Нет никакой гарантии, что после команды CHECK будет передаваться непомеченный отклик EXISTS – для гаранти­рованного получения такого отклика следует использовать команду NOOP. Пример: C: FXXZ CHECK
S: FXXZ OK CHECK Completed
6.4.2. Команда CLOSE Аргументы: не используются
Отклик: для этой команды не существует специфических откликов Результат: OK – выбор ящика отменен, текущее состояние authenticated
NO – отказ – не выбрано почтового ящика
BAD - команда не поддерживается или некорректны аргументы Команда CLOSE уничтожает в выбранном почтовом ящике все сообщения с установленным флагом \Deleted и обес­печивает возврат в состояние authenticated из состояния. В ответ на команду передается без тега отклик EXPUNGE. Сообщения не удаляются и сообщения об ошибке не возвращается, если почтовый ящик был выбран командой EXAMINE или открыт в режиме read-only (только чтение).
Если почтовый ящик выбран, команды SELECT, EXAMINE, LOGOUT могут вводиться без предшествующей коман­ды CLOSE. Команды SELECT, EXAMINE и LOGOUT явно отменяют текущий выбор почтового ящика без удаления сообщений из него. Однако при наличии большого числа сообщений с флагом \Deleted последовательности CLOSE-LOGOUT и CLOSE-SELECT заметно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, поскольку они не передают непомеченных откликов EXPUNGE (которые клиент обычно игнорирует). Пример: C: A341 CLOSE
S: A341 OK CLOSE completed
6.4.3. Команда EXPUNGE Аргументы: не используются Отклик: непомеченный отклик EXPUNGE Результат: OK – удаление завершено
NO – отказ при удалении (например, нет прав доступа) BAD - команда не поддерживается или некорректны аргументы Команда 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 (см. описание отклика EXPUNGE).
6.4.4. Команда SEARCH
Аргументы: [CHARSET]8, критерии поиска (один или несколько) Отклик: Обязательный непомеченный отклик SEARCH Результат: OK – удачное завершение поиска
NO – ошибка – невозможно : can't search that [CHARSET] or criteria
BAD - команда не поддерживается или некорректны аргументы Команда SEARCH обеспечивает поиск в почтовом ящике сообщений, удовлетворяющих заданным критериям. Крите­рий поиска содержит один или несколько ключей. Непомеченный отклик SEARCH от сервера содержит список по­рядковых номеров сообщений, которые соответствуют критерию поиска.
При использовании множества ключей поиска они комбинируются с помощью логической операции AND (и). Напри­мер, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 задает поиск всех удаленных сообщений от Smith, поме­щенных в ящик после 1 февраля 1994 года. При задании ключей поиска могут использоваться логические операции OR (или) и NOT (отрицание), а также скобки.
Сервер может исключать части [MIME-IMB] в теле сообщения с типами, отличными от TEXT или MESSAGE при вы­полнении команды SEARCH.
Необязательный параметр [CHARSET] состоит из ключевого слова CHARSET, за которым следует зарегистрирован­ное значение [CHARSET]. Этот параметр задает набор символов в строке критерия поиска. Транспортное кодирова-
Необязательный параметр. Прим. перев.
16
ние [MIME-IMB] и строки [MIME-HDRS] в заголовках [RFC-822]/[MIME-IMB] должны декодироваться перед срав­нением текста, если [CHARSET] отличается от US-ASCII. Кодировка US-ASCII должна поддерживаться, другие вари­анты [CHARSET] также можно поддерживать. Если сервер не поддерживает заданное значение [CHARSET], он дол­жен возвращать помеченный отклик NO (а не BAD).
Во всех ключах поиска, содержащих строки текста, условие считается выполненным, если ключ поиска является ча­стью строки в сообщении. Регистр символов при поиске не учитывается.
Ниже перечислен список поддерживаемых ключей, а их синтаксические определения приведены в главе 9. Формальный синтаксис.
<message set>                     сообщения с порядковым номером, соответствующим указанному набору номеров.
ALL                                   все сообщения в почтовом ящике; принято по умолчанию как стартовый ключ для AND.
ANSWERED                      сообщения с установленным флагом \Answered.
BCC <string>                      сообщения, содержащие указанную строку в структуре поля BCC в конверте.
BEFORE <date>                 сообщения, в которых внутренняя дата раньше указанной.
BODY <string>                   сообщения, содержащие указанную строку в теле письма.
CC <string>                        сообщения, содержащие указанную строку в структуре поля CC в конверте.
DELETED                          сообщения с установленным флагом \Deleted.
DRAFT                              сообщения с установленным флагом \Draft.
FLAGGED                         сообщения с установленным флагом \Flagged.
FROM <string>                   сообщения, содержащие указанную строку в структуре поля FROM в конверте.
HEADER <field-name> <string> сообщения, в заголовке которых содержится поле с указанным именем (определено в
[RFC-822]) и содержимым. KEYWORD <flag>             сообщения с установленным флагом, который указан.
LARGER <n>                     сообщения с размером [RFC-822], превышающим заданное число октетов.
NEW                                  сообщения с установленным флагом \Recent, но без флага \Seen (эквивалент RECENT
UNSEEN – получено недавно и не прочитано)". NOT <search-key>              сообщения, не соответствующие заданному ключу поиска.
OLD                                   сообщения без флага \Recent (функциональный эквивалент NOT RECENT).
ON <date>                          сообщения, для которых внутренняя дата совпадает с заданной.
OR <search-key1> <search-key2> сообщения, соответствующие хотя бы одному ключу поиска. RECENT                            сообщения с флагом \Recent.
SEEN                                 сообщения с флагом \Seen flag.
SENTBEFORE <date> сообщения, для которых дата [RFC-822] Date: раньше указанной. SENTON <date>                 сообщения, для которых дата [RFC-822] Date: совпадает с указанной.
SENTSINCE <date>            сообщения, для которых дата [RFC-822] Date: совпадает с указанной или позже ее.
SINCE <date>                     сообщения, для которых внутренняя дата совпадает с указанной или позже ее.
SMALLER <n>                   сообщения размером [RFC-822] меньше указанного числа октетов.
SUBJECT <string>              сообщения, содержащие указанную строку в поле SUBJECT конверта.
TEXT <string>                    сообщения, содержащие указанную строку в заголовке или теле письма.
TO <string>                        сообщения, содержащие указанную строку в поле TO конверта.
UID <message set>              сообщения с уникальными идентификаторами, соответствующими указанному набору.
UNANSWERED                 сообщения без флага \Answered.
UNDELETED                     сообщения без флага \Deleted.
UNDRAFT                         сообщения без флага \Draft.
UNFLAGGED                    сообщения без флага \Flagged.
UNKEYWORD <flag> сообщения без указанного ключом флага. UNSEEN                            сообщения без флага \Seen.
Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
6.4.5. Команда FETCH
Аргументы: набор сообщений, имена элементов данных в сообщениях
Отклик: непомеченный отклик FETCH
Результат: OK – успешная выборка
NO – неудача при попытке выборки
BAD - команда не поддерживается или некорректны аргументы
Команда FETCH отыскивает данные, связанные с сообщениями в почтовом ящике. Отыскиваемые данные могут зада­ваться с помощью атома или списка в скобках.
В настоящее время поддерживаются выборки для следующих типов данных:
ALL                   макроопределение для (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
BODY                нерасширяемая форма BODYSTRUCTURE.
BODY[<section>]<<partial>> текст в конкретной секции тела сообщения. Спецификация секций сообщения (если она присутствует) задается номером или одним из идентификаторов: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, TEXT. Пустая спецификация секции задает поиск по всему сообще­нию, включая заголовки.
Каждое сообщение имеет по крайней мере один номер секции (части сообщения). Сообщения, не от­носящиеся к [MIME-IMB], и сообщения [MIME-IMB] без инкапсуляции имеют только часть 1. В многосекционных сообщениях каждая часть имеет порядковый номер (начиная с 1). Если отдель-
17
ная часть имеет тип сообщения или содержит в себе отдельные части, нумерация должна задаваться двумя числами (через запятую) – сначала номер основной части, затем - вложенной. Части типа MESSAGE/RFC822 также имеют номера вложенных частей, указывающие на части тела сообщения. Идентификаторы 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] для этой части. Идентификатор TEXT указывает на текст тела сообщений без заголовка [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 Возможна выборка подстроки обозначенного текста, осуществляемая путем добавления конструкции <позиция первого желаемого. максимальное число возвращаемых октетов> к спе­цификатору выборки. Если стартовый октет указывает за пределы текста, возвращается пустая стро­ка. Любая попытка частичной выборки за пределами текста усекается. Частичная выборка с позиции всегда дает результат, даже если происходит усекновение9.
Отметим, что выборка подстроки для HEADER.FIELDS или HEADER.FIELDS.NOT рассчитывается после выделения из заголовка нужных полей.
Флаг \Seen устанавливается явно; если это ведет к изменению флагов, их следует включать как часть откликов FETCH.
BODY.PEEK[<section>]<<partial>> Другая форма BODY[<section>] , не устанавливающая явно флаг \Seen.
BODYSTRUCTURE Структура [MIME-IMB] в теле сообщения, рассчитываемая сервером путем разбора полей заго­ловка [MIME-IMB] в заголовке [RFC-822] и заголовков [MIME-IMB].
ENVELOPE Структура конверта в сообщении, рассчитываемая сервером путем разбора заголовка [RFC-822] на составные части с установкой при необходимости принятых по умолчанию значений полей.
FAST                 Макроопределение для (FLAGS INTERNALDATE RFC822.SIZE)
FLAGS               Флаги, установленные для сообщения.
FULL                 Макроопределение для (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
INTERNALDATE Внутренняя дата сообщения.
RFC822              Функциональный эквивалент BODY[], отличающийся синтаксисом непомеченных данных FETCH
(возвращается RFC822).
RFC822.HEADER Функциональный эквивалент BODY.PEEK[HEADER] , отличающийся синтаксисом непомеченных данных FETCH (возвращается RFC822.HEADER).
RFC822.SIZE The [RFC-822] size of the message.
RFC822.TEXT Функциональный эквивалент BODY[TEXT], отличающийся синтаксисом непомеченных данных FETCH (возвращается RFC822.TEXT).
UID                    Уникальный идентификатор сообщения.
Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 2 FETCH ....
9 Это означает, что BODY[]<0.2048> для сообщения размером в 1500 октетов будет возвращать BODY[]<0> с буквальным текстом размером 1500 октетов, а не просто BODY[].
http://rfc.com.ru                                                                         18                                                   http://rfc.com.ru
S: * 3 FETCH .... S: * 4 FETCH .... S: A654 OK FETCH completed
6.4.6. Команда STORE
Аргументы: набор сообщений, значение для элемента данных сообщения Отклик: непомеченный отклик FETCH Результат: OK – успешная запись
NO - неудача
BAD - команда не поддерживается или некорректны аргументы Команда STORE изменяет данные для указанного сообщения в почтовом ящике. Обычно STORE возвращает изме­ненное значение данных в непомеченном отклике FETCH. Суффикс ".SILENT"10 в имени элемента данных предот­вращает возврат непомеченных откликов FETCH и серверу следует, что клиент способен сам определить обновленное значение или оно не требуется клиенту. В настоящее время могут изменяться следующие данные:
FLAGS <flag list>                  замена флагов сообщения; новые значения флагов возвращаются в непомеченном откли-
ке FETCH. FLAGS.SILENT <flag list> эквивалент FLAGS, но без возврата новых флагов. +FLAGS <flag list>                добавление флага; новые значения флагов возвращаются в непомеченном отклике
FETCH. +FLAGS.SILENT <flag list> эквивалент +FLAGS, но без возврата новых флагов. -FLAGS <flag list>                 удаление флага для сообщения; новые значения флагов возвращаются в непомеченном
отклике FETCH. -FLAGS.SILENT <flag list> эквивалент -FLAGS, но без возврата новых флагов. Пример: 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
6.4.7. Команда COPY
Аргументы: набор сообщений, имя почтового ящика Отклик: для этой команды не существует специфических откликов Результат: OK – успешное копирование
NO – неудача
BAD - команда не поддерживается или некорректны аргументы Команда COPY копирует указанные сообщения в конец заданного почтового ящика. Для копии следует сохранять внутреннюю дату и значения флагов.
Если указанного почтового ящика не существует, серверу следует возвращать сообщение об ошибке и не следует ав­томатически создавать почтовый ящик. Если нет очевидной невозможности создания почтового ящика с таким име­нем, сервер должен передавать код [TRYCREATE] в качестве префикса к тексту помеченного отклика NO. Это под­сказывает клиенту возможность попытки создания почтового ящика с помощью команды CREATE и после этого ис­пользовать команду COPY, если почтовый ящик удалось создать.
При любой ошибке команды COPY сервер должен восстановить исходное состояние почтового ящика. Пример: C: A003 COPY 2:4 MEETING S: A003 OK COPY completed
6.4.8. Команда UID Аргументы: имя команды, аргументы команды Отклик: непомеченный отклик FETCH, SEARCH Результат: OK – успешное завершение
NO - ошибка
BAD - команда не поддерживается или некорректны аргументы Команда UID имеет две формы. В первом варианте используются команды COPY, FETCH, STORE и аргументы соот­ветствующей команды. Однако в качестве номеров при указании набора сообщений используются уникальные иден­тификаторы сообщений, а не их порядковые номера. Во второй форме команда UID использует команду SEARCH и ее набор аргументов. Интерпретация аргументов такая же, как для команды SEARCH, однако вместо порядковых номе­ров сообщений возвращаются их уникальные идентификаторы (UID). Например, команда UID SEARCH 1:100 UID 443:557 будет возвращать уникальные идентификаторы, соответствующие пересечению сообщений с порядковыми номерами от 1 до 100 и UID в диапазоне443:557.
Допустимо включение диапазона сообщений, однако не гарантируется, что уникальные идентификаторы для диапазо­на образуют непрерывную последовательность. Несуществующие уникальные идентификаторы в заданном диапазоне будут игнорироваться без генерации сообщений об ошибках.
Число после "*" в непомеченном отклике FETCH всегда указывает порядковый номер сообщения, а не его уникаль­ный идентификатор (даже в откликах на команду UID). Однако серверы должны явно включать значения UID как
10 Независимо от наличия суффикса ".SILENT" серверу следует передавать непомеченный отклик FETCH при изменении флагов внешним источником.
http://rfc.com.ru                                                              19                                                             http://rfc.com.ru
часть откликов 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
6.5. Команды клиента – экспериментальные/расширения
6.5.1. Команда X<atom> Аргументы: зависит от реализации Отклик: зависит от реализации Результат: OK – успешное завершение NO - неудача
BAD - команда не поддерживается или некорректны аргументы Все команды с префиксом X являются экспериментальными. Команды, которые не включены в данную специфика­цию, ее расширения/пересмотры в стандартах и предложенных стандартах или одобренные IESG экспериментальные протоколы, должны использовать префикс X.
Все добавляемые экспериментальными командами непомеченные отклики должны начинаться с префикса X. Для сер­веров недопустима передача таких непомеченных откликов, если клиент не использует связанных эксперименталь­ных команд. Пример: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay
7. Отклики сервера
Отклики сервера делятся на три типа – информация о состоянии, данные и запросы на продолжение команд. Инфор­мация, содержащаяся в откликах, помечена словом "Содержимое:" при описании отклика (но не его синтаксиса). Син­таксис откликов описан в главе 9. Формальный синтаксис.
Клиент должен сохранять постоянную готовность к получению откликов от сервера.
Статусные отклики могут быть отмеченными (tagged) или неотмеченными (untagged). Отмеченные отклики показы­вают результат (OK, NO, BAD) выполнения команды клиента и включают тег, соответствующий команде. Все данные и некоторые статусные отклики передаются без тегов. Непомеченные отклики идентифицируются марке­ром "*" взамен тега. Непомеченные статусные отклики содержат приветствия сервера, или данные о состоянии, кото­рые не показывают завершения команд (например, уведомление об отключении сервера - shutdown alert). В силу исто­рических причин неотмеченные статусные отклики сервера называют также unsolicited data (представленные без за­проса данные), хотя, строго говоря, они не являются таковыми.
Некоторые данные от сервера должны записываться клиентом – такие случаи явно указываются в описании данных. Данные этого типа содержат критически важную информацию, которая влияет на интерпретацию последующих ко­манд и откликов (например, обновлений о создании или удалении сообщений).
Другие типы данных следует сохранять для использования в будущем; если клиенту не нужно записывать эти данные или смысл записи данных неясен (например, отклик SEARCH при отсутствии выполняемых команд SEARCH), такие данные следует игнорировать.
Непомеченные данные по инициативе сервера могут передаваться, когда соединение IMAP находится в состоянии se­lected. В этом состоянии сервер проверяет почтовый ящик на предмет появления в нем новых сообщений в результате выполнения команд. Обычно это является частью выполнения всех команд, следовательно, команда NOOP также инициирует проверку наличия новых сообщений. Если такие сообщения найдены, сервер передает непомеченные от­клики EXISTS и RECENT, отражающие новый размер почтового ящика. Серверам, поддерживающим множественный доступ к почтовому ящику, следует также передавать подходящие непомеченные отклики FETCH и EXPUNGE, если другой агент изменяет состояние любого из флагов сообщений или удаляет какое-либо сообщение. Запросы на продолжение команд используют маркер "+" взамен тега. Такие отклики передаются сервером для инди­кации восприятия сервером неполной команды клиента и готовности к получению оставшейся части команды.
7.1. Отклики сервера - состояние
К статусным относятся отклики OK, NO, BAD, PREAUTH и BYE. Отклики OK, NO, BAD могут передаваться с тегами или без таковых, отклики PREAUTH и BYE всегда являются неотмеченными.
Статусные отклики могут включать дополнительно «код отклика» (response code), состоящий из данных в квадрат­ных скобках в форме атома, за которыми может следовать пробел и аргументы. Код отклика содержит дополнитель­ную информацию или коды состояния для клиентской программы (сверх результата OK/NO/BAD) и определяются для тех случаев, когда клиент на основе этой информации может предпринять дополнительные действия. В настоящем документе определены следующие коды откликов:
ALERT                        текст для пользователя, содержащий специальное предупреждение, которое должно предосте-
речь пользователя понятным ему способом. NEWNAME                 с последующим именем нового почтового ящика. Команды SELECT и EXAMINE будут давать
ошибку в связи с тем, что указанный почтовый ящик больше не существует в результате смены
http://rfc.com.ru                                                                         20                                                   http://rfc.com.ru
имени. Это является советом клиенту повторить операцию SELECT или EXAMINE с новым именем почтового ящика.
PARSE                         понятный пользователю текст, представляющий ошибку при разборе заголовка [RFC-822] или
заголовков [MIME-IMB] в сообщении.
PERMANENTFLAGS вместе с последующим списком в скобках показывает какие из известных флагов клиент может поменять окончательно. Флаги, включенные в непомеченный отклик FLAGS, но отсутствую­щие в списке PERMANENTFLAGS нельзя изменить окончательно. Если клиент пытается со­хранить с помощью команды STORE флаги, не указанные в списке PERMANENTFLAGS, сер­вер будет отвергать команду, возвращая отклик NO или сохранит флаги только до конца теку­щего сеанса. Список PERMANENTFLAGS может включать также специальный флаг \*, кото­рый показывает возможность создания новых ключевых слов за счет попытки сохранения этих флагов в почтовом ящике.
READ-ONLY               почтовый ящик выбран в режиме «только для чтения» или доступ после выбора в режиме
«чтения-записи» был изменен на read-only.
READ-WRITE             почтовый ящик выбран для чтения и записи или после выбора в режиме «только чтение» дос-
туп был изменен на read-write.
TRYCREATE               неудачная попытка использования APPEND или COPY в результате отсутствия указанного
почтового ящика (в отличие от других ошибок); этот отклик является советом клиенту сначала создать ящик с помощью команды CREATE, а потом повторить попытке.
UIDVALIDITY            вместе со следующим десятичным числом показывает уникальный идентификатор корректно-
сти.
UNSEEN                     вместе со следующим десятичным числом показывает количество сообщений без флага \Seen.
Дополнительные коды откликов, используемые клиентами и серверами, должны начинаться с префикса "X", пока они
не будут включены в новый вариант спецификации этого протокола. Клиентам следует игнорировать непонятные им
коды откликов.
7.1.1. Отклик OK
Содержимое: необязательный текст для пользователя
Отклик OK показывает информационное сообщение от сервера. Отклик с тегом говорит об успешном завершении указанной тегом команды. В отклик может дополнительно включаться текст, понятный пользователю. Отклик без те­га указывает на информационное сообщение – природа информации может указываться кодом отклика. Отклики без тега используются также как одно из трех возможных приветствий при организации соединения, показывая, что ау­тентификации еще не прошла и требуется команда LOGIN. Пример: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
7.1.2. Отклик NO
Содержимое: необязательный текст для пользователя
Отклик NO говорит о возникновении ошибки на сервере. Отклик с тегом говорит о неудачной попытке выполнения указанной тегом команды. Неотмеченная форма используется как предупреждение о том, что выполнение команды еще не завершено. В отклик может добавляться понятный пользователю текст. Пример: C: A222 COPY 1:2 owatagusiam
S:
* NO
S:
A222
C:
A223
S:
* NO
S:
* NO
S:
A223
Disk is 98% full, please delete unnecessary data
OK COPY completed
COPY 3:200 blurdybloop
Disk is 98% full, please delete unnecessary data
Disk is 99% full, please delete unnecessary data
NO COPY failed: disk is full
7.1.3. Отклик BAD
Содержимое: необязательный текст для пользователя
Отклик BAD говорит об ошибке на сервере. Отклики с тегом сообщают об ошибке протокольного уровня при обра­ботке сервером указанной тегом команды. Непомеченные отклики показывают ошибки протокольного уровня, кото­рые не удалась связать с определенной командой. Отклик может содержать текст, понятный пользователю. Пример: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
7.1.4. Отклик PREAUTH
Содержимое: необязательный текст для пользователя Отклики PREAUTH всегда передаются без тега и служат в качестве одного из трех приветствий, передаваемых серве-
http://rfc.com.ru                                                              21                                                             http://rfc.com.ru
ром при организации соединения. Отклик показывает, что аутентификация уже успешно проведена внешними силами
и нет необходимости использовать команду LOGIN.
Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith
7.1.5. Отклик BYE
Содержимое: необязательный текст для пользователя
Отклики BYE всегда передаются без тега и показывают, что сервер закрывает соединение. Для пользователя в отклик
может добавляться текстовое сообщение. Отклик BYE может передаваться в четырех случаях:
1)    Часть нормальной процедуры завершения сеанса. Сервер будет закрывать соединение после передачи поме­ченного отклика OK для команды LOGOUT.
2)    Часть анонса неожиданного завершения работы сервера (panic shutdown). Соединение закрывается незамед­лительно.
3)    Анонс завершения сеанса по тайм-ауту. Соединение закрывается незамедлительно.
4)    Одно из трех возможных приветствий при организации соединения, показывающее, что сервер не желает от­крывать сеанс для данного клиента. Соединение закрывается незамедлительно.
Различие между BYE при нормальной процедуре LOGOUT (случай 1) и в результате сбоя или отказа (остальные три ситуации) состоит в том, что в трех последних случаях сеанс закрывается немедленно. Пример: S: * BYE Autologout; idle for too long
7.2. Отклики сервера состояние сервера и почтового ящика
Эти отклики всегда передаются без тегов и служат для передачи клиенту данных о состоянии сервера и почтового ящика. Большинство этих откликов возвращается в результате вызова одноименных команд.
7.2.1. Отклик CAPABILITY Содержимое: список возможностей
Отклик CAPABILITY возвращается в результате использования команды CAPABILITY. Список возможностей со­держит поддерживаемые сервером возможности с использованием пробела в качестве разделителя. Список возможно­стей должен включать атом IMAP4rev1.
Имена возможностей, начинающиеся с AUTH=, показывают, что сервер поддерживает тот или иной механизм аутен­тификации.
Другие имена возможностей показывают, что сервер поддерживает расширения, пересмотренные варианты или заме­ну протокола IMAP4rev1. Отклики сервера должны соответствовать данному документу, пока клиент не использует команд, связанных с соответствующими расширенными возможностями.
Имена возможностей должны быть стандартными расширениями, пересмотрами или заменами протокола IMAP4rev1, зарегистрированными в IANA, если они не начинаются с префикса "X".
Клиентам не следует требовать поддержки имен, отличающихся от IMAP4rev1 и они должны игнорировать неиз­вестные имена возможностей. Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
7.2.2. Отклик LIST
Содержимое: атрибуты имени, разделитель уровней иерархии, имя
Отклик LIST возвращается в результате вызова команды LIST и содержит одно имя, соответствующее спецификации в команде LIST. На одну команду LIST может возвращаться множество откликов LIST. Определены 4 атрибута имен: \Noinferiors для этого уровня иерархии невозможно существование любых дочерних уровней – их нет сейчас и не
может быть в будущем. \Noselect это имя нельзя использовать как выбранный почтовый ящик. \Marked почтовый ящик отмечен сервером как «интересный» - возможно он содержит сообщения, добавленные с
момента его предыдущего выбора. \Unmarked почтовый ящик не содержит сообщений, добавленных после предыдущего обращение к нему. Если сервер не может определить «интересен» ли данный почтовый ящик, или имя имеет атрибут \Noselect, серверу не следует передавать атрибуты \Marked или \Unmarked.
Разделитель уровней иерархии представляет собой символ, используемый в качестве границы между соседними уров­нями иерархии имен почтовых ящиков. Клиент может использовать разделитель для создания дочерних почтовых ящиков или поиска других уровней в иерархии имен. На всех уровнях иерархии должен использоваться одинаковый разделитель. Значение NIL в качестве разделителя уровней означает отсутствие иерархии (плоская модель именова­ния).
Имена представляются в иерархии слева направо и должны быть приемлемы для использования в командах LIST и LSUB. Если не указан атрибут \Noselect имя также должно быть корректно как аргумент для команд, принимающих в качестве аргумента имя почтового ящика (например, SELECT). Пример: S: * LIST (\Noselect) "/" ~/Mail/foo
7.2.3. Отклик LSUB
Содержимое: атрибуты имени, разделитель уровней иерархии, имя
Отклик LSUB возвращается в результате использования команды LSUB и содержит одно имя, соответствующее спе­цификации в команде LSUB. На одну команду LSUB может возвращаться множество откликов LSUB. Формат данных идентичен формату в откликах LIST. Пример: S: * LSUB () "." #news.comp.mail.misc
22
7.2.4 Отклик STATUS
Содержимое: имя, заключенный в скобки список состояний
Отклик STATUS возвращается в результате вызова клиентом команды STATUS и содержит имя почтового ящика, со­ответствующее спецификации в команде STATUS, а также информацию о состоянии этого почтового ящика. Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
7.2.5. Отклик SEARCH Содержимое: 0 или более чисел
Отклики SEARCH возвращаются в результате вызова команд SEARCH или UID SEARCH. Возвращаемые числа со­держат порядковые номера (команда SEARCH) или уникальные идентификаторы (UID SEARCH) удовлетворяющих критериям поиска сообщений. В качестве разделителя используется символ пробела. Пример: S: * SEARCH 2 3 6
7.2.6. Отклик FLAGS
Содержимое: заключенный в скобки список флагов
Отклики FLAGS возвращаются в результате использования клиентом команд SELECT или EXAMINE и содержат за­ключенный в скобки список флагов (как минимум, системные флаги), которые применимы к указанному почтовому ящику. Отличные от системных флаги используются в зависимости от реализации сервера. Обновления по сравнению с откликом FLAGS должны записываться клиентом. Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
7.3. Отклики сервера – размер почтового ящика
Отклики этой группы всегда передаются без тегов и показывают клиенту изменения размера почтового ящика. Вслед за маркером "*" сразу же указывается число сообщений в почтовом ящике.
7.3.1. Отклик EXISTS Содержимое: отсутствует
Отклики EXISTS показывают число сообщений в почтовом ящике и передаются в результате использования команд SELECT и EXAMINE или при изменении почтового ящика (например, доставка нового письма). Обновления числа сообщений должны записываться клиентом. Пример: S: * 23 EXISTS
7.3.2. Отклик RECENT Содержимое: отсутствует
Отклики RECENT говорят о числе сообщений с флагом \Recent и возвращаются в результате команд SELECT и EXAMINE или при изменении размера почтового ящика (например, в результате доставки нового письма). Отметим, что непрерывность порядковых номеров свежих сообщений не гарантируется – они не обязательно занима­ют подряд n старших номеров в почтовом ящике (значение n возвращается откликом RECENT). Примером ситуации отсутствия такой непрерывности может быть одновременная работа множества клиентов работают с одним почтовым ящиком (первая уведомляемая сессия будет видеть свежие сообщения, остальные могут этого и не увидеть), а также случаи изменения порядка сообщений агентами, отличными от IMAP.
Надежными способами идентификации свежих сообщений являются только просмотр флагов и поиск или флага \Recent или использование команды SEARCH RECENT. Обновление откликов RECENT должно записываться клиентом. Пример: S: * 5 RECENT
7.4. Отклики сервера – сообщение о состоянии
Статусные отклики всегда передаются без тегов. Отклики часто передаются сервером в результате использования клиентом одноименной с откликом команды. Сразу после маркера "*" в откликах содержится число, указывающее по­рядковый номер сообщения.
7.4.1. Отклик EXPUNGE Содержимое: отсутствует
Отклик EXPUNGE информирует об уничтожении сообщения с указанным порядковым номером. Порядковый номер каждого следующего за уничтоженным сообщения уменьшается на 1 и это уменьшение отражается в нумерации для последующих откликов (включая и другие непомеченные отклики EXPUNGE).
Как результат правила немедленного уменьшения номеров, порядковые номера в последовательных откликах EXPUNGE зависят от порядка уничтожения сообщений (от старших номеров к младшим или наоборот). Например, при удалении последних 5 сообщений из ящика с 9 письмами, начиная с младшего номера, сервер будет передавать 5 последовательных непомеченных откликов EXPUNGE для сообщения с порядковым номером 5, тогда как при удале­нии со старшего номера отклики EXPUNGE будут возвращаться для сообщений 9, 8, 7, 6, 5.
Недопустимо передавать отклик EXPUNGE при отсутствии обрабатываемых команд или при обработке FETCH, STORE, SEARCH. Это правило позволяет избежать потери синхронизации порядковых номеров сообщений между клиентом и сервером.
Обновления откликов EXPUNGE должны записываться клиентом. Пример: S: * 44 EXPUNGE
23
7.4.2. Отклик FETCH Содержимое: данные сообщения
Отклик FETCH возвращает клиенту данные о сообщении. Данные представляются в виде пар имя – значение, заклю­ченных в скобки. Этот отклик возвращается по команде в результате команд FETCH и STORE или по инициативе сер­вера (например, в результате обновления флагов). Настоящая спецификация определяет следующие типы данных: BODY         форма BODYSTRUCTURE без расширения данных.
BODY[<section>]<<origin_octet>> Строковое выражение содержимого тела указанной части сообщения. Клиенту сле­дует интерпретировать строку в соответствии с типом транспортного кодирования содержимого, типом и подтипом тела.
Если указан начальный октет, эта строка является подстрокой всего содержимого тела, начиная с началь­ного октета. Это значит, что BODY[]<0> можно усечь, а BODY[] усекать недопустимо. Допустимо использование 8-битовых текстовых данных, если идентификатор [CHARSET] является ча­стью заключенного в скобки списка параметров тела для этой секции. Отметим, что заголовки (специфи­каторы частей HEADER и MIME или части заголовка MESSAGE/RFC822) должны быть 7-битовыми (8-битовые символы недопустимы в заголовках). Отметим также, что в данные заголовка всегда включается пустая строка в конце.
Нетекстовые (бинарные) данные должны передаваться с использованием преобразования в текст (напри­мер, BASE64) до передачи клиенту. Для восстановления исходных двоичных данных клиент должен де­кодировать строку транспортного кодирования.
BODYSTRUCTURE заключенный в скобки список, который описывает структуру тела сообщения [MIME-IMB]. Этот список создается сервером в результате разбора полей заголовка [MIME-IMB] и включения при необходимости принятых по умолчанию значений. Например, простое текстовое сообще­ние из 48 строк и 2279 октетов имеет структуру тела: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48). При наличии множества частей они указываются вложенными списками в скобках. Вместо типа тела первого элемента заключенного в скобки списка помещается вложенное тело. Вторым элементов списка в скобках является подтип multipart (mixed, digest, parallel, alternative и т. п.). Например, сообщение из 2 частей, содержащее текст и данные в формате BASE64 может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED"))
После подтипа multipart следует расширение данных. Это расширение никогда не возвращается в выбор­ках BODY но может содержаться в выборках BODYSTRUCTURE. При наличии расширенных данных они должны размещаться в приведенном ниже порядке. The extension data of a multipart body part are in the following order: body parameter parenthesized list
Заключенный в скобки список пар «атрибут-значение» (например, ("foo" "bar" "baz" "rag"), где "bar" является значением атрибута "foo", а "rag" – значением "baz") в соответствии с [MIME-IMB]. body disposition
Заключенный в скобки список, который содержит строку типа размещения, за которой следует за­ключенный в скобки список пар «атрибут размещения – значение». Типы размещения и имена атри­бутов будут определены в будущей версии предложенного стандарта [DISPOSITION]. body language
Строка или заключенный в скобки список, указывающие язык тела в соответствии с [LANGUAGE-TAGS]. Все последующие данные еще не определены в данной версии протокола. Такие расширения данных мо­гут содержать 0 или более значений NIL, строк, чисел и потенциально вложенных заключенных в скобки списков таких данных. Реализации клиентов, использующие выборки BODYSTRUCTURE должны быть готовы к восприятию расширенных данных такого типа. Для серверов недопустима передача таких рас­ширений, пока они не будут определены при пересмотре данного протокола.
Базовые поля для тел, не содержащих множества частей (non-multipart body) имеют следующий порядок: body type
Строка, указывающая название типа среды в соответствии с [MIME-IMB]. body subtype
Строка, указывающая имя подтипа в соответствии с [MIME-IMB]. body parameter parenthesized list
Заключенный в скобки список пар «атрибут-значение» (например, ("foo" "bar" "baz" "rag"), где "bar" является значением атрибута "foo", а "rag" – значением "baz") в соответствии с [MIME-IMB]. body id
Строка, указывающая идентификатор содержимого в соответствии с [MIME-IMB]. body description
Строка, описывающая содержимое в соответствии с [MIME-IMB]. body encoding
Строка, указывающая транспортное кодирование в соответствии с [MIME-IMB]. body size
Число, показывающее размер тела в октетах. Отметим, что это число показывает размер для транс­портного кодирования, а не размер после декодирования.
http://rfc.com.ru                                                                         24                                                   http://rfc.com.ru
Тело типа MESSAGE или подтипа RFC822 содержит сразу же после основных полей структуру конверта, структуру тела и размер текстовых строк инкапсулированного сообщения.
Тело типа TEXT содержит сразу же после основных полей размер и собственно тело в форме текстовых строк. Отметим, что поле размера задается для транспортного кодирования, а не для содержимого после декодирования.
После основных полей и перечисленных выше полей, связанных с конкретными типами сообщений, сле­дуют поля расширения. Эти поля никогда не возвращаются в выборке BODY, но могут возвращаться вы­боркой BODYSTRUCTURE. При использовании расширенных данных они должны размещаться в приве­денном ниже порядке (для тел, не содержащих множества частей): body MD5
Строка, дающая значение MD5 в соответствии с определением [MD5]. body disposition
Список в скобках таким же содержимым и функциями, как расположение тела для multipart body part. body language
Строка или заключенный в скобки список, указывающие язык тела сообщения в соответствии с [LANGUAGE-TAGS].
Все последующие расширения данных еще не определены в этой версии протокола и описываются как данные multi­part-расширений.
ENVELOPE заключенный в скобки список, описывающий структуру конверта в сообщении. Этот список создается сервером путем разбора заголовка [RFC-822] на составные части и включения при необходимости приня­тых по умолчанию значений. Поля в структуре конверта располагаются в следующем порядке: date, sub­ject, from, sender, reply-to, to, cc, bcc, in-reply-to, and message-id. Поля date, subject, in-reply-to и message-id представляют собой текстовые строки, поля from, sender, reply-to, to, cc, bcc – заключенные в скобки спи­ски адресных структур.
Адресная структура представляет собой заключенный в скобки список, который описывает адрес элек­тронной почты. Поля структуры располагаются в следующем порядке: personal name, [SMTP] at-domain-list (source route), mailbox name, host name.
Групповой синтаксис [RFC-822] указывается специальной формой адресной структуры, в которой имя хоста имеет значение NIL. Если имя почтового ящика также имеет значение NIL, это говорит о маркере окончания группы (точка с запятой в синтаксисе RFC 822). Если имя почтового ящика отличается от NIL, это говорит о маркере начала группы и поле имени почтового ящика содержит имя группы. Любые неприменимые поля конверта или адресной структуры содержат значение NIL. Отметим, что сер­вер должен по умолчанию брать значения полей reply-to и sender из поля from; предполагается, что кли­ент не обязан их знать.
FLAGS заключенный в скобки список флагов, установленных для сообщения.
INTERNALDATE строка, представляющая внутреннюю дату сообщения.
RFC822 эквивалент BODY[].
RFC822.HEADER эквивалент BODY.PEEK[HEADER].
RFC822.SIZE число, выражающее размер [RFC-822] для сообщения.
RFC822.TEXT эквивалент BODY[TEXT].
UID             число, выражающее уникальный идентификатор сообщения.
Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
7.5. Отклики сервера – запрос продолжения команды
Запросы на продолжение команды указываются маркером "+" взамен тега. Эта форма откликов показывает, что сервер готов воспринять от клиента продолжение команды. Остальная часть отклика представляет собой текстовую строку. Этот отклик используется в команде AUTHORIZATION для передачи сервером данных клиенту и запроса дополни­тельных данных от клиента. Этот же отклик применяется с любой командой, аргументом которой является литерал. Клиенту не разрешается передавать октеты литералов, пока сервер не укажет готовность к их приему. Это позволяет серверу построчно обрабатывать команды и отвергать ошибки. Оставшаяся часть команды, включая завершающую последовательность CRLF передается в форме октетов. При наличии дополнительных аргументов они должны отде­ляться пробелом. Пример: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
8. Пример соединения IMAP4rev1
Ниже приведен пример соединения IMAP4rev1 (длинные строки разделены на части только в целях форматирования).
S:       * OK IMAP4rev1 Service Ready
C:       a001 login mrc secret
S:       a001 OK LOGIN completed
C:       a002 select inbox
http://rfc.com.ru                                                              25                                                             http://rfc.com.ru
* 18 EXISTS
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* 2 RECENT
* OK [UNSEEN 17] Message 17 is the first unseen message
* OK [UIDVALIDITY 3857529045] UIDs valid a002 OK [READ-WRITE] SELECT completed a003 fetch 12 full
* 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 WG mtg summary and minutes"
("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" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL "<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) a003 OK FETCH completed a004 fetch 12 body[header]
* 12 FETCH (BODY[HEADER] {350} Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) From: Terry Gray <gray@cac.washington.edu> Subject: IMAP4rev1 WG mtg summary and minutes To: imap@cac.washington.edu
cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU> Message-Id: <B27397-0100000@cac.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
)
a004 OK FETCH completed
a005 store 12 +flags \deleted
* 12 FETCH (FLAGS (\Seen \Deleted)) a005 OK +FLAGS completed a006 logout
* BYE IMAP4rev1 server terminating connection a006 OK LOGOUT completed
9. Формальный синтаксис
В приведенной ниже спецификации синтаксиса используется расширенная форма Бэкуса-Наура (BNF), заданная в [RFC-822], с единственным исключением – символ-ограничитель (delimiter), используемый с "#" порождает один про­бел (SPACE), а не одну или несколько запятых.
При наличии альтернативных или дополнительных правил, когда последующее правило отменяет действие указанно­го ранее правила, приоритет должно иметь правило, указанное раньше. Например, "\Seen" при рассмотрении флагов дает имя флага \Seen, а не расширение flag_extension, несмотря на возможность разборки "\Seen" как flag_extension. Некоторые (но не все) случаи использования этого правила отмечены ниже при описании синтаксиса. Если явно не указано иное, регистр символов не принимается во внимание. Строчные и прописные символы исполь­зуются в описаниях синтаксиса для лучшего восприятия. Реализации должны трактовать эти строки независимо от ре­гистра символов.
address                   ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox SPACE addr_host ")"
addr_adl ::= nstring
;; сохраняет [RFC-822] route-addr (если оно не равно NIL) addr_host ::= nstring
;; NIL указывает на групповой синтаксис [RFC-822], в остальных случаях
;; содержит доменное имя [RFC-822] addr_mailbox ::= nstring
;; NIL указывает конец группы [RFC-822]; в остальных случаях содержит имя
;; группы [RFC-822] (если addr_host = NIL) или локальную часть [RFC-822] addr_name ::= nstring
;; фраза из почтового ящика [RFC-822] или NIL
alpha                        :
"A"
/
"В"
/
"С"
/
"D"
/
"Е"
/
"р"
/
"G"
/
"Н"
/
"I"
/
"J"
/
"К"
/
"L"
/
"М"
/
"N"
/
"0"
/
"P"
/
"Q"
/
"R"
/
"S"
/
П гп П
/
"U"
/
"V"
/
"W"
/
"X"
/
пуп
/
"Z"
/
"a"
/
"Ь"
/
"с"
/
"d"
/
"е"
/
П .f П
/
"q"
/
"h"
/
П -j п
/
п _: п
/
"к"
/
п 1 п
/
"m"
/
"п"
/
"о"
/
"p"
/
"q"
/
П — П
/
"s"
/
"t"
/
"u"
/
"v"
/
"w"
/
"х"
/
"у"
/
"z"
append
astring
atom
ATOM_CHAR
atom_specials
authenticate
регистр символов различается = "APPEND" SPACE mailbox [SPACE flag_list] [SPACE date_time] SPACE literal = atom / string = 1*ATOM_CHAR
= <any CHAR except atom_specials>
= "(" / ")" / "{" / SPACE / CTL / list_wildcards / quoted_specials = "AUTHENTICATE" SPACE auth_type *(CRLF base64)
26
auth_type
base64
base64_char
base64_terminal
body
body_extension
atom определяется в [IMAP-AUTH]
*(4base64_char) [base64_terminal]
alpha / digit / "+" / "/"
(2base64_char "==") / (3base64_char "=")
"(" body_type_1part / body_type_mpart ")"
nstring / number / "(" 1#body_extension ")" Будущее расширение. Реализации клиентов должны воспринимать поля body_extension. Для реализаций серверов недопустимо генерировать поля body_extension за исключением тех, которые будут определены в будущих стандартных (или standards-track) вариантах этой спецификации
body_fld_md5 [SPACE body_fld_dsp [SPACE body_fld_lang [SPACE
1#body_extension]]] недопустимо возвращать нерасширяемые выборки "BODY"
body_fld_param [SPACE body_fld_dsp SPACE body_fld_lang [SPACE
1#body_extension]] недопустимо возвращать нерасширяемые выборки "BODY"
body_fld_param SPACE body_fld_id SPACE body_fld_desc SPACE body_fld_enc
SPACE body_fld_octets
nstring
"(" string SPACE body_fld_param ")" / nil
(<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ "QUOTED-PRINTABLE") <">) /
string
nstring
nstring / "(" 1#string ")"
number
nstring
number
"(" 1#(string SPACE string) ")" / nil
(body_type_basic / body_type_msg / body_type_text) [SPACE body_ext_1part]
media_basic SPACE body_fields субтипом MESSAGE недопустимо задавать "RFC822"
1*body SPACE media_subtype [SPACE body_ext_mpart]
media_message SPACE body_fields SPACE envelope SPACE body SPACE
body_fld_lines
media_text SPACE body_fields SPACE body_fld_lines
"AUTH=" auth_type / atom новые возможности должны начинаться с "X" или должны быть зарегистрированы в IANA как стандарт или предложенный стандарт
"CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" [SPACE 1#capability] серверы IMAP4rev1, предлагающие совместимость с RFC 1730, должны указывать IMAP4 как первую возможность.
<any 7-bit US-ASCII character except NUL, 0x01 - 0x7f>
<any 8-bit octet except NUL, 0x01 - 0xff>
tag SPACE (command_any / command_auth / command_nonauth / command_select)
CRLF доступность команд зависит от состояния
"CAPABILITY" / "LOGOUT" / "NOOP" / x_command доступны во всех состояниях
append / create / delete / examine / list / lsub / rename / select /
status / subscribe / unsubscribe доступны только в состояниях Authenticated и Selected
login / authenticate доступны только в состоянии Non-Authenticated
"CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store / uid / search доступны только в состоянии Selected
"+" SPACE (resp_text / base64)
"COPY" SPACE set SPACE mailbox
<ASCII CR, carriage return, 0x0D>
"CREATE" SPACE mailbox имя INBOX дает ошибку NO
CR LF
<any ASCII control character and DEL, 0x00 - 0x1f, 0x7f>
date_text / <"> date_text <">
1*2digit число месяца
(SPACE digit) / 2digit date_day в фиксированном формате
"Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / Dec"
date_day "-" date_month "-" date_year
4digit
<"> date_day_fixed "-" date_month "-" date_year SPACE time SPACE zone <">
"DELETE" SPACE mailbox
;; Use of INBOX gives a NO error
"0" / digit_nz
body_ext_lpart
body_ext_mpart
body_fields
body_fld_desc
body_fld_dsp
body_fld_enc
body_fld_id
body_fld_lang
body_fld_lines
body_fld_md5
body_fld_octets
body_fld_param
body_type_lpart
body_type_basic
body_type_mpart body_type_msg
body_type_text capability
capability_data
CHAR
CHAR8
command
command_any command_auth
command_nonauth
command_select
continue_req
copy
CR
create
CRLF CTL date date_day
date_day_fixed
date_month
"Oct" / "Nov" /
date_text
date_year
date_time
delete
digit
27
digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" envelope ::= "(" env_date SPACE env_subject SPACE env_from SPACE env_sender env_reply_to SPACE env_to SPACE env_cc SPACE env_bcc SPACE env_in_reply_to SPACE env_message_id ")"
SPACE
env_bcc
env_cc
env_date
env_from
env_in_reply_to
env_message_id
env_reply_to
env_sender
env_subject
env_to
examine
fetch
fetch_att
(
1*address
)" / nil
)" / nil
= "(" 1*address
= nstring
= "(" 1*address ")" / nil
= nstring
= nstring
= "(" 1*address ")" / nil
= "(" 1*address ")" / nil
= nstring
= "(" 1*address ")" / nil
= "EXAMINE" SPACE mailbox
= "FETCH" SPACE set SPACE ("ALL" / "FULL" / "FAST" / fetch_att / "(" 1#fetch_att ")")
= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / "RFC822" ".TEXT"] / "BODY" ["STRUCTURE"] / "UID" / "BODY"
[".HEADER" / ".SIZE" / [".PEEK"] section ["<"
flag flag_extension
number "." nz_number ">"]
= "\Answered" / "\Flagged" / "\Deleted" / "\Seen" / "\Draft" / flag_keyword / flag_extension
= "\" atom Будущее расширение. Реализации клиентов должны воспринимать флаги flag_extension. Для серверов недопустимо генерировать флаги flag_extension кроме тех, которые будут определены в стандартных вариантах данной спецификации.
= atom
= "(" #flag ")"
= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
= astring
= "(" 1#header_fld_name ")"
= <ASCII LF, line feed, 0x0A>
= "LIST" SPACE mailbox SPACE list_mailbox
= 1*(ATOM_CHAR / list_wildcards) / string
= "%" / "*"
= "{" number "}" CRLF *CHAR8
;; Number represents the number of CHAR8 octets
= "LOGIN" SPACE userid SPACE password
= "LSUB" SPACE mailbox SPACE list_mailbox
= "INBOX" / astring В имени INBOX регистр символов не имеет значения и все варианты (например, iNbOx) должны интерпретироваться как INBOX (см. параграф 5.1).
= "FLAGS" SPACE flag_list / "LIST" SPACE mailbox_list / "LSUB" SPACE mail-box_list / "MAILBOX" SPACE text / "SEARCH" [SPACE 1#nz_number] / "STATUS" SPACE mailbox SPACE "(" #<status_att number ")" / number SPACE "EXISTS" / number SPACE "RECENT"
= "(" #("\Marked" / "\Noinferiors" / "\Noselect" / "\Unmarked" /
flag_extension) ")" SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / "MESSAGE" / "VIDEO") <">) / string) SPACE media_subtype Определено в [MIME-IMT]
= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> Определено в [MIME-IMT]
= string Определено в [MIME-IMT]
= <"> "TEXT" <"> SPACE media_subtype Определено в [MIME-IMT]
= nz_number SPACE ("EXPUNGE" / ("FETCH" SPACE msg_att))
= "(" 1#("ENVELOPE" SPACE envelope / "FLAGS" SPACE "(" #(flag / "\Recent") ")" / "INTERNALDATE" SPACE date_time / "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / "RFC822.SIZE" SPACE number / "BODY" ["STRUCTURE"] SPACE body / "BODY" section ["<" number ">"] SPACE nstring / "UID" SPACE uniqueid) ")"
= "NIL"
= string / nil
= 1*digit
flag_keyword
flag_list
greeting
header_fld_name
header_list
LF
list
list_mailbox
list_wildcards
literal
login
lsub
mailbox
mailbox_data
mailbox_list media_basic
media_message
media_subtype
media_text
message_data msg_att
nil
nstring
number
nz_number
password
quoted
QUOTED_CHAR
quoted_specials
rename
Беззнаковое 32-битовое
= digit_nz *digit Беззнаковое 32-битовое
= astring
= <"> *QUOTED_CHAR <">
= <any TEXT_CHAR except
целое (0 <= n < 4,294,967,296) целое (0 <= n < 4,294,967,296)
quoted_specials> / "\" quoted_specials
= <"> / "\"
= "RENAME" SPACE mailbox SPACE mailbox
28
response response_data
response_done response_fatal
response_tagged resp_cond_auth
resp_cond_bye resp_cond_state
resp_text
resp_text_code
search search_key
Использование INBOX как получателя приводит к ошибке NO = *(continue_req / response_data) response_done = "*" SPACE (resp_cond_state / resp_cond_bye / mailbox_data / message_data /
capability_data) CRLF = response_tagged / response_fatal = "*" SPACE resp_cond_bye CRLF
сервер немедленно закрывает соединение = tag SPACE resp_cond_state CRLF = ("OK" / "PREAUTH") SPACE resp_text
условие аутентификации = "BYE" SPACE resp_text = ("OK" / "NO" / "BAD") SPACE resp_text
состояние = ["[" resp_text_code "]" SPACE] (text_mime2 / text)
текст не должен начинаться с "[" или "=" = "ALERT" / "PARSE" / "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / "READ­ONLY" / "READ-WRITE" / "TRYCREATE" / "UIDVALIDITY" SPACE nz_number / "UNSEEN" SPACE nz_number / atom [SPACE 1*<any TEXT_CHAR except "]">] = "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] 1#search_key
значение [CHARSET] должно быть зарегистрировано в IANA = "ALL" / "ANSWERED" / "BCC" SPACE astring / "BEFORE" SPACE date / "BODY" SPACE astring / "CC" SPACE astring / "DELETED" / "FLAGGED" / "FROM" SPACE astring / "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / "ON" SPACE date / "RECENT" / "SEEN" / "SINCE" SPACE date / "SUBJECT" SPACE astring / "TEXT" SPACE astring / "TO" SPACE astring / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNKEYWORD" SPACE flag_keyword / "UNSEEN" /
В [IMAP2] эта строка имела вид
"DRAFT" / "HEADER" SPACE header_fld_name SPACE astring / "LARGER" SPACE
number / "NOT" SPACE search_key / "OR" SPACE search_key SPACE search_key /
"SENTBEFORE" SPACE date / "SENTON" SPACE date / "SENTSINCE" SPACE date /
"SMALLER" SPACE number / "UID" SPACE set / "UNDRAFT" / set / "("
1#search_key ")" = "[" [section_text / (nz_number *["." nz_number] ["." (section_text /
"MIME")])] "]" = "HEADER" / "HEADER.FIELDS" [".NOT"] SPACE header_list / "TEXT" = "SELECT" SPACE mailbox = nz_number / "*"
* - наибольшее используемое значение. Для порядковых номеров сообщений
это число писем в ящике, для уникальных идентификаторов – уникальный
идентификатор последнего сообщения в ящике. = sequence_num / (sequence_num ":" sequence_num) / (set "," set)
идентифицирует набор сообщений. Для порядковых номеров от целые числа от 1
до числа сообщения в ящике. Запятые разделяют числа, двоеточие указывает
интервал (включающий). Например, 2,4:7,9,12:* показывает сообщения
2,4,5,6,7,9,12,13,14,15 для ящика с 15 сообщениями. = <ASCII SP, space, 0x20>
= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / "UNSEEN" = "STORE" SPACE set SPACE store_att_flags
= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE (flag_list / #flag) = quoted / literal = "SUBSCRIBE" SPACE mailbox = 1*<any ATOM_CHAR except "+"> = 1*TEXT_CHAR = "=?" <charset> "?" <encoding> "?" <encoded-text> "?="
синтаксис определен в [MIME-HDRS] = <any CHAR except CR and LF> = 2digit ":" 2digit ":" 2digit
часы, минуты, секунды = "UID" SPACE (copy / fetch / search / store)
уникальные идентификаторы, используемые взамен порядковых номеров = nz_number
строго возрастает = "UNSUBSCRIBE" SPACE mailbox = astring
= "X" atom <experimental command arguments> = ("+" / "-") 4digit
4-значное число со знаком, представляющее сдвиг от Гринвича в формате hhmm
(т. е., разницу между данным временем и Universal Time - UT). Вычитание
zone из данного времени дает значение UT (зона +0000).
section
section_text
select
sequence_num
set
SPACE
status
status_att
store
store_att_flags
string
subscribe
tag
text
text_mime2
TEXT_CHAR time
uid
uniqueid
unsubscribe userid x_command zone
10. Примечание автора
Этот документ является пересмотром предшествующих документов и переписывает спецификации протокола, вклю­ченные в эти документы - RFC 1730, неопубликованный документ IMAP2bis, RFC 1176, RFC 1064.
29
11. Вопросы безопасности
IMAP4rev1 protocol transactions, including electronic mail data, are sent in the clear over the network unless privacy pro­tection is negotiated in the AUTHENTICATE command.
A server error message for an AUTHENTICATE command which fails due to invalid credentials SHOULD NOT detail why the credentials are invalid. Use of the LOGIN command sends passwords in the clear. This can be avoided by using the AUTHENTICATE command instead. A server error message for a failing LOGIN command SHOULD NOT specify that the user name, as opposed to the password, is invalid.
Additional security considerations are discussed in the section discussing the AUTHENTICATE and LOGIN commands.
12. Адрес автора
Mark R. Crispin
Networks and Distributed Computing
University of Washington
4545 15th Aveneue NE
Seattle, WA 98105-4527
Phone: (206) 543-5762
Перевод на русский язык
Николай Малых BiLiM Systems Ltd. 194354, СПб., К-354, а/я 153 Тел. (812) 325-2068 Email: nmalykh@bilim.com
Приложения
A. Литература
[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", Work in Progress11.
[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 180612, June 1995.
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. Carnegie-Mellon University, December 1994. [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 2061, University of Washington, November 1996. [IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress.
[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, University of Washington, December 1994.
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in IMAP4", RFC 1733, University of Washington, December 1994. [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - Obsolete Syntax", RFC 2062, University of Washington, November 1996.
[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, University of Washington, August 1990. [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of Languages", RFC 176613, March 1995. [MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 204514, November 1996.
[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 204615, No­vember 1996.
[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 204716, November 1996.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 82217, University of Delaware, August 1982.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 82118, USC/Information Sciences Institute, August 1982. [UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe Transformation Format of Unicode", RFC 164219, July 1994.
B. Изменения по отношению к RFC 1730
1)    Добавлена команда STATUS.
2)    Уточнен формальный синтаксис - "#" не может указывать на множественные символы пробела.
3)    Устаревший синтаксис вынесен в отдельный документ.
4)    Отменена команда PARTIAL.
11 В настоящее время работа завершена и опубликована в RFC-2244. Прим. перев.
12 В RFC 2183 содержится ряд дополнений и уточнений. Прим. перев.
13 Этот документ устарел и заменен RFC 3066. Прим. перев.
14 В RFC 2184, RFC 2231 содержится ряд дополнений и уточнений. Прим. перев.
15 В RFC 2646 содержится ряд дополнений и уточнений. Прим. перев.
16 В RFC 2184, RFC 2231 содержится ряд дополнений и уточнений. Прим. перев.
17 В RFC 1123 (см. перевод на сайте http://rfc.com.ru), RFC 1138, RFC 1148, RFC 1327, RFC 2156 содержится ряд дополнений и уточнений. Прим. перев.
18 Этот документ устарел и заменен RFC 2821, перевод которого можно найти на сайте http://rfc.com.ru. Прим. перев.
19 Этот документ устарел и заменен RFC 2152. Прим. перев.
30
5)    Отменены атрибуты выборки RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, RFC822.TEXT.PEEK.
6)    Добавлены атрибуты "<" "." size ">" для текста BODY.
7)    Добавлены идентификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, TEXT.
8)    Добавлена поддержка Content-Disposition и Content-Language.
9)    Снято ограничение для выборки во вложенных частях MULTIPART.
10)  Отменено использование части тела с номером 0.
11)  Поддерживаемые сервером способы аутентификации идентифицируются как возможности сервера.
12)  Возможности протокола обозначаются как IMAP4rev1. Серверам, обеспечивающим совместимость с RFC 1730, следует возвращать также возможность IMAP4 (в дополнение к IMAP4rev1) в откликах CAPABILITY. Поскольку RFC-1730 требует указания IMAP4 как первой возможности, этот идентификатор должен указываться первым.
13)  Добавлено описание соглашений для пространства имен почтовых ящиков.
14)  Добавлено описание соглашения по использованию других языков в именах почтовых ящиков.
15)  Элементы состояния UID-NEXT и UID-VALIDITY получили названия UIDNEXT и UIDVALIDITY (это измене­ние связано с незавершенной работой IMAP STATUS, а не с RFC-1730).
16)  Добавление – пустое имя почтового ящика в аргументе команды LIST возвращает непомеченный отклик LIST с разделителем уровней иерархии и ссылкой на корень.
17)  Определены термины MUST, SHOULD, MUST NOT.
18)  Добавлен параграф, определяющий атрибуты сообщений и более тонкие детали семантики порядковых номеров, UID и флагов.
19)  Разъяснены обстоятельства, когда клиент может передавать множество команд, не дожидаясь отклика, и возмож­ные неоднозначности в таких случаях.
20)  Добавлены рекомендации в части поведения сервера по отношению к командам DELETE и RENAME при сущест­вовании подчиненных уровней иерархии.
21)  Уточнение - имя почтового ящика не может быть произвольно исключено из подписки сервером даже если это имя больше не существует.
22)  Уточнение – отклик на команду LIST должен даваться максимально быстро.
23)  Уточнение – аргумент date_time функции APPEND устанавливает для сообщения внутреннюю дату.
24)  Уточнено описание поведения APPEND для операций с выбранным в данный момент почтовым ящиком.
25)  Уточнение – внешние изменения флагов должны всегда анонсироваться с помощью непомеченных откликов FETCH даже при использовании для аргументов команды STORE суффикса ".SILENT".
26)  Уточнение – команда COPY копирует сообщения в казанный почтовый ящик.
27)  Добавлен код отклика NEWNAME.
28)  Переписано описание непомеченного отклика BYE с цель уточнения семантики.
29)  Уточнены ссылки на RFC для тел MD5.
30)  Уточнение – правила формального синтаксиса могут перекрываться и преимущество имеет первое правило из числа перекрывающихся.
31)  Исправлено определение параметра body_fld_param.
32)  Расширен формальный синтаксис для for capability_data.
33)  Уточнение – любое написание "INBOX" должно трактоваться как INBOX (все буквы заглавные).
34)  Уточнение – текст для пользователя в откликах resp_text не следует начинать с "[" или "=".
35)  Изменены ссылки на черновые стандарты для MIME.
36)  Уточнена семантика флагов \Recent.
37)  Добавлены примеры.
C. Предметный указатель
body ext lpart..................................27
body"ext"mpart.................................27
bodylextension..................................27
body fields........................................27
bodyjldjesc....................................27
body_fld_dsp.....................................27
body fid enc.....................................27
body'fkfid........................................27
bodylfldjang....................................27
body fid lines...................................27
body"fkfmd5....................................27
body"fkfoctets..................................27
bodylldlparam.................................27
bodylype lpart................................27
body"type"basic................................27
body"type"mpart...............................27
bodylypelmsg..................................27
body type text..................................27
BODYSTRUCTURE...................18, 24
BYE...................................................22
capability...........................................27
CAPABILITY...............................8, 22
capability_data...................................27
CC <string>.......................................17
[RFC-822]
25
authenticate........................................26
AUTHENTICATE...............................9
BAD..................................................21
base64................................................27
base64 char.......................................27
baseeCterminal.................................27
BCC <string>....................................17
BEFORE <date>................................17
body...................................................27
BODY..........................................17, 24
BODY <string>.................................17
body description................................24
body disposition...........................24, 25
body encoding...................................24
body id...............................................24
body language..............................24, 25
body parameter parenthesized list......24
body size............................................24
Body Structure.....................................5
body subtype......................................24
body type...........................................24
BODY.PEEK[<section>]«partial» 18 BODY[<section>]«origin octet». 24 BODY[<section>]«partial>>..........17
+FLAGS <flag list> ........................... 19
+FLAGS.SILENT
19
<message set>
17
<n> EXISTS......................................10
<n> RECENT....................................10
addr adl.............................................26
addThost...........................................26
addTmailbox.....................................26
addTname.........................................26
address...............................................26
ALERT..............................................20
ALL...................................................17
alpha..................................................26
Answered.............................................5
ANSWERED.....................................17
26 15
append
APPEND
astring................................................26
atom...................................................26
Atom....................................................6
ATOM_CHAR..................................26
atom specials....................................26
auth_lype...........................................27
31
CHAR ................................................ 27
CHAR8 .............................................. 27
CHECK .............................................. 16
CLOSE ............................................... 16
command ............................................ 27
command_any .................................... 27
command_auth ................................... 27
command_nonauth ............................. 27
command_select ................................. 27
continue_req ...................................... 27
copy ................................................... 27
COPY ................................................. 19
CR ...................................................... 27
create .................................................. 27
CREATE ............................................ 11
CRLF ................................................. 27
CTL .................................................... 27
date .................................................... 27
date_day ............................................. 27
date_day_fixed ................................... 27
date_month ........................................ 27
date_text ............................................. 27
date_time ............................................ 27
date_year ............................................ 27
delete .................................................. 27
DELETE ............................................ 11
Deleted ................................................. 5
DELETED ......................................... 17
digit .................................................... 27
digit_nz .............................................. 28
Draft ..................................................... 5
DRAFT .............................................. 17
env_bcc .............................................. 28
env_cc ................................................ 28
env_date ............................................. 28
env_from ............................................ 28
env_in_reply_to ................................. 28
env_message_id ................................. 28
env_reply_to ...................................... 28
env_sender ......................................... 28
env_subject ........................................ 28
env_to ................................................ 28
envelope ............................................. 28
ENVELOPE ................................. 18, 25
examin ............................................... 28
EXAMINE ......................................... 11
EXISTS ........................................ 10, 23
EXPUNGE ................................... 16, 23
FAST ................................................. 18
fetch ................................................... 28
FETCH ......................................... 17, 24
fetch_att ............................................. 28
flag ..................................................... 28
flag_extension .................................... 28
flag_keyword ..................................... 28
flag_list .............................................. 28
Flagged ................................................ 5
FLAGGED ......................................... 17
FLAGS ............................. 10, 18, 23, 25
FLAGS <flag list> ............................. 19
-FLAGS <flag list> ............................ 19
FLAGS.SILENT <flag list> ............... 19
-FLAGS.SILENT <flag list> ............. 19
FROM <string> ................................. 17
FULL ................................................. 18
greeting .............................................. 28
HEADER <field-name> <string> ...... 17
header_fld_name ................................ 28
header_list .......................................... 28
INTERNALDATE ....................... 18, 25
KEYWORD <flag> ........................... 17
LARGER <n> .................................... 17
LF ...................................................... 28
list ...................................................... 28
LIST ............................................. 13, 22
list_mailbox ....................................... 28
list_wildcards ..................................... 28
literal .................................................. 28
login ................................................... 28
LOGIN ............................................... 10
LOGOUT ............................................. 9
lsub ..................................................... 28
LSUB ........................................... 14, 22
mailbox .............................................. 28
mailbox_data ...................................... 28
mailbox_list ....................................... 28
media_basic ....................................... 28
media_message .................................. 28
media_subtype ................................... 28
media_text .......................................... 28
message_data ..................................... 28
MESSAGES ....................................... 15
msg_att ............................................... 28
NEW .................................................. 17
NEWNAME ....................................... 20
nil ....................................................... 28
NIL ....................................................... 7
NO ...................................................... 21
Noinferiors ......................................... 22
NOOP .................................................. 9
Noselect ............................................. 22
NOT ................................................... 17
nstring ................................................ 28
number ............................................... 28
nz_number ......................................... 28
OK ...................................................... 21
OK [UIDVALIDITY <n>] ................. 10
OLD ................................................... 17
ON <date> .......................................... 17
OR <search-key1> <search-key2> ..... 17
Parenthesized List ................................ 7
PARSE ............................................... 21
password ............................................ 28
PERMANENTFLAGS ....................... 21
PREAUTH ......................................... 21
quoted ................................................ 28
QUOTED_CHAR .............................. 28
quoted_specials .................................. 28
READ-ONLY .................................... 21
READ-WRITE ................................... 21
Recent .................................................. 5
RECENT .......................... 10, 15, 17, 23
rename ................................................ 28
RENAME ........................................... 12
resp_cond_auth .................................. 29
resp_cond_bye ................................... 29
resp_cond_state .................................. 29
resp_text ............................................. 29
resp_text_code ................................... 29
response ............................................. 29
response_data ..................................... 29
response_done .................................... 29
response_fatal .................................... 29
response_tagged ................................. 29
RFC822 ........................................ 18, 25
RFC822.HEADER ....................... 18, 25
RFC822.SIZE ............................... 18, 25
RFC822.TEXT ............................. 18, 25
search ................................................. 29
SEARCH ...................................... 16, 23
search_key ......................................... 29
section ................................................ 29
section_text ........................................ 29
Seen ...................................................... 5
SEEN ................................................. 17
select .................................................. 29
SELECT ............................................. 10
SENTBEFORE <date> ...................... 17
SENTON <date> ................................ 17
SENTSINCE <date> .......................... 17
sequence_num .................................... 29
set ....................................................... 29
SINCE <date> .................................... 17
SMALLER <n> .................................. 17
SPACE ............................................... 29
status .................................................. 29
STATUS ...................................... 14, 23
status_att ............................................ 29
store .................................................... 29
STORE ............................................... 19
store_att_flags .................................... 29
string .................................................. 29
SUBJECT <string> ............................ 17
subscribe ............................................ 29
SUBSCRIBE ...................................... 13
tag ....................................................... 29
text ..................................................... 29
TEXT <string> ................................... 17
TEXT_CHAR .................................... 29
text_mime2 ......................................... 29
time .................................................... 29
TO <string> ........................................ 17
TRYCREATE .................................... 21
uid ...................................................... 29
UID .................................... 4, 18, 19, 25
UID <message set> ............................ 17
UIDNEXT .......................................... 15
UIDVALIDITY ............................ 15, 21
UIDVALIDITY <n> .......................... 10
UNANSWERED ................................ 17
UNDELETED .................................... 17
UNDRAFT ......................................... 17
UNFLAGGED ................................... 17
uniqueid .............................................. 29
UNKEYWORD <flag> ...................... 17
Unmarked ........................................... 22
UNSEEN ................................ 15, 17, 21
unsubscribe ......................................... 29
UNSUBSCRIBE ................................ 13
userid .................................................. 29
x_command ........................................ 29
X<atom> ............................................ 20
zone .................................................... 29
Атрибуты ............................................ 4
Внутренняя дата ............................. 5
Номера сообщений ......................... 4
Порядковый номер ......................... 5
Размер сообщения [RFC-822] ........ 5
Структура конверта ........................ 5
Структура тела ................................ 5
Уникальный идентификатор
сообщения ................................... 4
Флаги сообщения ........................... 5
Порядковый номер сообщения ......... 5
Состояние
Authenticated ................................... 6
Logout .............................................. 6
Non-Authenticated ........................... 5
Selected ............................................ 6
Таймер автоматического отключения
......................................................... 8
Формат
Атом ................................................ 6
Пустой формат ................................ 7
Список в скобках ............................ 7
Строка ............................................. 6
Число ............................................... 6
32
праститутки- одна из самых древнейших профессий на земле.