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] – этот документ представляет в основном исторический интерес.
Оглавление
Статус документа ......................................................................................................................................................................................... 1
Тезисы ........................................................................................................................................................................................................... 1
Спецификация протокола IMAP4rev1 ............................................................................................................................................................. 3
1. Как работать с документом ..................................................................................................................................................................... 3
1.1. Структура документа ....................................................................................................................................................................... 3
1.2. Используемые соглашения .............................................................................................................................................................. 3
2. Обзор ......................................................................................................................................................................................................... 3
2.1. Канальный уровень .......................................................................................................................................................................... 3
2.2. Команды и отклики .......................................................................................................................................................................... 3
2.2.1. Передатчик клиента и приемник сервера .............................................................................................................................. 3
2.2.2. Приемник клиента и передатчик сервера .............................................................................................................................. 4
2.3. Атрибуты сообщения ....................................................................................................................................................................... 4
2.3.1. Номера сообщений .................................................................................................................................................................. 4
2.3.1.1. Уникальный идентификатор сообщения (UID) ............................................................................................................ 4
2.3.1.2. Порядковый номер сообщения ....................................................................................................................................... 5
2.3.2. Флаги сообщения ..................................................................................................................................................................... 5
2.3.3. Внутренняя дата сообщения ................................................................................................................................................... 5
2.3.4. Размер сообщения [RFC-822] ................................................................................................................................................. 5
2.3.5. Структура конверта ................................................................................................................................................................. 5
2.3.6. Структура тела сообщения (Body Structure) .......................................................................................................................... 5
2.4. Текст сообщения .............................................................................................................................................................................. 5
3. Состояния сервера и команды ................................................................................................................................................................. 5
3.1. Состояние Non-Authenticated .......................................................................................................................................................... 5
3.2. Состояние Authenticated .................................................................................................................................................................. 6
3.3. Состояние Selected ........................................................................................................................................................................... 6
3.4. Состояние Logout ............................................................................................................................................................................. 6
4. Форматы данных ...................................................................................................................................................................................... 6
4.1. Атом (Atom) ...................................................................................................................................................................................... 6
http://rfc.com.ru                                                                                                                               http://rfc.com.ru
4.2. Число ................................................................................................................................................................................................. 6
4.3. Строка ................................................................................................................................................................................................ 6
4.3.1. 8-битовые и двоичные строки ................................................................................................................................................. 6
4.4. Список в скобках (Parenthesized List) ............................................................................................................................................. 7
4.5. Пустой формат (NIL) ........................................................................................................................................................................ 7
5. Работа протокола ...................................................................................................................................................................................... 7
5.1. Именование почтовых ящиков ........................................................................................................................................................ 7
5.1.1.Иерархия имен ........................................................................................................................................................................... 7
5.1.2. Соглашение о пространстве имен ........................................................................................................................................... 7
5.1.3. Соглашение об использовании других языков в именах ...................................................................................................... 7
5.2. Обновление размеров и статуса сообщений .................................................................................................................................. 7
5.3. Отклики при отсутствии обрабатываемых команд ........................................................................................................................ 8
5.4. Таймер автоматического отключения ............................................................................................................................................ 8
5.5. Обработка множества команд ......................................................................................................................................................... 8
6. Команды клиента ................................................................................................................................................................................. 8
6.1. Команды клиента для любого состояния ....................................................................................................................................... 8
6.1.1. Команда CAPABILITY ............................................................................................................................................................ 8
6.1.2. Команда NOOP ......................................................................................................................................................................... 9
6.1.3. Команда LOGOUT ................................................................................................................................................................... 9
6.2. Клиентские команды – состояние Non-Authenticated .................................................................................................................... 9
6.2.1. Команда AUTHENTICATE ..................................................................................................................................................... 9
6.2.2. Команда LOGIN ..................................................................................................................................................................... 10
6.3. Команды клиента – состояние Authenticated ................................................................................................................................ 10
6.3.1. Команда SELECT ................................................................................................................................................................... 10
6.3.2. Команда EXAMINE ............................................................................................................................................................... 11
6.3.3. Команда CREATE .................................................................................................................................................................. 11
6.3.4. Команда DELETE ................................................................................................................................................................... 11
6.3.5. Команда RENAME ................................................................................................................................................................. 12
6.3.6. Команда SUBSCRIBE ............................................................................................................................................................ 13
6.3.7. Команда UNSUBSCRIBE ...................................................................................................................................................... 13
6.3.8. Команда LIST ......................................................................................................................................................................... 13
6.3.9. Команда LSUB ........................................................................................................................................................................ 14
6.3.10. Команда STATUS ................................................................................................................................................................. 14
6.3.11. Команда APPEND ................................................................................................................................................................ 15
6.4. Команды клиента – состояние Selected ........................................................................................................................................ 15
6.4.1. Команда CHECK .................................................................................................................................................................... 16
6.4.2. Команда CLOSE ..................................................................................................................................................................... 16
6.4.3. Команда EXPUNGE ............................................................................................................................................................... 16
6.4.4. Команда SEARCH .................................................................................................................................................................. 16
6.4.5. Команда FETCH ..................................................................................................................................................................... 17
6.4.6. Команда STORE ..................................................................................................................................................................... 19
6.4.7. Команда COPY ....................................................................................................................................................................... 19
6.4.8. Команда UID ........................................................................................................................................................................... 19
6.5. Команды клиента – экспериментальные/расширения ................................................................................................................. 20
6.5.1. Команда X<atom> ................................................................................................................................................................... 20
7. Отклики сервера ..................................................................................................................................................................................... 20
7.1. Отклики сервера - состояние ......................................................................................................................................................... 20
7.1.1. Отклик OK .............................................................................................................................................................................. 21
7.1.2. Отклик NO .............................................................................................................................................................................. 21
7.1.3. Отклик BAD ............................................................................................................................................................................ 21
7.1.4. Отклик PREAUTH .................................................................................................................................................................. 21
7.1.5. Отклик BYE ............................................................................................................................................................................ 22
7.2. Отклики сервера – состояние сервера и почтового ящика .......................................................................................................... 22
7.2.1. Отклик CAPABILITY ............................................................................................................................................................ 22
7.2.2. Отклик LIST ............................................................................................................................................................................ 22
7.2.3. Отклик LSUB .......................................................................................................................................................................... 22
7.2.4 Отклик STATUS ...................................................................................................................................................................... 23
7.2.5. Отклик SEARCH .................................................................................................................................................................... 23
7.2.6. Отклик FLAGS ....................................................................................................................................................................... 23
7.3. Отклики сервера – размер почтового ящика ................................................................................................................................ 23
7.3.1. Отклик EXISTS ....................................................................................................................................................................... 23
7.3.2. Отклик RECENT ..................................................................................................................................................................... 23
7.4. Отклики сервера – сообщение о состоянии .................................................................................................................................. 23
7.4.1. Отклик EXPUNGE .................................................................................................................................................................. 23
7.4.2. Отклик FETCH ....................................................................................................................................................................... 24
7.5. Отклики сервера – запрос продолжения команды ....................................................................................................................... 25
8. Пример соединения IMAP4rev1 ............................................................................................................................................................ 25
9. Формальный синтаксис .......................................................................................................................................................................... 26
10. Примечание автора ............................................................................................................................................................................... 29
11. Вопросы безопасности ......................................................................................................................................................................... 30
12. Адрес автора .......................................................................................................................................................................................... 30
Приложения ...................................................................................................................................................................................................... 30
A. Литература .............................................................................................................................................................................................. 30
B. Изменения по отношению к RFC 1730 ................................................................................................................................................. 30
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). Теги генерируются кли­ентом для каждой команды.
http://rfc.com.ru
3
http://rfc.com.ru
Существует два случая, когда строка от клиента не содержит полной команды – в одном случае сопровождаются счетчиком октетов (см. описание 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) данные. В любом случае запрос н продолжение команды сохраняется и клиент в ответ на этот запрос выполняет соответствующие действия. Во всех случаях клиент должен передать всю команду (включая все отклики на запросы продолжения команды и сами команды продолжения) до инициализации новой команды.
http://rfc.com.ru
4
http://rfc.com.ru
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) используют специальную семантику.
\Seen
Сообщение было прочитано.
\Answered
На сообщение был отправлен ответ.
\Flagged
Флаг важности сообщения.
\Deleted
Сообщение «удалено» для последующего уничтожения с помощью EXPUNGE.
\Draft
Сообщение не закончено (помечено как черновик - draft).
\Recent
Сообщение недавно доставлено в почтовый ящик. Этот сеанс является первым, в котором это сообщение появилось. Следующие сеансы не будут устанавливать флаг \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 Клиент должен получать запрос на продолжение даже при передаче литеральной строки нулевой длины.
http://rfc.com.ru
6
http://rfc.com.ru
Хотя бинарные данные определены спецификацией, их некодированная передача не допускается. Бинарными назы­вают строки с символами 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).
http://rfc.com.ru
7
http://rfc.com.ru