Область применения протокола IMAP ( Internet Message Access Protocol ) аналогична области применения протокола POP3: он тоже предназначен для получения почты и используется на участке между MUA получателя и хранилищем сообщений. IMAP предоставляет более широкие возможности работы с почтовыми ящиками, чем POP3: он позволяет работать с несколькими почтовыми ящиками на одном или нескольких серверах IMAP как с файлами и каталогами на собственной машине пользователя. Обычно почтовые ящики сервера IMAP действительно представляют собой файлы в специальном каталоге сервера и его подкаталогах.
Сервер IMAP способен анализировать сообщение: выделять заданные поля заголовка и разбирать структуру тела сообщения.
В отличие от серверов POP3, серверы IMAP не должны блокировать ящик на время сеанса – несколько клиентов могут одновременно работать с одним и тем же ящиком. Множественный доступ к почтовым ящикам связан с рядом проблем, особенно, если информация в ящиках доступна для записи. Различные способы разрешения этих проблем описаны в RFC 2180 .
Довольно часто IMAP используется в организациях, где пользователям нужно предоставить возможность совместно работать с одними и теми же почтовыми ящиками. Он удобен для работы с новостями USENET . Также протокол можно использовать для работы с личными каталогами и файлами пользователя, расположенными на сервере. Впрочем, для этой цели целесообразнее использовать протоколы, специально предназначенные для работы с каталогами на файловом сервере.
Хотя программное обеспечение, реализующее протокол IMAP , постоянно совершенствуется, IMAP менее защищен, чем POP3. Возможность хранить сообщения на сервере может стать причиной злоупотреблений со стороны пользователей, которые будут переполнять хранилище сообщений ненужной информацией.
Протокол IMAP предполагает в основном работу пользователей с почтовыми ящиками непосредственно на сервере, в отличие от протокола POP3, который ориентирован на то, что клиент забирает пришедшую почту и разбирает ее уже на своей машине (см. RFC 1733 ). Это делает IMAP неудобным для пользователей, подключающихся к сети кратковременно, только для того, чтобы получить или отослать почту. Во всяком случае, многие преимущества IMAP таким пользователям недоступны. При работе по протоколу IMAP клиенту желательно иметь доступ к сети все время, пока он работает с почтой.
Протокол IMAP позволяет пользователю работать с множеством почтовых ящиков, расположенных, возможно, на разных серверах.
Допускается иерархическое расположение почтовых ящиков в каталогах и их подкаталогах, причем имена каталогов и почтовых ящиков сами по себе не различаются. Почтовый ящик может быть только конечным элементом иерархической структуры, он не может содержать никаких нижестоящих элементов. Каталог может содержать подкаталоги и почтовые ящики, но он не содержит сообщений и не может быть выбран командой SELECT .
Символ, используемый в качестве иерархического разделителя, может различаться в зависимости от используемого на сервере программного обеспечения. Обычно это косая черта: "/", если сервер работает под управлением операционной системы, совместимой с UNIX , обратная косая черта: "\" для операционной системы Windows и точка для имен групп новостей USENET .
Допускается использование различных пространств имен почтовых ящиков и, соответственно, разных иерархических разделителей. Например, если сервер IMAP предоставляет доступ к ящикам, расположенным в каталогах файловой системы UNIX и к группам новостей USENET , то в первом случае в качестве иерархического разделителя используется косая черта, а во втором – точка. Чтобы использовать и различать разные пространства имен на одном сервере IMAP , имена, принадлежащие каждому из используемых пространств, должны начинаться с некоторого префикса, обычно начинающегося символом "#". Естественно, запросы, в которых путь к ящику начинается с одного префикса, будут давать отличные результаты от таких же запросов, начинающихся с другого префикса. Используемое по умолчанию пространство имен может префикса не иметь.
Клиент может выяснить, какие именно пространства имен для почтовых ящиков каких типов поддерживаются данным сервером IMAP , если сервер поддерживает расширение NAMESPACE. Префикс и иерархический разделитель конкретного имени почтового ящика или каталога можно выяснить при помощи команды LIST .
Большие возможности, предоставляемые протоколом IMAP , создают большие сложности при разработке, настройке и эксплуатации серверов и клиентов. Некоторые рекомендации по этим вопросам даны в RFC 2683 . В общем случае можно посоветовать использовать протокол IMAP только в том случае, если возможности протокола POP3 не достаточны для работы пользователей с их почтовыми ящиками.
Последняя на момент написания данного пособия версия протокола IMAP : IMAP4rev1 описана в RFC 3501 .
Сервер IMAP ожидает соединения от клиентов на порту TCP 143. После установления соединения сервер посылает свое приветствие клиенту, и начинается диалог, в котором клиент посылает серверу команды, а сервер сообщает о результатах их выполнения или присылает затребованную клиентом информацию. Как и сеанс POP3, сеанс IMAP делится на несколько состояний ( states ). Допустимый набор команд зависит от текущего состояния сеанса. Сеанс может находиться в одном из следующих состояний:
Схема переходов между состояниями сеанса IMAP представлена на рис.6.
Переходы, обозначенные цифрами:
Рис.6. Состояния сеанса IMAP
Команда клиента состоит из идентификатора (ярлыка) – короткой строкой, состоящей из букв и цифр, не повторяющейся в других командах в течение всего сеанса. За ярлыком следует сама команда и ее аргументы. Регистр символов в названиях команд, как и в большинстве аргументов, как правило, не имеет значения.
Кроме стандартных команд, которые обязательно должны поддерживаться, имеются также дополнительные команды, описанные в стандартах и поддерживаемые серверами IMAP как элементы расширений. Разработчики также могут добавлять в своих реализациях новые команды. Названия таких нестандартизированных команд должны начинаться с буквы Х. Имена стандартных команд с буквы Х начинаться не могут.
Все ответы сервера начинаются с метки, после которой следует отделенный пробелом текст.
В ответах сервера, сообщающих об исполнении команд, в качестве метки используется ярлык соответствующей команды. Это помеченные (tagged) ответы. За ним следует одно из ключевых слов:
Ответы, содержащие информацию, запрошенную клиентом или посылаемую сервером без запроса, начинаются с метки "*", такие ответы называются непомеченными (untagged). После метки следуют номер опрашиваемого сообщения и ключевое слово или только ключевое слово. Ключевых слов для непомеченных ответов предусмотрено значительно больше, чем для помеченных, обычно они соответствуют имени команды или характеру передаваемой клиенту информации.
Каждая команда должна получить один помеченный ответ сервера, свидетельствующий о возможности или невозможности исполнения команды, и, возможно, один или несколько непомеченных ответов, содержащих запрошенную или дополнительную информацию.
Клиент может послать несколько команд подряд, не дожидаясь ответа на каждую из них, если принятие решения о следующей команде не зависит от ответа на предыдущую. Сервер, получив несколько команд подряд, может выполнять их параллельно, если для успешного выполнения следующей команды не требуется выполнение предыдущей. Ответы в этом случае могут поступать в порядке, отличном от того, в каком команды посылались. Соответствие помеченных ответов посланным командам клиент определяет по ярлыкам.
Надо соблюдать осторожность и следить за тем, чтобы при одновременном выполнении команд не возникало неоднозначностей. Например, при удалении сообщения из ящика изменяется нумерация оставшихся сообщений, что может привести к неоднозначной интерпретации команды, одновременно обращающейся к другому сообщению в том же почтовом ящике.
Информация, передаваемая в команде или в непомеченном ответе, не обязательно должна укладываться в одну строку. Данные, которые передаются как продолжение команды или непомеченного ответа, называются литералом. На конце строки, которая должна быть продолжена литералом, ставится его размер в октетах, заключенный в фигурные скобки.
Сервер может передавать литерал, не дожидаясь разрешения клиента, клиент, прежде чем передавать литерал, должен дождаться разрешения – строки, начинающейся с метки "+". Например:
| C | A 001 LOGIN {11} |
| S | + Ready for additional command text |
| C | FRED FOOBAR {7} |
| S | + Ready for additional command text |
| C | Fat man |
В RFC 2088 описано расширение LITERAL+, позволяющее клиенту отправлять серверу продолжение команды, не дожидаясь разрешения. В этом случае между числом и закрывающей фигурной скобкой должен стоять плюс (+).
В ответ на эту команду сервер присылает непомеченную строку с ключевым словом CAPABILITY, содержащую список поддерживаемых возможностей (расширений) и их параметров. В число возможностей входит в частности поддерживаемая версия протокола IMAP – IMAP4rev1 и механизмы аутентификации ( AUTH =механизм_аутентификации), описанные в RFC 2595 . Возможности IMAP описываются в различных RFC или могут вводиться разработчиками. В последнем случае их названия должны начинаться с буквы Х. Названия стандартных возможностей с этой буквы начинаться не могут.
Не выполняет никаких действий. Однако эта команда сбрасывает таймер неактивности, что позволяет избежать разрыва соединения по таймауту. Кроме того, при определенных обстоятельствах эта или другая команда служит неявным запросом информации об обновлениях, произошедших на сервере. Таким образом, с помощью команды NOOP можно периодически проверять, не появились ли новые сообщения или не изменился ли статус старых. Это можно делать и с помощью других команд, но, поскольку команда NOOP не производит никаких других действий, использование ее с описанной целью предпочтительнее.
Конец сеанса.
Клиент должен успешно аутентифицироваться, чтобы перейти в следующее состояние. Алгоритмы аутентификации для протокола IMAP не отличаются принципиально от рассматривавшихся в предыдущих главах алгоритмов аутентификации для протоколов SMTP и POP3.
Информация о поддерживаемых способах аутентификации передается сервером клиенту в ответе на команду CAPABILITY. Так запись STARTTLS свидетельствует о поддержке одноименной команды, описанной в RFC 2595 , LOGINDISABLED – расширение, исключающее аутентификацию с использованием незашифрованных имени и пароля, параметры AUTH указывают, какие механизмы аутентификации с использованием SASL поддерживает сервер.
Подробно о механизмах аутентификации IMAP см. RFC 1731 .
Серверы IMAP могут допускать анонимный доступ к некоторым почтовым ящикам. Анонимный пользователь регистрируется под именем anonymous, в качестве пароля используется адрес электронной почты пользователя, имя его домена, произвольный набор символов или пустая строка. Анонимный доступ возможен как при передаче пароля открытым текстом, так и с использованием SASL . В последнем случае, в соответствии с RFC 2245 , в ответе на команду CAPABILITY клиент информируется о наличии механизма аутентификации ANONYMOUS: AUTH=ANONYMOUS. При аутентификации с использованием этого механизма клиент должен передать серверу некоторую информацию о себе. Характер этой информации, как и ее достоверность не имеют значения, в принципе, это может быть произвольная, даже пустая, строка. Поскольку анонимным доступом может воспользоваться любой желающий, а идентифицировать такого пользователя не представляется возможным, следует проявлять осторожность, предоставляя анонимный доступ. Возможности анонимного клиента должны быть строго ограничены, как правило, он не получает прав на изменение какой-либо информации на сервере.
Перевод сеанса в защищенный режим. После получения сервером команды STARTTLS клиент и сервер согласовывают параметры дальнейшего взаимодействия. Все данные, которыми обмениваются клиент и сервер после успешного завершения этой команды, передаются в зашифрованном виде. Однако аутентификация при помощи этой команды не производится, сеанс остается в неаутентифицированном состоянии.
Аутентификация при помощи регистрационного имени и пароля, передаваемых открытым текстом.
Передача зашифрованных аутентификационных данных с использованием SASL .
В аутентифицированном состоянии клиент производит различные манипуляции с почтовыми ящиками.
Открывает доступ к указанному почтовому ящику. Сеанс переходит в состояние выбора, после этого клиент может работать с отдельными сообщениями в ящике.
В ответ на эту команду сервер присылает ряд непомеченных ответов, содержащих информацию о почтовом ящике: количество сообщений, список допустимых флагов (см. описание команды APPEND), количество новых сообщений, номер первого непрочитанного сообщения, идентификатор почтового ящика.
Аналогично команде SELECT , но почтовый ящик открывается только для чтения.
Создает новый почтовый ящик или каталог.
Если объект создается не в корневом каталоге, то надо указать путь к нему.
Если на конце указанного имени стоит символ, используемый в качестве иерархического разделителя, создается каталог.
Например :
| C | A003 CREATE owatagusiam/ |
| S | A003 OK CREATE completed |
| C | A004 CREATE owatagusiam/blurdybloop |
| S | A004 OK CREATE completed |
В этом примере, если косая черта (/) служит на сервере иерархическим разделителем, создается каталог owatagusiam и в нем почтовый ящик blurdybloop . В противном случае создаются два почтовых ящика в текущем каталоге.
Удаляет указанный почтовый ящик. Эта же команда удаляет также и каталоги, если они не содержат почтовые ящики.
Переименование почтового ящика.
Почтовый ящик помечается как "активный". Эта пометка используется для вывода списка почтовых ящиков при помощи команды LSUB.
Снимает с почтового ящика пометку "активный". Эта пометка может быть снята с почтового ящика только при помощи команды UNSUBSCRIBE. Даже если ящик больше не существует, это не может само по себе стать причиной снятия пометки "активный".
Возвращает список каталогов и почтовых ящиков, соответствующих указанным аргументам.
В имени ящика могут использоваться групповые символы:
"*", обозначающий любые символы и
"%", обозначающий любые символы кроме иерархических разделителей.
Если имя ящика само по себе содержит полный путь к ящику, то первый аргумент игнорируется.
В ответ сервер присылает одну или несколько непомеченных строк с ключевым словом LIST. Каждая из них содержит атрибуты, если таковые имеются, иерархический разделитель и имя почтового ящика или каталога, отвечающего заданным в аргументах условиям. Атрибуты заключаются в скобки, иерархический разделитель – в кавычки.
RFC 3501 предусматривает четыре атрибута:
\Noinferiors – объект нижнего уровня иерархии – почтовый ящик, не каталог;
\Noselect – объект – каталог, он не может быть выбран командой SELECT ;
\Marked – почтовый ящик отмечен как представляющий интерес, скорее всего это означает, что со времени последнего обращения к ящику туда были добавлены новые сообщения;
\Unmarked – со времени последнего обращения в почтовый ящик не поступило новых сообщений.
В описанном в RFC 3348 расширении CHILDREN предусмотрены еще два атрибута, позволяющие определить, содержит ли каталог почтовые ящики или подкаталоги:
\HasChildren – каталог содержит почтовые ящики или подкаталоги;
\HasNoChildren – объект не содержит почтовых ящиков или подкаталогов, доступных пользователю, аутентифицированному в данном сеансе. Этот атрибут не следует путать с атрибутом \Noinferiors, означающим, что никакие нижестоящие иерархические элементы не могут быть созданы. Атрибут \HasNoChildren означает только то, что такие элементы в настоящее время не существуют. Такой атрибут могут иметь как почтовые ящики, так и пустые каталоги.
Оставив пустым второй аргумент команды LIST , можно выяснить используемый в первом аргументе префикс пространства имен. В этом случае ответ сервера вместо имени ящика будет содержать имя корневого каталога, то есть префикс пространства имен с иерархическим разделителем на конце.
Если оба аргумента команды LIST пустые, то сервер возвращает только используемый по умолчанию иерархический разделитель.
Примеры :
| 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 |
Опрашиваются иерархический разделитель и префикс пространства, к которому принадлежит имя # news . comp . mail . misc . Иерархический разделитель: ".", префикс: # news .
| C | A103 LIST /usr/staff/jones "" |
| S | * LIST (\Noselect) "/" / |
| S | A103 OK LIST Completed |
Для имени / usr / staff / jones иерархический разделитель: "/", корневой каталог: /.
| C | A202 LIST ~/Mail/ % |
| S | * LIST (\Noselect) "/" ~/Mail/foo |
| S | * LIST () "/" ~/Mail/meetings |
| S | A202 OK LIST completed |
Список объектов в каталоге ~/ Mail /: каталог foo и почтовый ящик meetings .
Если вместо иерархического разделителя в ответе указана пустая строка: "", это означает, что иерархия имен на данном сервере вообще не предусмотрена: все почтовые ящики могут быть расположены только в одном каталоге.
Команда LSUB аналогична команде LIST , но она возвращает только имена почтовых ящиков с пометкой "активный".
Возвращает запрошенные элементы информации об указанном почтовом ящике. Имена элементов информации разделяются пробелами и все вместе заключаются в скобки. Предусмотрены следующие имена элементов информации:
MESSAGES – общее количество сообщений в ящике;
RECENT – количество новых сообщений;
UIDNEXT –уникальный идентификатор, который изменяется всякий раз, когда в почтовый ящик помещается новое сообщение, используется для того, чтобы определить, появились ли в ящике новые сообщения за время, прошедшее после предыдущей проверки;
UIDVALIDITY – уникальный идентификатор почтового ящика;
UNSEEN – количество сообщений, не помеченных как прочитанные.
Ответ представляет собой непомеченную строку с ключевым словом STATUS , за которым следует имя опрашиваемого почтового ящика, после которого в скобках перечисляются имена запрошенных элементов и их числовые значения.
Пример :
| C | A042 STATUS blurdybloop (UIDNEXT MESSAGES) |
| S | * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) |
| S | A042 OK STATUS completed |
Добавляет сообщение в конец указанного почтового ящика. В качестве аргументов указываются имя ящика, флаги сообщения (не обязательно), метка времени (не обязательно) и само сообщение – заголовок и тело.
Имеются следующие флаги сообщений:
\ Seen – прочитано;
\ Answered – написан ответ;
\ Flagged – срочное;
\ Deleted – помечено для удаления;
\ Draft – черновик;
\Recent – новое сообщение, оно поступило в почтовый ящик после окончания прошлого сеанса.
Если в команде указаны флаги, то они устанавливаются для добавляемого сообщения. В любом случае для сообщения устанавливается флаг \Recent.
Если в команде задана метка времени, то это время будет установлено в качестве времени создания сообщения, в противном случае за время создания принимается текущее время.
Поскольку сообщение состоит не из одной строки, используются литералы.
Пример :
| C | A003 APPEND saved-messages (\Seen) {247} |
| S | + Ready for literal data |
| C | Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) |
| C | From: Fred Foobar <foobar@Blurdybloop.COM> |
| C | Subject: afternoon meeting |
| C | To: mooch@owatagu.siam.edu |
| C | Message-Id: <B27397-0100000@Blurdybloop.COM> |
| C | |
| C | Hello Joe, do you think we can meet at 3:30 tomorrow? |
| S | A003 OK APPEND completed |
Расширение MULTIAPPEND, описанное в RFC 3502, позволяет одной командой добавлять в почтовый ящик несколько сообщений.
В выбранном состоянии клиент может выполнять те же действия, что и в аутентифицированном состоянии, и производить манипуляции с сообщениями в выбранном почтовом ящике.
Команда производит проверку выбранного почтового ящика, характер которой зависит от реализации программного обеспечения сервера.
Выбранный почтовый ящик закрывается. При этом, если почтовый ящик был открыт для чтения и записи, все помеченные для удаления сообщения в ящике удаляются. Сеанс возвращается в аутентифицированное состояние.
Из выбранного почтового ящика удаляются все помеченные для удаления сообщения. Для каждого удаляемого сообщения посылается непомеченный ответ, содержащий номер сообщения и ключевое слово EXPUNGE .
Поиск в выбранном почтовом ящике сообщений, отвечающих указанным критериям поиска.
Необязательный первый аргумент команды состоит из слова "CHARSET" и названия кодировки, используемой в критериях поиска. Кодировку нужно указывать, только если она отличается от стандартной US-ASCII.
Второй аргумент содержит один или более критериев поиска.
Критерий поиска состоит из ключевого слова и аргумента. В табл. 3 приведены ключевые слова и соответствующие аргументы, используемые в критериях поиска.
Таблица 3
| Ключевое слово | Аргумент | Значение |
|---|---|---|
| х:у | Сообщения с номерами в интервале от х до у | |
| ALL | Все сообщения | |
|
BCC CC FROM SUBJECT TO |
строка | Сообщения, содержащие указанную строку в соответствующем поле заголовка |
| HEADER | имя_поля строка | Сообщения, содержащие указанную строку в указанном поле заголовка |
| BODY | строка | Сообщения, в теле которых содержится указанная строка |
| TEXT | Сообщения, содержащие указанную строку в заголовке или в теле | |
| SENTON | дата | Сообщения, у которых в поле Date заголовка записано указанное число |
| SENTSINCE | дата | Сообщения, у которых в поле Date заголовка записано число, более позднее, чем указанное |
| SENTBEFORE | дата | Сообщения, у которых в поле Date заголовка записано число, более раннее, чем указанное |
| ON | дата | Сообщения, с указанной датой создания |
| SINCE | дата | Сообщения, созданные позднее указанной даты |
| BEFORE | дата | Сообщения, созданные раньше указанной даты |
| ANSWERED DELETED DRAFT FLAGGED RECENT SEEN |
Сообщения, для которых установлен соответствующий флаг | |
| UNANSWERED UNDELETED UNDRAFT UNFLAGGED UNSEEN |
Сообщения, для которых не установлен соответствующий флаг | |
| KEYWORD | флаг | Сообщения, для которых установлен указанный флаг |
| UN KEYWORD | флаг | Сообщения, для которых не установлен указанный флаг |
| NEW | Сообщения с установленным флагом \Recent и не установленным флагом \Seen | |
| OLD | Сообщения, для которых не установлен флаг \Recent | |
| SMALLER | число | Сообщения, размер которых меньше указанного числа октетов |
| LARGER | число | Сообщения, размер которых больше указанного числа октетов |
| NOT | критерий_поиска | Сообщения, не отвечающие указанному критерию поиска |
| OR | критерий_поиска критерий_поиска | Сообщения, отвечающие одному из указанных критериев поиска |
| UID | х:у | Сообщения с уникальным идентификатором в интервале от х до у |
При поиске строки регистр символов всегда игнорируется.
Если задано несколько критериев поиска, то ищутся сообщения, отвечающие всем критериям. Например, строка
DELETED FROM " SMITH " SINCE 1- Feb -1994
означает поиск всех помеченных для удаления сообщений со строкой " SMITH " в адресе отправителя, помещенных в почтовый ящик после 1 февраля 1994 г .
Критерии также можно объединять, заключая в скобки. Это бывает удобно при использовании ключевых слов NOT и OR.
Непомеченные ответы на команду SEARCH содержат номера сообщений, отвечающих указанным критериям.
В приведенном ниже примере производится поиск непрочитанных сообщений, пришедших после 1.02.1994, в адресе отправителя которых нет строки " Smith ". Этому критерию отвечают три сообщения с номерами 2, 84, 882. После этого ищутся сообщения, содержащие строку " string not in mailbox ". Таких в ящике нет. В последнем примере ищутся сообщения, содержащие строку "что-нибудь" на русском языке в кодировке KOI -8- R . Найдено одно сообщение с номером 43.
| C | A282 SEARCH UNSEEN SINCE 1-Feb-1994 NOT FROM "Smith" |
| S | * SEARCH 2 84 882 |
| S | A282 OK SEARCH completed |
| C | A283 SEARCH TEXT "string not in mailbox" |
| S | * SEARCH |
| S | A283 OK SEARCH completed |
| C | A284 SEARCH CHARSET KOI-8-R TEXT {10} |
| C | что-нибудь |
| S | * SEARCH 43 |
| S | A284 OK SEARCH completed |
Сервер возвращает информацию, относящуюся к сообщениям, обозначенным первым аргументом команды. Это может быть либо число, обозначающее номер сообщения, либо интервал от номера х до номера у, записанный в формате х:у.
Во втором аргументе перечисляются запрашиваемые информационные элементы. В табл. 4 описаны имеющиеся типы информационных элементов.
| Информационный элемент | Значение |
|---|---|
| BODY | структура сообщения. Может различаться в зависимости от характера содержимого. Например, описание структуры сообщения, не содержащего никаких вложений, состоит из следующих подэлементов:
• тип содержимого * ; • подтип содержимого * ; • параметры тела сообщения, представляющие собой пары строк, где первая строка пары – название параметра, а вторая строка – значение, например запись "foo" " bar " " baz " " rag " следует интерпретировать как foo= bar , baz = rag ; • идентификатор содержимого тела сообщения * ; • описание содержимого тела сообщения * ; • кодирование тела сообщения (7BIT, 8BIT, BINARY, BASE64, QUOTED-PRINTABLE) * ; • размер тела сообщения в октетах; • информация, зависящая от типа сообщения, например, для текста это число строк в теле сообщения. Сообщения могут иметь сколь угодно сложную структуру, включать в себя различные вложения, содержать альтернативные форматы текста, например, простой текст, гипертекст и документ в формате Word , из которых клиент должен выбрать наиболее предпочтительный. Каждая часть может сама состоять из нескольких подчастей. Протокол IMAP позволяет работать по отдельности с разными частями сообщения и их подчастями |
| BODYSTRUCTURE | содержит ту же информацию, что и BODY , а также некоторые дополнительные данные |
| BODY <x.y> | текст соответствующей части сообщения, где
• секция – необязательный набор спецификаторов, разделенных точкой, если это поле оставлено пустым: , то берется сообщение целиком, в качестве спецификаторов выступают номера части и подчастей или одно из следующих ключевых слов: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT. Каждое сообщение содержит как минимум одну часть. Структуру сообщений, включая количество и вложенность частей сообщения, можно выяснить, опросив элементы BODY или BODYSTRUCTURE этих сообщений; • х.у, где х – номер первого октета, запрошенного клиентом, у – количество запрошенных октетов. Расположение – используется в том случае, если надо получить не всю запрошенную часть сообщения, а только некоторый фрагмент. Если х больше, чем количество октетов в запрошенной части, клиент получает пустую строку. Объем информации, посылаемой клиенту не должен превышать у октетов. Примеры: BODY – поля заголовка DATE и FROM; BODY <0.2048> – первые 2048 октетов сообщения; BODY – текст сообщения; BODY – заголовок сообщения. После выполнения, для опрошенного сообщения выставляется флаг \ Seen , если используется BODY , и не выставляется, если используется BODY . PEEK |
| ENVELOPE | содержимое полей date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to и message-id заголовка сообщения . Адреса в ответе сервера переписываются в следующем формате: имя пользователя, маршрут сообщения (обычно пустой), регистрационное имя в почтовой системе (левая часть адреса), почтовый домен (правая часть адреса). |
| FLAGS | флаги, выставленные для сообщения |
| INTERNALDATE | дата сообщения |
| RFC 822 | эквивалентно BODY |
| RFC822.HEADER | эквивалентно BODY.PEEK |
| RFC822.SIZE | размер сообщения |
| RFC822.TEXT | BODY |
| UID | уникальный идентификатор сообщения |
* См. описание спецификации MIME в RFC 2045 .
Расширение BINARY, описанное в RFC 3516 , дополнительно предусматривает еще три типа информационных элементов:
BINARYсекция< x . y >, но данные передаются без всякого кодирования, как двоичный поток;
BINARY.PEEKсекция – тоже самое, но без установки флага \Seen;
BINARY.SIZEсекция – размер указанной секции в незакодированном виде.
Кодирование в соответствии со спецификацией MIME увеличивает размер сообщений. Отказ от кодирования двоичных файлов позволяет уменьшить объем передаваемых данных и, соответственно, сократить время передачи.
В ответе перед каждым информационным элементом записывается его название, если он состоит из нескольких составных частей, каждая из них заключается в скобки, если отдельные части тоже состоят или могут состоять из нескольких частей, то и их тоже заключают в скобки. Строковые константы заключаются в кавычки. Если обязательная составная часть информационного элемента оказывается пустой, то на ее месте записывается слово NIL .
Кроме типов информационных элементов установлено три макроса, описывающие наиболее часто используемые комбинации информационных элементов:
ALL – соответствует (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
FAST – соответствует (FLAGS INTERNALDATE RFC822.SIZE)
FULL – соответствует (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
Примеры использования команды FETCH можно найти ниже, в примере сеанса IMAP .
Команда STORE изменяет значения флагов для указанного в первом аргументе сообщения или сообщений. В ответ сервер возвращает непомеченный ответ с ключевым словом FETCH, содержащий значения флагов, если в имени элемента данных не используется суффикс .SILENT. Определены следующие имена элементов данных:
FLAGS – изменяет значения указанных флагов, кроме флага \Recent;
FLAGS.SILENT – аналогично FLAGS, значения флагов не возвращаются;
+FLAGS – устанавливает значения указанных флагов;
+FLAGS.SILENT – аналогично +FLAGS, значения флагов не возвращаются;
–FLAGS – сбрасывает значения указанных флагов;
–FLAGS.SILENT – аналогично –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 |
Копирует сообщения с номерами от х до у из текущего почтового ящика в указанный почтовый ящик.
Команда UID принимает в качестве аргументов команды COPY, FETCH или STORE с их аргументами, но наряду с номерами сообщений в ответах указываются уникальные идентификаторы сообщений.
Также команду UID можно использовать совместно с командой SEARCH. В этом случае интерпретация аргументов команды SEARCH не изменяется, но в ответах на эту команду будут приведены уникальные идентификаторы сообщений.
Ниже приведен пример сеанса IMAP , в котором пользователь регистрируется на сервере под именем mrc с паролем secret, открывает почтовый ящик inbox, содержащий 18 сообщений, 2 из которых получены после предыдущего сеанса. Номер первого непрочитанного сообщения – 17, уникальный идентификатор почтового ящика – 3857529045, также приведен список флагов, которые могут быть установлены для сообщений в выбранном почтовом ящике.
После этого клиент запрашивает сведения о двенадцатом сообщении в выбранном ящике. Ответ сервера содержит только одну непомеченную строку. Нам пришлось разбить ее на несколько строк, чтобы она поместилась на странице.
Сервер отвечает, что это сообщение уже было просмотрено; оно получено 17 июля 1996г. в 2:22:25 в часовом поясе –07:00, что соответствует таким штатам США, как Аризона, Юта, Колорадо, Айдахо, Вайоминг, Монтана; размер сообщения – 4286 октетов; в заголовке сообщения имеются следующие поля:
Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT),
Subject: IMAP4rev1 WG mtg summary and minutes,
From: Terry Gray <gray@cac.washington.edu>,
Sender: Terry Gray <gray@cac.washington.edu>,
reply-to: Terry Gray <gray@cac.washington.edu>,
to: imap@cac.washington.edu,
cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>,
bcc : отсутствует,
in - reply - to : отсутствует,
message - id : <B27397-0100000@cac.washington.edu>.
Обратите внимание, адреса в ответе сервера на команду fetch 12 full записаны в формате, отличающемся от принятого в адресах SMTP .
Тело сообщения имеет следующую структуру:
тип содержимого: TEXT;
подтип содержимого: PLAIN;
параметры тела сообщения: CHARSET=US-ASCII;
идентификатор тела сообщения: отсутствует;
описание тела сообщения: отсутствует;
кодирование тела сообщения: 7 BIT ;
размер тела сообщения в октетах: 3028;
число строк в теле сообщения: 92.
Клиент запрашивает заголовок двенадцатого сообщения. Обратите внимание, передаваемый элемент – заголовок, заключен в скобки. Передается он в виде литерала.
Клиент помечает двенадцатое сообщение для удаления и завершает сеанс.
| S | * OK IMAP4rev1 Service Ready |
| C | A001 login mrc secret |
| S | A001 OK LOGIN completed |
| C | A002 select inbox |
| S | * 18 EXISTS |
| S | * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) |
| S | * 2 RECENT |
| S | * OK Message 17 is the first unseen message |
| S | * OK UIDs valid |
| S | A002 OK SELECT completed |
| C | A003 fetch 12 full |
| S | * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" "IMAP4rev1 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" "MIT.EDU")) NIL NIL "<B27397-0100000@cac.washington.edu>") BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) |
| S | A003 OK FETCH completed |
| C | A004 fetch 12 body |
| S | * 12 FETCH (BODY {342} |
| S | Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) |
| S | From: Terry Gray <gray@cac.washington.edu> |
| S | Subject: IMAP4rev1 WG mtg summary and minutes |
| S | To: imap@cac.Washington.edu |
| S | Cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU> |
| S | Message-Id: <B27397-0100000@cac.washington.edu> |
| S | MIME-Version: 1.0 |
| S | Content-Type: TEXT/PLAIN; CHARSET=US-ASCII |
| S: | |
| S | ) |
| S | A004 OK FETCH completed |
| C | A005 store 12 +flags \deleted |
| S | * 12 FETCH (FLAGS (\Seen \Deleted)) |
| S | A005 OK +FLAGS completed |
| C | A006 logout |
| S | * BYE IMAP4rev1 server terminating connection |
| S | A006 OK LOGOUT completed |
Расширения IMAP аналогичны расширениям, используемым протоколами SMTP и POP3. Они добавляют возможности существующим командам, как, например, упоминавшиеся выше расширения BINARY, CHILDREN, LITERAL+ и MULTIAPPEND, и вводят новые команды. Клиент информируется о поддерживаемых сервером расширениях ответом на команду CAPABILITY.
Расширение ACL , описанное в RFC 2086 , предназначено для управления доступом пользователей к почтовым ящикам и к информации в них.
Права доступа определяются набором атрибутов, возможно, пустым, устанавливаемым для пользователя в отношении почтового ящика. Каждый атрибут обозначается одной буквой. Определены следующие атрибуты:
l – lookup , просмотр (для почтового ящика могут быть выполнены команды LIST / LSUB );
r – read , чтение (ящик может быть выбран, сообщения в нем доступны для чтения);
s – значение флага \ Seen не может быть изменено для сообщений в ящике;
w – write , запись (без права изменения значений флагов \ Seen и \ Deleted ;)
i – insert , добавление (команды APPEND и COPY );
p – post , отправка сообщения по адресу, установленному для почтового ящика;
c – create , создание ящика (относится к каталогу при иерархическом расположении почтовых ящиков);
d – delete , удаление сообщений;
a – administer , изменение прав доступа.
Как уже отмечалось выше, права доступа к ящику определяются для каждого пользователя. Так право изменения прав доступа может быть только у владельца ящика или у администратора, у других же пользователей в отношении этого ящика могут быть установлены другие права.
Расширение ACL добавляет к набору команд IMAP ряд дополнительных команд, их описания приведены в табл. 5 .
Таблица 5
| Команда | Аргументы | Описание |
|---|---|---|
| SETACL | имя_ящика имя_пользователя права_доступа | Изменение прав доступа указанного пользователя к указанному почтовому ящику. Символы, обозначающие права доступа записываются в одну строку, перед ними могут стоять символы плюс (+) или минус (-). Плюс обозначает установку прав, минус – отмену. Если перед атрибутами не стоит никакой символ, то уже установленные права доступа заменяются на указанные |
| DELETEACL | имя_ящика имя_пользователя | Удаляет все права доступа указанного пользователя к указанному почтовому ящику |
| GETACL | имя_ящика | Возвращает списки прав доступа к указанному почтовому ящику. Ответ содержит столько непомеченных строк с ключевым словом ACL , для скольких пользователей установлены права доступа к данному ящику. Каждая непомеченная строка ответа содержит имя пользователя и установленные для него права |
| LISTRIGHTS | имя_ящика имя_пользователя | Возвращает список прав доступа указанного пользователя к указанному почтовому ящику |
| MYRIGHTS | имя _ ящика | Возвращает список прав доступа к указанному почтовому ящику пользователя, зарегистрированного в текущем сеансе |
Пример :
| C | A001 LISTRIGHTS ~/Mail/saved smith |
| S | * LISTRIGHTS ~/Mail/saved smith larswicd |
| S | A001 OK Listrights completed |
Серверы, поддерживающие описанное в RFC 2087 расширение QUOTA, могут налагать ограничения на некоторые виды ресурсов. Названия и характер ресурсов зависят от технической реализации. Например, в качестве ресурсов могут выступать общий размер сообщений или их количество. Каждому почтовому ящику приписываются ноль или более корневых квот ( quota roots ), каждая из которых содержит ноль или более ограничений ресурсов. Ресурсы, ограниченные корневой квотой, распределяются между всеми почтовыми ящиками, которым она приписана. В табл. 6 описаны команды, вводимые расширением QUOTA.
Таблица 6
| Команда | Аргументы | Описание |
|---|---|---|
| SETQUOTA | корневая_квота ограничения | Устанавливает указанные ограничения для указанной корневой квоты |
| GETQUOTA | корневая_квота | Возвращает объем используемых ресурсов и размеры ограничений, установленных для указанной корневой квоты |
| GETQUOTAROOT | имя_ящика | Возвращает имена корневых квот, установленных для указанного почтового ящика, объемы их используемых ресурсов и размеры ограничений |
Пример :
| C | A003 GETQUOTA "" |
| S | * QUOTA "" (STORAGE 10 512) |
| S | A003 OK Getquota completed |
Расширение IDLE, описанное в RFC 2177 , позволяет клиенту при выбранном состоянии сеанса IMAP получать информацию об изменениях в выбранном почтовом ящике, не запрашивая ее. Таким образом, клиент оперативно информируется о получении почты, а с сервера снимается нагрузка, связанная с обслуживанием регулярных переспросов клиента.
Клиент переходит в режим ожидания, направив серверу команду IDLE без параметров и получив подтверждение, начинающееся с символа "+". После этого сервер, не получая запроса клиента, может посылать ему информацию о выбранном почтовом ящике при каждом изменении его содержимого.
Чтобы выйти из режима ожидания, клиент посылает серверу строку, состоящую из одного слова " DONE ", это не команда, метка перед ней не ставится.
Клиент должен периодически подтверждать свою активность, прерывая режим ожидания не реже, чем каждые 29 минут. Иначе сервер сам прекращает сеанс по истечении таймаута.
Пример :
| C | A001 SELECT INBOX |
| S | * FLAGS (Deleted Seen) |
| S | * 3 EXISTS |
| S | * 0 RECENT |
| S | * OK |
| S | A001 OK SELECT completed |
| C | A002 IDLE |
| S | + idling |
Поступило новое сообщение
| S | * 4 EXISTS |
| C | DONE |
| S | A002 OK IDLE terminated |
Ресурсы, доступ к которым предоставляется по протоколу IMAP , могут быть описаны при помощи унифицированных указателей ресурсов ( URL ). Их формат описан в RFC 2192 . В общем виде URL ресурса IMAP записывается таким образом:
imap ://пользователь; AUTH =механизм_аутентификации@сервер/ресурс ,
где пользователь – регистрационное имя пользователя, если оно не задано, производится анонимная регистрация;
механизм_аутентификации – механизм аутентификации, используемый командой AUTHENTICATE, если эта часть URL пропущена, то аутентификация проводится при помощи команды LOGIN, если на месте механизма аутентификации стоит звездочка (*), то используется один из механизмов, поддерживаемых клиентом и сервером;
сервер – имя сервера;
ресурс – описывается в зависимости от характера ресурса: список почтовых ящиков, почтовый ящик, список сообщений, сообщение или его часть.
В URL , указывающем на конкретное сообщение, ресурс описывается следующим образом:
ящик; UIDVALIDITY =ид_ящика/; UID =ид_сообщения/;section=секция ,
где ящик – имя почтового ящика, включающее путь к нему, если почтовые ящики на сервере расположены иерархически;
ид_ящика – необязательный идентификатор почтового ящика. Если он задан, то доступ к почтовому ящику с указанным именем будет предоставлен, только если указанный идентификатор совпадает с идентификатором указанного ящика. Это позволяет избежать ошибки, которая может возникнуть, если ящик был удален, а после был создан ящик с тем же именем: в отличие от имени ящика, идентификатор не может совпадать с уже существовавшим;
ид_сообщения – идентификатор сообщения;
секция – необязательный аргумент, используемый в команде
UID FETCH ид_сообщения BODY . PEEK .
Ниже приведены примеры URL и соответствующие им последовательности команд, посылаемых клиентом.
imap://minbari.org/gray-council;UIDVALIDITY=385759045/;UID=20
A001 LOGIN ANONYMOUS sheridan@babylon5.org
A002 SELECT gray-council
Клиент проверяет, совпадает ли известный ему идентификатор почтового ящика с тем идентификатором, который был получен от сервера
A003 UID FETCH 20 BODY.PEEK
imap://;AUTH=KERBEROS_V4@minbari.org/gray-council/;uid=20/;section=1.2
A001 AUTHENTICATE KERBEROS_V4
Обмен аутентификационными данными
A 002 SELECT gray - council
A003 UID FETCH 20 BODY.PEEK
imap://user;AUTH=*@ minbari.org /shared/foo
A001 AUTHENTICATE KERBEROS_V4
Обмен аутентификационными данными пользователя user . Пароль запрашивается .
A002 SELECT "shared/foo"
Пробелы в аргументах и прочие символы, недопустимые в URL , кодируются в соответствии с требованиями RFC 1738 , где описываются общие правила оформления унифицированных указателей ресурсов.
URL ресурсов IMAP в частности используются расширением MAILBOX-REFERRALS для работы с распределенными ресурсами, предоставляемыми по протоколу IMAP . Это расширение описано в RFC 2193 .
В некоторых случаях бывает целесообразно располагать почтовые ящики не на одном сервере, а на нескольких. Поскольку клиенту заранее не известно, на каком именно сервере находится интересующий его почтовый ящик, он всегда обращается к одному серверу, который, если запрошенный ящик находится на другом сервере, возвращает негативный помеченный ответ со ссылкой на истинное расположение запрошенного ящика. После этого клиент устанавливает соединение с сервером, указанным в полученном URL , и вновь запрашивает почтовый ящик.
Пример :
| C | A001 SELECT REMOTE |
| S | A001 NO Remote mailbox. |
В данном примере клиенту не удалось открыть почтовый ящик, так как он находится на другом сервере – server 2. Получив URL требуемого ресурса, клиент устанавливает соединение с server 2.
| S | * OK IMAP4rev1 server ready |
| C | B001 AUTHENTICATE KERBEROS_V4 |
Обмен аутентификационной информацией
| S | B001 OK user is authenticated |
| C | B002 SELECT remote |
| S | * 12 EXISTS |
| S | * 1 RECENT |
| S | * OK Message 10 is first unseen |
| S | * OK |
| S | * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) |
| S | * OK |
| S | B002 OK Selected completed |
Аналогичные возможности обеспечивает также расширение LOGIN-REFERRALS, описанное в RFC 2221 . Это расширение предназначено для перенаправления аутентифицировавшегося пользователя на сервер, содержащий его почтовые ящики.
Если после аутентификации клиент получает отрицательный ответ, содержащий URL другого сервера, то клиенту следует аутентифицироваться на указанном сервере, так как там, где он только что аутентифицировался, нет доступных ему почтовых ящиков.
Пример :
| C | A001 LOGIN MIKE PASSWORD |
| S | A001 NO try server2. |
Положительный ответ, содержащий URL другого сервера, полученный клиентом после аутентификации, свидетельствует о том, что на основном сервере есть почтовые ящики, доступные данному пользователю, но его персональный почтовый ящик находится на другом сервере.
Пример :
| C | A001 LOGIN MATTHEW PASSWORD |
| S | A001 OK public mailboxes are available |
Описанное в RFC 2342 расширение NAMESPACE дает клиенту возможность с помощью не требующей параметров команды NAMESPACE определить, какие пространства имен задействованы на данном сервере.
Ответ сервера содержит префиксы и иерархические разделители пространств имен
Если какие-то из перечисленных пространств имен не существуют или недоступны данному пользователю, то на их месте в ответе должно стоять слово NIL .
Примеры:
Пользователю доступны только его личные почтовые ящики:
| C | A001 NAMESPACE |
| S | * NAMESPACE (("" "/")) NIL NIL |
| S | A001 OK NAMESPACE command completed |
Анонимному пользователю доступны только ящики, содержащие новости Usenet :
| C | A001 NAMESPACE |
| S | * NAMESPACE NIL NIL (("" ".")) |
| S | A001 OK NAMESPACE command completed |
Доступны личные почтовые ящики, почтовые ящики других пользователей, обратиться к которым можно, указав префикс "~", а также общедоступные ящики с префиксом "# public /" и новости Usenet с префиксом "# news .":
| C | A001 NAMESPACE |
| S | * NAMESPACE (("" "/")) (("~" "/")) (("#public/" "/")("#news." ".")) |
| S | A001 OK NAMESPACE command completed |
Описанное в RFC 2359 расширение UIDPLUS позволяет использовать команду UID совместно с командой EXPUNGE, а также добавляет информацию об уникальных идентификаторах в ответы на команды APPEND, COPY и UID COPY. Тех же результатов можно добиться, используя команды базового протокола, но данное расширение позволяет получить тот же результат несколько быстрее.
Описанное в RFC 2971 расширение ID дает клиенту и серверу возможность обменяться сведениями об установленном на них программном обеспечении.
Команда принимает в качестве аргумента заключенный в скобки набор пар параметр/значение. В общем виде формат команды следующий:
ярлык ID ("параметр1" "значение1" "параметр2" "значение2" …)
Непомеченный ответ сервера имеет аналогичный формат. Как в команде, так и в ответе, вместо сведений может стоять слово NIL , если клиент или сервер не желают сообщать информацию о себе.
В качестве имен параметров можно использовать любые строки длиной не более 30 символов. Следующие имена параметров установлены:
Пример :
| C | a023 ID ("name" "sodr" "version" "19.34") |
| S | * ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" "5.5") |
| S | a023 OK ID completed |