Что такое код imap_close

Содержание
Илон Маск рекомендует:  Что такое код asp aspthreadgatetimeslice

IMAP Модуль

В IMAP модуле CommuniGate Pro реализован IMAP сервер. IMAP сервера позволяют клиентским приложениям (почтовым программам) получать сообщения из папок пользователя, используя Интернет протокол IMAP4rev1 (RFC2060) через TCP/IP сети.

IMAP протокол позволяет клиентским приложениям создавать дополнительные папки пользователя, передвигать сообщения между папками, осуществлять в папках поиск, отмечать сообщения в папках, загружать MIME-структуру хранимых сообщений и загружать отдельные MIME-части сообщений, хранимых в папках пользователя.

IMAP модуль CommuniGate Pro поддерживает как незашифрованные, так и безопасные (SSL/TLS) соединения.

Интернет Протокол Доступа к Сообщениям (IMAP)

Интернет Протокол Доступа к Сообщениям позволяет работать с сообщениями, хранящимися в папках на удалённых почтовых серверах, непосредственно с компьютеров клиентов. Компьютер, на котором запущено приложение — почтовая программа (почтовый клиент), устанавливает соединение с компьютером почтового сервера и сообщает ему имя пользователя и пароль. Если указанному пользователю предоставляется доступ, то почтовое приложение сможет отправлять на почтовый сервер команды. Команды протокола указывают серверу выдать список всех сообщений в папке, загрузить определённые сообщения или удалить их, найти сообщения с определёнными атрибутами, передвинуть сообщения между папками и т.д.

Конфигурирование IMAP Модуля

Для того, что бы настроить параметры IMAP модуля, используйте Веб Интерфейс Администратора. Откройте страницу Доступ в разделе Установки:

Используйте эту настройку для того, что бы указать, какую информацию IMAP модуль должен сохранять в Журнале работы Сервера. Обычно используется уровень Основные (отчёты о передаче сообщений) или уровень Проблемы (передача сообщений и не фатальные ошибки). В случае, если в работе IMAP модуля возникают проблемы, возможно, целесообразным будет увеличить детализацию до уровня Подробности или Всё: в этом случае в Журнал работы Сервера будет также записываться более подробная информация о работе модуля на уровне протокола или на уровне ссылок. Когда проблема решена, верните настройку Уровень Журнала в её обычное значение, иначе Системный Журнал будет очень быстро увеличивать свой размер.

Записи, помещённые IMAP модулем в Журнал работы Сервера, имеют пометку IMAP.

Когда вы указываете ненулевое значение в настройке Максимальное число Каналов, IMAP модуль создаёт так называемый «Приёмник». Модуль начинает принимать все IMAP соединения, которые устанавливают клиенты для того, что бы получать почту с вашего Сервера. Эта настройка используется для того, что бы ограничить число одновременных соединений, которое может принимать IMAP модуль. Если открыто предельное число соединений, то модуль будет отказывать в приёме новых соединений. В этом случае почтовые клиенты должны попытаться соединиться позднее.

По умолчанию, Приёмник IMAP модуля принимает незашифрованные соединения на TCP порт 143 и безопасные соединения на TCP порт 993. Нажмите на ссылку Приёмник для того, что бы настроить порт Приёмника IMAP.

IMAP модуль поддерживает команду STARTTLS, которая позволяет почтовому клиенту устанавливать соединение в незащищённом режиме и затем переводить его в режим безопасного соединения.

Send 'Running' every Если эта опция не установлена в значение Никогда, то IMAP модуль будет следить за длительностью выполнения операций APPEND, COPY и SEARCH. Если выполнение любой из этих операций превышает указанный здесь период времени, то модуль отправляет клиентскому приложению «непомеченный» ответ. Эта возможность может использоваться для того, что бы предотвратить возникновение ситуации тайам-аута у клиентского приложения; также она помогает при работе в конфигурациях с различными NAT-устройствами, которые склонны закрывать соединение, если оно некоторое время неактивно.

Одновременный Доступ

В отличие от множества других IMAP серверов, «блокирующих» открытые папки, IMAP модуль Сервера CommuniGate Pro спроектирован таким образом, что бы обеспечивать одновременный доступ к папке неограниченного числа клиентов.

IMAP модуль использует Менеджер Папок CommuniGate Pro, что позволяет обеспечить одновременный доступ к Папкам для всех типов поддерживаемых протоколов и клиентов. Дополнительную информацию смотрите в разделе Папки.

Список Прав Доступа

IMAP модуль поддерживает RFC2086 (ACL расширение IMAP4). Это расширение протокола позволяет IMAP пользователям предоставлять доступ к своим папкам другим пользователям.

Дополнительную информацию о Списках Прав Доступа Папки (ACL) смотрите в разделе Папки.

Для того, что бы иметь возможность устанавливать Права Доступа, клиент должен использовать современного IMAP клиента, поддерживающего это расширение протокола. Если такой клиент отсутствует, то права доступа к папке можно задать через Веб Интерфейс Пользователя.

Чужие (Общие) и Публичные Папки

CommuniGate Pro позволяет пользователям получать доступ к папкам других пользователей. Дополнительную информацию смотрите в разделе Папки.

Множество популярных IMAP клиентов не поддерживают эту возможность. Однако, для почтовых программ IMAP, использующих «подписку» на папки, существует решение, позволяющее обойти это ограничение. Подписка — это список имён папок, который почтовая программа хранит на сервере. Обычно, почтовые программы создают список подписки во время первоначальной настройки. Впоследствии отображаются только те папки, которые включены в список подписки.

Используя различных IMAP клиентов или Веб Интерфейс Пользователя, пользователь может добавить имя чужой папки (как, например

public/news/company) в свой список подписки. Это приведёт к тому, что IMAP клиенты будут показывать чужую папку наряду с обычными папками пользователя и пользователь сможет работать с этой чужой папкой.

Некоторые IMAP клиенты (такие как Microsoft Outlook и Outlook Express) вообще не поддерживают работу с чужими папками. Для того, что бы эти клиенты получили доступ к совместно используемым папками других пользователей, может использоваться механизм Псевдонима Папки.

Аутентификация Пользователя

IMAP модуль позволяет пользователям использовать все Методы Аутентификации, поддерживаемые Сервером CommuniGate Pro.

Если опция Объявлять об небезопасных методах выключена, и соединение не зашифровано с помощью SSL/TLS, то Сервер добавляет ключевое слово LOGINDISABLED в список поддерживаемых возможностей аутентификации.

Непочтовые Папки

IMAP Модуль CommuniGate Pro обеспечивает доступ к папкам всех Классов (Календарь, Контакты и т.д.). Некоторые клиенты и/или пользователи могут быть поставлены в затруднительное положение, если они сталкиваются с Непочтовыми Папками.

Эти модули включают Непочтовые Папки в ответ IMAP команды LIST, если:

  • Пользователь включил настройку Не-Почтовые Папки видны в IMAP, или
  • команда IMAP LIST имеет расширение CLASS , или
  • была выполнена команда IMAP ENABLE EXTENSIONS

Предупреждения

IMAP Модуль CommuniGate Pro проверяет наличие сообщений с предупреждениями, отправленных аутентифицированному Пользователю. Предупреждающие сообщения передаются клиентской почтовой программе через стандартный код ответа IMAP [ALERT].

IMAP Модуль CommuniGate Pro проверяет наличие предупреждений сразу после аутентификации пользователя и может обнаруживать новые предупреждения и отсылать их пользователю в любое время в течении IMAP сессии.

Направления на Аутентификацию

IMAP Модуль поддерживает RFC2221 (Направления на Аутентификацию).
Как было объяснено в разделе Доступ, все адреса пользователей, заданные в клиентских почтовых программах, обрабатываются через Маршрутизатор.
Если имя пользователя перенаправляется на внешний Интернет адрес (обслуживаемый SMTP модулем), то IMAP модуль возвращает отрицательный ответ и передаёт направление на аутентификацию. Если IMAP клиент поддерживает направления на аутентификацию, то он автоматически переключится на новый адрес.

Пример: Пользователь j.smith перешёл с вашего сервера на сервер othercompany.com как пользователь John. Для того, что бы перенаправлять всю почту пользователя, вы создаёте запись псевдонима в таблице Маршрутизатора:
= John@othercompany.com
Теперь, если пользователь попытается зайти на ваш сервер как j.smith, то сервер будет отвергать это имя пользователя, но при этому будет выдавать направление на аутентификацию:
1234 NO [REFERRAL IMAP://John;AUTH=*@othercompany.com/] account has been moved to a remote system
Если клиентская почтовая программа поддерживает направления на аутентификацию, то она автоматически попытается соединится с сервером othercompany.com как пользователь John.

Мониторинг активности IMAP

Вы можете наблюдать за активностью IMAP модуля через Веб Интерфейс Администратора. Для того, что бы открыть страницы наблюдения за IMAP, нажмите на ссылку Доступ в области Наблюдения:

ID Это поле содержит числовой идентификационный номер IMAP сессии. В Журнале CommuniGate Pro эта сессия отмечается как IMAP-nnnnn, где nnnnn — это идентификационный номер сессии. Адрес Это поле содержит IP адрес присоединившегося клиента. Пользователь Это поле содержит имя Пользователя (после успешной аутентификации). Подсоединён Это поле содержит время соединения (время, в течении которого открыта эта TCP/IP сессия. Состояние Это поле содержит или имя текущей операции, или, если никакой операции не производится, текущее состояние сессии (Authenticating, Selected и т.д.). Обрабатывает Если есть какая-нибудь активная IMAP операция, то это поле содержит время, прошедшее с момента начала операции.

Если IMAP соединение используется для MAPI сессии, то это строка отображается на зеленом фоне.

Статистика активности IMAP доступна через SNMP агент CommuniGate Pro.

Подробности реализации IMAP

В IMAP Модуле CommuniGate Pro реализовано множество расширений протокола IMAP. Реализация некоторых из этих расширений в CommuniGate Pro имеет свои особенности.

QUOTA Каждый пользователь имеет свою Корневую Квоту право доступа. NAMESPACE Стандартный префикс «имени пользователя» в CommuniGate Pro соответствующий Домен. UNSELECT Эта команда IMAP эквивалентна команде CLOSE, но она не удаляет никакие сообщения, отмеченные как \Deleted

Дополнительные Расширения IMAP

В IMAP модуле CommuniGate Pro реализованы также несколько расширений, не являющихся частью IMAP стандарта и не включённые в существующие стандарты Расширения IMAP.

UNSELECT Эта команда IMAP эквивалентна команде CLOSE, но она не удаляет никакие сообщения, отмеченные как \Deleted COPY После имени требуемой папки может может быть указан параметр ENCRYPTED certificateData, где certificateData либо PKI Сертификат в кодировке base64, либо символ звёздочка (*), ссылающийся на личный S/MIME Сертификат аутентифицированного пользователя.
Копируемые сообщения являются S/MIME-зашифрованными при помощи указанного сертификата. MOVE, UID MOVE Эти команды IMAP эквивалентны командам COPY, но если сообщения были скопированы успешно, то они будут удалены. Если сообщения передвигались между папками одного и того же Пользователя, то Квота хранения не проверяется. STATUS Команда STATUS может использовать следующие дополнительные имена элементов данных: INTERNALSIZE Элемент данных, включаемый в ответ — число. Это число указывает размер папки (в том виде, как она хранится на сервере). Этот размер близок, но не обязательно совпадает с суммой значений атрибута RFC822.SIZE для всех сообщений, хранящихся в папке. OLDEST Элемент данных, включенных в ответ — строка типа date_time. Она указывает INTERNALDATE самого старого сообщения в папке. Если в папке нет сообщений, этот элемент данных в ответ не включается. UNSEENMEDIA Элемент данных, включаемый в ответ — число сообщений, которые имеют установленный флаг Media, но не имеют флага Seen.

Пример: A001 STATUS mailbox (UNSEEN OLDEST INTERNALSIZE UNSEENMEDIA)
* STATUS mailbox (UNSEEN 14 OLDEST "23-Feb-2002 07:59:42 +0000" INTERNALSIZE 2345678 UNSEENMEDIA 1)
A001 OK completed
LIST Наряду с опциями, описанными в расширении LISTEXT, команда LIST может использовать следующие дополнительные опции: UIDVALIDITY, CLASS, MESSAGES, UIDNEXT, UNSEEN, INTERNALSIZE, OLDEST, UNSEENMEDIA

4.4.14.3 Протокол Интернет для работы с сообщениями IMAP

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Протокол IMAP 4.1 (INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1, V.Crispin, RFC-2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143. Безопасная версия протокола IMAP использует порт 993. Протокол IMAP представляет собой альтернативу POP-3. Также как и последний он работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.

В отличие от POP3 IMAP хранит почтовые сообщения у себя “вечно” (пока клиент сам не пожелает их стереть).

1. Команды и отклики

Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, которые завершаются последовательностью CRLF. Получатель (клиент или сервер) воспринимает такую строку или последовательность октетов известной длины, за которой следует строка.

1.1 Протокольный отправитель клиента и протокольный получатель сервера

Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например A0001, A0002 и т.д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку. Имеется два случая, когда строка, посланная клиентом, не представляет собой законченную команду. В первом — аргумент команды снабжается кодом, определяющим число октетов в строке (см. описание литеральных строк в разделе “Форматы данных”). Во втором — аргументы команды требуют отклика со стороны сервера (см. описание команды authenticate). В обоих вариантах сервер посылает запрос продолжения команды, если он готов. Такой отклик сервера начинается с символа «+».

Замечание: Если, вместо этого, сервер детектирует ошибку в команде, посылается отклик завершения bad с меткой, требующей игнорирования команды и предотвращения посылки клиентом каких-либо еще запросов.

Отправитель может послать отклик завершения и в случае некоторых других команд (если одновременно исполняется несколько команд) или если данные не имеют меток. В любом случае, ожидается запрос продолжения, клиент предпринимает в ответ соответствующие действия и читает следующий отклик сервера. Во всех вариантах клиент должен завершить отправку одной команды прежде чем послать новую.

Протокольный приемник IMAP 4.1 сервера читает строку команды, пришедшей от клиента, осуществляет ее разбор, выделяет ее параметры и передает серверу данные. По завершении команды сервер посылает отклик.

1.2 Протокольный отправитель сервера и протокольный получатель клиента

Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс «*» и называются непомеченными откликами.

Данные сервера могут быть посланы в ответ на команду клиента или отправлены сервером по своей инициативе. Формат данных не зависит от причины посылки.

Отклик указывает на успешное выполнение операции или на ее неудачу. Отклик использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (указывает на успешное выполнение), no (отмечает неуспех) или bad (указывает на протокольную ошибку, например, не узнана команда или зафиксирована синтаксическая ошибка).

Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера. Он должен предпринять действия, в соответствии с первым символом метки «*» или «+».

Клиент должен быть готов принять любой отклик сервера в любое время. Это касается и не запрошенных данных, присланных сервером. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов.

Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами.

Доступ к сообщениям в IMAP 4.1 осуществляется с помощью уникального идентификатора или порядкового номера сообщения.

1.3 Атрибут сообщения UID

Каждому сообщению ставится в соответствие 32-битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Сообщения, приходящие позднее имеют больший код UID, чем полученные ранее.

В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [IMAP-DISC].

UID ассоциируется с почтовым ящиком и посылается в виде кода uidvalidity отклика (ok) на фазе выбора почтового ящика. Если UID из предыдущей сессии по какой-то причине не может быть использован, UID должен быть инкрементирован.

UID для данного почтового ящика должен всегда изменяться монотонно. Если порядок записей изменен вне рамок IMAP, необходимо перегенерировать UID для данного почтового ящика, так как порядок старых значений UID в этом случае уже не будет монотонным.

Еще одной причиной не сохранения UID может служить стирание старого и создание нового почтового ящика с тем же именем. Так как имя почтового ящика не изменилось, клиент может не знать об этом и пытаться использовать старые UID. Хорошим значением UID можно считать 32-битное представление даты и времени создания почтового ящика. Вполне приемлемо и значение 1, если имеется гарантия, что это значение никогда не будет использовано повторно, даже в случае стирания и создания нового почтового ящика с тем же именем.

UID сообщения не должно изменяться в пределах сессии, его не следует изменять и от сессии к сессии. Однако если невозможно сохранить UID сообщения в последующей сессии, каждая следующая сессия должна иметь новый уникальный код идентификатора, который больше чем любой UID использованный ранее.

Атрибут порядкового номера сообщения

Этот атрибут определяет порядковый номер сообщения в почтовом ящике, начиная с 1. Последующее сообщение всегда имеет значение этого атрибута на 1 большее, чем у предшествующего.

Допускается изменение порядкового номера сообщения на протяжении сессии. Например, когда сообщение удаляется из почтового ящика, номера всех последующих сообщений изменяются. Аналогично, новому сообщению может быть присвоен номер удаленного сообщения.

Номера сообщений могут использоваться при вычислениях, касающихся указателей. Например, если сообщение 287 в почтовом ящике, содержащем 523 сообщения, имеет UID 12345, имеется 286 сообщений, имеющих меньшее значение UID и 236 сообщений с большими UID.

1.4 Атрибут флагов сообщения

Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путем его добавления к этому списку и обнуляется путем его удаления. Существует два типа флагов в IMAP 4.1. Флаг может быть постоянным или действующим только на время данной сессии.

Системным флагом является флаг, чье имя определено в данной спецификации. Все системные флаги начинаются с символа «\». Некоторые системные флаги (\deleted и \seen) имеют специальную семантику, заданную вне рамок данного документа. В настоящее время определены следующие системные флаги:

\seen Сообщение прочитано
\answered На сообщение послан ответ
\flagged Сообщение «помечено» как срочное, требующее особого внимания
\deleted Сообщение помечено как стертое для последующего удаления посредством expunge
\draft Сообщения не является законченным (помечено, как проект).
\recent Сообщение только что положено в почтовый ящик. Эта сессия является первой, где фигурирует данное сообщение; для последующих сессий это сообщение не будет иметь флага \recent. Флаг не может быть изменен клиентом.

Если невозможно определить, является ли эта сессия первой для данного сообщения, его следует считать относящимся к текущей сессии. Ключевое слово определяется реализацией сервера. Ключевые слова не начинаются с символа «\». Серверы могут позволять клиенту создавать новые ключевые слова в почтовом ящике. Постоянные флаги клиент может устанавливать для данного сообщения или удалять на постоянной основе; таким образом, последующая сессия может воспользоваться новыми значениями флагов.

Системный флаг \recent имеет статус флага сессии. Флаг \recent не может использоваться в качестве аргумента команды store, и по этой причине не может быть изменен вообще.

Внутренняя дата и время сообщения на сервере. Это не та дата и время, которые указаны в заголовке [RFC-822], а время и дата получения сообщения. В случае доставки сообщения посредством протокола [SMTP], это должна быть дата и время доставки конечному адресату. В случае сообщений, доставленных командой IMAP 4.1 copy, это должны быть внутренняя дата и время отправителя сообщения. В случае доставки сообщения командой IMAP 4.1 append, это должна быть дата и время, заданные в описании команды append.

Атрибут размера сообщения определяет число октетов в сообщении (рассмотрен в документе [RFC-822]). Атрибут структуры конверта сообщения соответствует требованиям документа [RFC-822]. Атрибут структуры тела сообщения несет в себе информацию о структуре сообщения в соответствии с регламентациями [MIME-IMB]. Кроме доставки текстового сообщения, как это описано в RFC-822, IMAP 4.1 позволяет осуществлять передачу части текста. Можно отдельно доставить заголовок и тело сообщения или даже часть тела сообщения.

2. Состояние и диаграмма исполнения

Сервер IMAP 4.1 находится в одном из четырех состояний. Большинство команд допустимо только во вполне определенных состояниях. Если клиент пытается реализовать команду в неправильном состоянии, это рассматривается как протокольная ошибка. В этом случае сервер откликнется командой bad или no в зависимости от реализации конкретной программы.

В состоянии без аутентификации клиент должен предоставить имя и пароль, прежде чем станет доступно большинство команд. Переход в это состояние производится при установлении соединения, если только для данного соединения не была проведена предварительная аутентификация.

В состоянии аутентификации клиент идентифицирован и должен выбрать почтовый ящик, прежде чем ему станут доступны команды для работы с сообщениями. Переход в это состояние происходит при установлении соединение с предварительной аутентификацией, когда выданы все необходимые идентификационные данные или при ошибочном выборе почтового ящика.

В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика. В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.

Рис. 4.4.14.2.1. Схема состояний для протокола IMAP

(1) Cоединение без предварительной аутентификации (отклик OK)
(2) Cоединение с предварительной аутентификацией (отклик PREAUTH)
(3) Соединение отвергнуто (отклик BYE)
(4) Успешное завершение команды LOGIN или AUTHENTICATE
(5) Успешное завершение команды SELECT или EXAMINE
(6) Выполнение команды CLOSE, или неудачная команда SELECT или EXAMINE
(7) Выполнение команды LOGOUT, закрытие сервера, или прерывание соединения

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

IMAP 4.1 использует текстовые команды и отклики. Данные в IMAP 4.1 могут иметь одну из следующих форм: атом, число, строка, список, заключенный в скобки или NIL.

Атом состоит из одного или более неспециализированных символов.

Число состоит из одной или более цифр и характеризует некоторое числовое значение.

Строка может иметь одну из двух форм: литерал или строка в кавычках. Литеральная форма является основной формой строки. Строка в кавычках является альтернативной формой, исключающей избыточность литеральной формы за счет ограничений, налагаемых на символы, используемые в строке.

Литерал представляет собой нуль или более октетов (включая CR и LF). Литерал начинается с октета, где хранится число символов. Этот октет заключается в фигурные скобки, за которыми следует последовательность CRLF. В случае передачи литералов от сервера к клиенту за CRLF следуют непосредственно данные. При передаче литералов от клиента серверу клиент должен подождать прихода команды продолжения, прежде чем начать пересылку данных.

Строка в кавычках представляет собой последовательность из нуля или более 7-битовых символов за исключением CR и LF, начинающуюся и завершающуюся двойной кавычкой ( ). Пустая строка представляется как «» или как литерал <0>, за которым следует последовательность CRLF.

Замечание: Даже если число октетов равно нулю, клиент, передающий литерал должен подождать прихода команды продолжения.

3.1. 8-битовые и двоичные строки

8-битовая текстовая и двоичная почта поддерживается посредством шифрования [MIME-IMB]. Реализации IMAP 4.1 могут передавать 8-битные или многооктетные символы в литералах, но должны это делать, только когда определен [CHARSET]. Если даже определена кодировка BINARY, незакодированные двоичные строки не могут быть разрешены. «Двоичная строка» — это любая строка из NUL символов. Реализации программ должны перекодировать двоичные данные в текстовую форму, такую как BASE64, прежде чем их пересылать. Строка с большим числом символов CTL может рассматриваться как двоичная.

3.2. Список в скобках

Структуры данных представляются в виде списков, помещенных в скобки, элементы списка разделяются пробелами. Такой список может включать в себя другие “списки в скобках”. Пустой список выглядит как () — “список в скобках” с нулевым числом членов.

3.3. NIL

Специальный атом «NIL» представляет собой указание на отсутствие каких-то определенных данных типа строка или “список в скобках”. Его следует отличать от пустой строки «» или пустого “списка в скобках” ().

4. Операционные соображения
4.1. Присвоение имени почтовому ящику

Интерпретация имен почтовых ящиков является независимой от конкретной программной реализации. Однако имя почтового ящика INBOX является специальным именем, зарезервированным для «первичного почтового ящика данного пользователя на данном сервере» (значение не зависит от использования строчных или прописных букв). Почтовые ящики могут образовывать иерархическую структуру. Если желательно экспортировать иерархию имен почтовых ящиков, имена почтовых ящиков должны быть упорядочены по буквам слева направо.

4.2. Соглашение о пространстве имен почтовых ящиков

В соответствии с соглашением первый иерархический элемент любого имени почтового ящика, который начинается с символа «#» указывает на “пространство имен” остальной части имени. Например, реализации, которые предлагают доступ к группам новостей USENET могут использовать пространство имен «#news», для того чтобы отделить пространство имен групп новостей от имен других почтовых ящиков. Таким образом, группа новостей comp.mail.misc будет иметь имя почтового ящика «#news.comp.mail.misc», а имя «comp.mail.misc» может относиться к другому объекту (напр., к почтовому ящику пользователя).

4.3. Международное соглашение об именах почтовых ящиков

Согласно договоренности имена международных почтовых ящиков специфицированы в соответствии модифицированной версией кодировки UTF-7, описанной в [UTF-7]. Целью этих модификаций было устранение следующих проблем, связанных с UTF-7:

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

«, это вступает в конфликт с тем, что некоторые серверы рассматривают этот символ, как указатель на базовый каталог (home).

  • UTF-7 допускает разнообразные формы представления одних и тех же строк, в частности, печатные символы US-ASCII могут использоваться в закодированной форме.
  • В модифицированном UTF-7, печатные символы US-ASCII за исключением «&» представляются в исходном виде; то есть, символами со значениями октетов 0x20-0x25 и 0x27-0x7e. Символ «&» (0x26) представляется в виде двух октетной последовательности «&-«. Все другие символы (значения октетов 0x00-0x1f, 0x7f-0xff, и все уникодные 16-битовые октеты) представляются в модифицированной кодировке BASE64, с дополнительными видоизменениями из [UTF-7]. Модифицированная BASE64 не должна использоваться для представления любых печатных символов US-ASCII, которые должны представлять самих себя.

    Символ «&» используется для перехода к модифицированной кодировке BASE64 а «-» для возврата назад к US-ASCII. Все имена начинаются с US-ASCII, и должны завершаться US-ASCII (то есть, имя, которое заканчивается уникодным 16-битовым октетом, должно быть завершено символом «-«). Примером может служить имя почтового ящика, в котором смешаны фрагменты текста на английском, японском и китайском языках:

    4.4. Размер почтового ящика и актуализации состояния сообщений

    В любое время сервер может послать данные, которые клиент не запрашивал. Иногда, такое поведение системы является необходимым. Например, агенты, внешние по отношению к серверу, могут положить сообщения в почтовый ящик, изменить флаги сообщения в почтовом ящике (например, одновременный доступ в почтовый ящик нескольких агентов), или даже удалить сообщения из почтового ящика. Сервер должен автоматически послать уведомление об изменении размера почтового ящика, если такое изменение произошло в процессе выполнения команды. Сервер должен автоматически послать уведомление об изменении флагов сообщений, не требуя соответствующего запроса клиента. Имеются специальные правила для оповещения клиента сервером об удалении сообщений, чтобы избежать ошибок синхронизации (смотри также описание EXPUNGE). Программа клиента должна своевременно фиксировать изменения размера почтового ящика. Она не должна полагаться на то, что любая команда после начального выбора почтового ящика возвращает значение его размера.

    4.5. Отклик в случае, когда не исполняется никакой команды

    Реализациям сервера разрешается посылать непомеченные отклики (за исключением EXPUNGE), если в это время не выполняется ни одной команды. Реализации, которые посылают такие отклики, должны учитывать соображения управления трафиком. В частности, они должны либо (1) проверить, что размер данных не превосходит транспортные возможности, или (2) использовать неблокирующую запись.

    4.6. Таймер автоматического отключения (Autologout)

    Если сервер имеет таймер выгрузки в случае длительной пассивности, тогда такой таймер должен быть настроен на время, по крайней мере, 30 минут. Получения любой команды от клиента в течение этого периода должно быть достаточно для сброса этого таймера.

    4.7. Одновременное исполнение нескольких команд

    Клиент может послать другую команду, не дожидаясь отклика на предшествующую, сервер может начать обработку другой команды до завершения обработки текущей.

    Исключение может составлять случаи, когда результат выполнения одной команды зависит от выполнения других команд. Клиенты не должны посылать несколько команд, не дожидаясь результата, если возможна неопределенность из-за их взаимозависимости. Если сервер детектирует возможную неопределенность, он должен исполнить их последовательно в порядке их получения от клиента.

    Наиболее очевидный пример неопределенности реализуется, например, когда последовательно выполняются команды FETCH для флагов сообщения и STORE для тех же самых флагов.

    Неочевидные неопределенности возникают с командами, которые допускают немаркированный отклик EXPUNGE (команды отличные от FETCH, STORE и SEARCH), так как немаркированный отклик EXPUNGE может нарушить корректность порядковых номеров сообщений для последующих команд. Это не представляет проблем для команд FETCH, STORE или SEARCH, так как серверам запрещено посылать отклики EXPUNGE, когда исполняется одна их этих команд. Следовательно, если клиент посылает любую команду, отличную от FETCH, STORE или SEARCH, он должен ждать отклика, прежде чем посылать команду, содержащую номер сообщения. Например, следующая последовательность команд (без ожидания) является некорректной:

    FETCH + NOOP + STORE
    STORE + COPY + FETCH
    COPY + COPY
    CHECK + FETCH

    Ниже представлены примеры последовательностей, не требующих ожидания завершения предшествующих инструкций:

    FETCH + STORE + SEARCH + CHECK
    STORE + COPY + EXPUNGE

    5. Команды клиента

    Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.

    5.1. Команды клиента — любое состояние

    Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.

    5.1.1. Команда CAPABILITY

    Аргументы: отсутствуют.
    Отклики: Необходим немаркированный отклик: CAPABILITY.
    Результат: OK — успешное завершение команды;
    BAD — команда неизвестна или неверный аргумент

    Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с «IMAP 4.1» в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с «AUTH=» указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора «blurdybloop» могут быть описаны как «AUTH=XBLURDYBLOOP», а не «XAUTH=BLURDYBLOOP» или «XAUTH=XBLURDYBLOOP».

    Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации.

    Пример: C: abcd CAPABILITY
    S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
    S: abcd OK CAPABILITY completed

    5.1.2. Команда NOOP

    Аргументы: отсутствуют.
    Отклики: никакого специального отклика на эту команду не требуется.
    Результат: OK — команда успешно завершена;
    BAD — команда неизвестна или неверен аргумент;
    Команда NOOP ничего не делает и всегда успешно завершается.

    Так как любая команда может прислать немаркированные данные об изменении состояния, команда NOOP может использоваться, как периодический запрос нового сообщения или информации об изменении статуса в периоды неактивности. Команда NOOP может также использоваться для сброса таймера прерывания сессии сервером из-за отсутствия активности.

    Пример: C: a002 NOOP
    S: a002 OK NOOP completed
    . . .
    C: a047 NOOP
    S: * 22 EXPUNGE
    S: * 23 EXISTS
    S: * 3 RECENT
    S: * 14 FETCH (FLAGS (\Seen \Deleted))
    S: a047 OK NOOP completed

    5.1.3. Команда LOGOUT

    Аргументы: отсутствуют.
    Отклики: необходим немаркированный отклик BYE.
    Результат: OK — прерывание сессии завершено;
    BAD — неизвестная команда или неверный аргумент.

    Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.

    Пример: C: A023 LOGOUT
    S: * BYE IMAP 4.1 Server logging out
    S: A023 OK LOGOUT completed
    (Сервер и клиент разорвали соединение)

    5.2. Команды клиента — в состоянии без аутентификации

    В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.

    Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени «anonymous». Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.

    По завершении аутентификации невозможно вернуться непосредственно в состояние “без аутентификации”. В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии “без аутентификации” возможны команды: AUTHENTICATE и LOGIN.

    5.2.1. Команда AUTHENTICATE

    Аргументы: имя механизма аутентификации.
    Отклики: может быть запрошена дополнительная информация.

    Результат OK Аутентификация завершена, осуществлен переход в состояние «аутентификация выполнена»;
    NO Ошибка аутентификации: неподдерживаемый механизм аутентификации, параметры аутентификации отвергнуты;
    BAD Неизвестная команда или неверный аргумент, механизм аутентификации прерван.

    Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.

    Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом «+», за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только «*». Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.

    Механизм защиты обеспечивает целостность и конфиденциальность соединения. Если механизм защиты согласовыван, то в дальнейшем он используется для всех сообщений, проходящих через данное соединение. Механизм защиты начинает действовать сразу после ввода последовательности CRLF, которая завершает аутентификационный обмен для клиента, и прихода CRLF маркированного отклика OK сервера. Раз механизм защиты вступил в силу, поток октетов команд и откликов заносится в буферы шифрованного текста. Каждый буфер передается через соединение в виде потока октетов, который начинается с четырех октетов, содержащих длину последующих данных. Максимальный размер буфера для текста-шифра определяется выбранным механизмом защиты.

    Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант.

    Пример: S: * OK KerberosV4 IMAP4rev1 Server
    C: A001 AUTHENTICATE KERBEROS_V4
    S: + AmFYig==
    C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
    +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
    WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
    S: + or//EoAADZI=
    C: DiAF5A4gA+oOIALuBkAAmw==
    S: A001 OK Kerberos V4 authentication successful

    5.2.2. Команда LOGIN

    Аргументы: имя пользователя, пароль.
    Отклики: команда не требует какого-либо специального отклика.
    Результат: OK — login завершено, система в состоянии с аутентификацией;
    NO — login не прошла: имя пользователя или пароль отвергнуты;
    BAD — команда неизвестна или неверный аргумент.

    Команда LOGIN идентифицирует клиента серверу и передает пароль пользователя открытым текстом.

    Пример: C: a001 LOGIN SMITH S ESAME
    S: a001 OK LOGIN completed

    5.3. Команды клиента в состоянии «аутентификация осуществлена»

    В состоянии «аутентификация осуществлена» разрешены команды манипуляции почтовыми ящиками, как объектами-атомами. Команды SELECT и EXAMINE реализует выбор почтового ящика и переход в состояние «выбрано» .

    В добавление к стандартным командам (CAPABILITY, NOOP и LOGOUT), в состоянии «аутентификация осуществлена» допустимы следующие команды: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND.

    5.3.1. Команда SELECT

    Аргументы: имя почтового ящика.
    Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
    опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.

    Результат: OK — процедура выбора закончена, система находится в состоянии «выбрано» ;
    NO — выбор неудачен: нет такого ящика, доступ к почтовому ящику невозможен;
    BAD — команда неизвестна или неверен аргумент.

    Команда SELECT осуществляет выбор почтового ящика, так чтобы обеспечить доступ к сообщениям, находящимся там. Прежде чем присылать клиенту OK, сервер должен послать клиенту следующие немаркированные данные:

    FLAGS — флаги, определенные для почтового ящика.
    EXISTS Число сообщений в почтовом ящике.
    RECENT Число сообщений с набором флагов \Recent.
    OK [UIDVALIDITY ] Уникальный идентификатор корректности.

    Сервер должен также послать «невидимый» код отклика внутри немаркированного сообщения OK, который представляет собой порядковый номер первого невидимого сообщения в почтовом ящике.

    Если клиент не может изменить состояние одного или нескольких флагов, перечисленных в немаркированном отклике FLAGS, сервер должен в немаркированном отклике OK послать код PERMANENTFLAGS, перечислив флаги, которые клиент может изменить.

    Единовременно для одного соединения может быть выбран только один почтовый ящик. Одновременный доступ к нескольким почтовым ящикам требует установления соответствующего числа соединений. Команда SELECT автоматически аннулирует выбор почтового ящика при повторной попытке его выбора. Следовательно, если почтовый ящик был выбран, а команда SELECT не прошла, предшествующий выбор ящика аннулирован. Если клиенту разрешено модифицировать почтовый ящик, сервер должен снабжать маркированный текст отклика OK префиксом «[READ-WRITE]».

    Если клиенту не позволено модифицировать почтовый ящик, но разрешен доступ для чтения, почтовый ящик выбирается в режиме «только для чтения» и сервер должен перед посылкой текста передать маркированный отклик OK в ответ на команду SELECT с кодом отклика «[READ-ONLY]». Доступ «только для чтения» тем не менее, отличается от команды EXAMINE, при нем некоторые почтовые ящики позволяют изменять постоянное состояние некоторых флагов пользователя. Сетевые новости из файла .newsrc являются примером того, как некоторые состояния могут изменяться для почтовых ящиков типа «только для чтения».

    Пример: C: A142 SELECT INBOX
    S: * 172 EXISTS
    S: * 1 RECENT
    S: * OK [UNSEEN 12] Message 12 is first unseen
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: * FLAGS (\Answered \Flag ged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
    S: A142 OK [READ-WRITE] SELECT completed

    5.3.2. Команда EXAMINE

    Аргументы: имя почтового ящика.
    Отклики: необходимы немаркированные отклики: FLAGS, EXISTS, RECENT;
    опционны немаркированные отклики OK: UNSEEN, PERMANENTFLAGS.

    Результат: OK Осмотр закончен, система в состоянии «выбор сделан» ;
    NO Осмотр не прошел, система в состоянии «аутентификация выполнена» ; нет такого почтового ящика; доступ к почтовому ящику невозможен;
    BAD Команда неизвестна или неверен аргумент.

    Команда EXAMINE идентична команде SELECT и дает тот же результат, однако, выбранный почтовый ящик идентифицируется как «только для чтения». Никакие изменения постоянного состояния почтового ящика в этом случае не разрешены. Текст маркированного отклика OK на команду EXAMINE должен начинаться с кода отклика «[READ-ONLY]».

    Пример: C: A932 EXAMINE blurdybloop
    S: * 17 EXISTS
    S: * 2 RECENT
    S: * OK [UNSEEN 8] Message 8 is first unseen
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
    S: A932 OK [READ-ONLY] EXAMINE completed

    5.3.3. Команда CREATE

    Аргументы: имя почтового ящика.
    Отклики: на эту команду не посылается каких-либо откликов.

    Результат OK Команда выполнена;
    NO команда не выполнена: почтовый ящик с таким именем не может быть создан;
    BAD команда неизвестна или неверен аргумент.

    Команда CREATE создает почтовый ящик с заданным именем. Отклик OK присылается в случае, когда новый почтовый ящик с указанным именем создан. Попытка создания INBOX или почтового ящика с именем, существующего почтового ящика, является ошибкой . Любая ошибка при попытке создания почтового ящика вызовет маркированный отклик NO.

    Если имя почтового ящика имеет суффикс с символом сепаратора иерархии сервера (в соответствии с тем, что получено при выполнении команды LIST), то это является декларацией клиента о намерении создать почтовый ящик с именем в рамках указанной иерархии. Реализации сервера, которые не требуют этой декларации, должны ее игнорировать.

    Если символ-сепаратор иерархии сервера появляется где-либо еще в имени, сервер должен создать любые имена более высокого уровня иерархии, которые необходимы для успешного завершения выполнения команды CREATE. Другими словами, попытка создания «foo/bar/zap» на сервере, для которого символ «/» является иерархическим сепаратором, должна привести к созданию foo/ и foo/bar/, если они до этого не существовали.

    Если новый почтовый ящик создан с именем стертого почтового ящика, то его идентификатор должен быть больше, использованного его предшественником, если только новая версия ящика не имеет другого значения UID.

    Пример: C: A003 CREATE owatagusiam/
    S: A003 OK CREATE completed
    C: A004 CREATE owatagusiam/blurdybloop
    S: A004 OK CREATE completed

    Замечание: интерпретация этого примера зависит от того, является ли символ «/» иерархическим сепаратором. Если «/» иерархический сепаратор, создается новый иерархический уровень с «owatagusiam» с новым членом иерархии этого уровня «blurdybloop». В противном случае создаются два почтовых ящика на одном и том же уровне иерархии.

    5.3.4. Команда DELETE

    Аргументы: имя почтового ящика.
    Отклики: команда не требует каких-либо откликов.
    Результат: OK — команда завершена;
    NO — ошибка при выполнении команды: не удается стереть ящик с этим именем;
    BAD — команда неизвестна или неверен аргумент.

    Команда DELETE навечно удаляет почтовый ящик с указанным именем. При этом присылается маркированный отклик OK только в том случае, когда ящик уничтожен. Ошибкой считается попытка стереть INBOX или ящик с несуществующим именем.

    Команда DELETE не должна удалять ящики с более низкой иерархией, чем текущая. Например, если почтовый ящик «foo» имеет иерархическую структуру «foo.bar» (предполагается, что «.» является иерархическим сепаратором), удаление «foo» не должно удалять «foo.bar». Считается ошибкой попытка удаления имени, которому соответствуют нижележащие иерархические уровни, имеющие атрибут \Noselect.

    Разрешено удалять имена, которым соответствуют нижележащие иерархические уровни, но не имеющие атрибута имени \Noselect. В этом случае все сообщения из этого почтового ящика также будут удалены, а имя получит атрибут \Noselect.

    Значение наибольшего используемого уникального идентификатора удаленных почтовых ящиков должно сохраняться, так чтобы новые созданные ящики с тем же именем не использовали идентификаторы своих предшественников, если только новый ящик не имеет другое значение UID.

    Примеры: C: A682 LIST «» *
    S: * LIST () «/» blurdybloop
    S: * LIST (\Noselect) «/» foo
    S: * LIST () «/» foo/bar
    S: A682 OK LIST completed
    C: A683 DELETE blurdybloop
    S: A683 OK DELETE completed
    C: A684 DELETE foo
    S: A684 NO Name «foo» has inferior hierarchical names
    C: A685 DELETE foo/bar
    S: A685 OK DELETE Completed
    C: A686 LIST «» *
    S: * LIST (\Noselect) «/» foo
    S: A686 OK LIST completed
    C: A687 DELETE foo
    S: A687 OK DELETE Completed
    C: A82 LIST «» *
    S: * LIST () «.» blurdybloop
    S: * LIST () «.» foo
    S: * LIST () «.» foo.bar
    S: A82 OK LIST completed
    C: A83 DELETE blurdybloop
    S: A83 OK DELETE completed
    C: A84 DELETE foo
    S: A84 OK DELETE Completed
    C: A85 LIST «» *
    S: * LIST () «.» foo.bar
    S: A85 OK LIST completed
    C: A86 LIST «» %
    S: * LIST (\Noselect) «.» foo
    S: A86 OK LIST completed

    5.3.5. Команда RENAME

    Аргументы: имя существующего почтового ящика, имя нового почтового ящика.
    Отклики: эта команда не требует каких-либо специфических откликов.

    Результат: OK переименование успешно осуществилось;
    NO переименование не прошло: не удалось переименовать ящик с данным именем, не удалось присвоить новое имя;
    BAD команда неизвестна или неверен аргумент.

    Команда RENAME изменяет имя почтового ящика. Маркированный отклик OK присылается лишь в случае, когда почтовый ящик переименован. Считается ошибкой попытка переименовать не существующий почтовый ящик или присвоить ящику уже имеющееся имя. Любая ошибка при переименовании вызовет маркированный отклик NO.

    Если ящик содержит в себе иерархическую структуру, имена этой структуры не должны меняться. Например, переименование «foo» в «zap» переименует «foo/bar» (предполагая, что «/» является иерархическим разделителем) в «zap/bar».

    Значение наибольшего использованного уникального идентификатора имени старого почтового ящика должно быть сохранено, так чтобы новый создаваемый с тем же именем почтовый ящик не использовал идентификатора своего предшественника, если только он не имеет другого значения UID.

    Переименование INBOX разрешено, но имеет свою специфику. Оно перемещает все сообщения в почтовый ящик с новым именем, оставляя INBOX пустым. Если реализация сервера поддерживает иерархические системы имен INBOX, это никак не сказывается на переименовании INBOX.

    Примеры: C: A682 LIST «» *
    S: * LIST () «/» blurdybloop
    S: * LIST (\Noselect) «/» foo
    S: * LIST () «/» foo/bar
    S: A682 OK LIST completed
    C: A683 RENAME blurdybloop sarasoop
    S: A683 OK RENAME completed
    C: A684 RENAME foo zowie
    S: A684 OK RENAME Completed
    C: A685 LIST «» *
    S: * LIST () «/» sarasoop
    S: * LIST (\Noselect) «/» zowie
    S: * LIST () «/» zowie/bar
    S: A685 OK LIST completed
    C: Z432 LIST «» *
    S: * LIST () «.» INBOX
    S: * LIST () «.» INBOX.bar
    S: Z432 OK LIST completed
    C: Z433 RENAME INBOX old-mail
    S: Z433 OK RENAME completed
    C: Z434 LIST «» *
    S: * LIST () «.» INBOX
    S: * LIST () «.» INBOX.bar
    S: * LIST () «.» old-mail
    S: Z434 OK LIST completed

    5.3.6. Команда SUBSCRIBE

    Аргументы: имя почтового ящика.
    Отклики: эта команда не требует каких-либо специфических откликов.
    Результат: OK — процедура подписки завершена;
    NO — подписка не прошла: подписка для данного имени невозможна;
    BAD — команда неизвестна или неверен аргумент.

    Команда SUBSCRIBE добавляет специфицированное имя почтового ящика к списку «активных» или «подписных» ящиков сервера, как это реализуется командой LSUB. Эта команда присылает маркированный отклик OK только в случае успешного осуществления подписки.

    Сервер может проверить аргумент команды SUBSCRIBE, чтобы проконтролировать его корректность для данного почтового ящика. Однако он не должен в одностороннем порядке удалять существующее имя почтового ящика из подписного листа, даже если ящика с таким именем более не существует.

    Замечание: это требование возникает потому, что некоторые серверы могут удалить почтовый ящик с известным именем, например, «system-alerts») после того как срок годности его содержимого истек с тем, чтобы создать его вновь при появлении новых сообщений.

    Пример: C: A002 SUBSCRIBE #news.comp.mail.mime
    S: A002 OK SUBSCRIBE completed

    5.3.7. Команда UNSUBSCRIBE

    Аргументы: имя почтового ящика.
    Отклики: эта команда не требует каких-либо специфических откликов.
    Результат: OK — ликвидация подписки прошла успешно;
    NO — ликвидация подписки не прошла: это невозможно для данного имени;
    BAD — команда неизвестна или неверен аргумент.

    Команда UNSUBSCRIBE удаляет специфицированный почтовый ящик из списка «активных» или «подписных» почтовых ящиков данного сервера, как это определяется командой LSUB. Эта команда возвращает маркированный отклик OK только в случае, если ликвидация подписки прошла успешно.

    Пример: C: A002 UNSUBSCRIBE #news.comp.mail.mime
    S: A002 OK UNSUBSCRIBE completed

    5.3.8. Команда LIST

    Аргументы: имя,
    имя почтового ящика может содержать символы подмены (wildcard).
    Отклики: немаркированные отклики LIST.

    Результат: OK команда list выполнена;
    NO команда не прошла: не возможно выполнение list для данного образца или имени;
    BAD команда неизвестна или неверен аргумент.

    Команда LIST возвращает субнабор имен из полного набора, доступного клиенту. Присылается нуль или более немаркированных откликов LIST, содержащих атрибуты имен, иерархические разделители и имена.

    Команда LIST должна возвращать данные быстро без существенных задержек. Например, она не должна тратить время на выяснение статуса (\Marked или \Unmarked) или на выполнение другой трудоемкой обработки, ведь если каждое имя требует одной секунды, то обработка списка из 1200 имен займет 20 минут.

    Аргумент, содержащий пустую строку образца имени («»), указывает, что имя почтового ящика интерпретируется также, как это делает команда SELECT. Присланные имена почтовых ящиков должны соответствовать полученному шаблону имени. Непустой аргумент является шаблоном имени почтового ящика или уровеня иерархии и указывает на контекст, в котором интерпретируется имя. Пустой аргумент имени («») представляет собой специальный запрос, требующий присылки иерархического разделителя и корневого имени. Значение, возвращаемое в качестве корневого имени, может быть нулем, если шаблону не соответствует никакая иерархия. Иерархический разделитель присылается во всех случаях. Это позволяет клиенту получить иерархический разделитель даже в случае, когда нет почтовых ящиков, соответствующих данному имени.

    Шаблон и имя почтового ящика интерпретируются по-разному в зависимости от реализации. В каноническом варианте анализ происходит слева направо.

    Любая часть аргумента шаблона, которая включена в интерпретированную форму, должна предшествовать интерпретированной форме. Она должна иметь тот же формат, что и аргумент шаблона имени. Это правило позволяет клиенту определить, соответствует ли присланное имя почтового ящика контексту шаблона. Без этого правила, клиент должен был бы знать семантику имен сервера.

    Ниже приведены некоторые примеры того, как могут интерпретироваться образцы и имена почтовых ящиков на серверах базирующихся на UNIX:

    smith/Mail/

    smith/Mail/foo.*

    smith/Mail/

    fred/Mail/*

    fred/Mail/*

    Шаблон Имя почтового ящика Интерпретация
    foo.*
    Archive/ % archive/%
    #news. comp.mail.* #news.comp.mail.*
    /usr/doc/foo /usr/doc/foo
    archive/

    Первые три примера демонстрируют интерпретацию в контексте аргумента шаблона. Заметьте, что «

    smith/Mail» не должно преобразоваться во что-то подобное «/u2/users/smith/Mail», иначе для клиента было бы невозможно определить, соответствовала ли интерпретация контексту шаблона.

    Символ «*» представляет собой подмену (wildcard), и соответствует нулю или более символов в данной позиции. Символ «%» подобен «*», но он не соответствует иерархическому разделителю. Если символ «%» является последним символом имени почтового ящика, то в отклике будут присланы и соответствующие уровни иерархии. Если эти уровни не являются почтовыми ящиками, которые можно выбрать, то их имена снабжаются атрибутом \Noselect. Реализациям сервера таким образом позволено спрятать некоторые почтовые ящики, имена которых могли бы быть раскрыты с использованием шаблонов с символами подмены (wildcard). Например, сервер на основе UNIX может ограничить интерпретацию «*» так, что начальный символ «/» будет приводить к несоответствию имени шаблону.

    Специальное имя INBOX включается в выдачу команды LIST, если INBOX поддерживается данным сервером для данного пользователя и, если строка «INBOX», напечатанная прописными буквами, соответствует интерпретированному шаблону.

    Пример: C: A101 LIST «» «»

    S: * LIST (\Noselect) «/» «»
    S: A101 OK LIST Completed
    C: A102 LIST #news.comp.mail.misc «»
    S: * LIST (\Noselect) «.» #news.
    S: A102 OK LIST Completed
    C: A103 LIST /usr/staff/jones «»
    S: * LIST (\Noselect) «/» /
    S: A103 OK LIST Completed
    C: A202 LIST

    /Mail/ %
    S: * LIST (\Noselect) «/»

    /Mail/meetings
    S: A202 OK LIST completed

    5.3.9. Команда LSUB

    Аргументы: имя-шаблон,
    имя почтового ящика может содержать символы подмены (wildcards).
    Отклики: немаркированный отклик: LSUB

    Результат: OK команда успешно исполнена;
    NO команда не прошла: не возможна выдача списка для предлагаемого шаблона или имени;
    BAD команда неизвестна или неверен аргумент.

    Команда LSUB возвращает субнабор имен из списка пользователя, который декларирован как «активный» или «подписной». При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.

    Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует.

    Пример: C: A002 LSUB «# news.» «comp.mail.*»
    S: * LSUB () «.» #news.comp.mail.mime
    S: * LSUB () «.» #news.comp.mail.misc
    S: A002 OK LSUB completed

    5.3.10. Команда STATUS

    Аргументы: имя почтового ящика, статусная информация имен.
    Отклики: немаркированные отклики: STATUS.
    Результат: OK — команда успешно выполнена;
    NO — команда не прошла: нет статусной информации для данного имени;
    BAD — команда неизвестна или неверен аргумент.

    Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности команда STATUS не должна вызывать потерю флага \Recent).

    Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении.

    В отличии от команды LIST, команда STATUS не гарантирует быстрого отклика. В некоторых реализациях сервер обязан открыть почтовый ящик в режиме «только чтение», чтобы получить нужные статусные данные. Кроме того, команда STATUS не допускает символов подмены в шаблоне имени. В настоящее время определены следующие статусные данные, которые могут быть запрошены:

    MESSAGES Число сообщений в почтовом ящике
    RECENT Число сообщений с установленным флагом \Recent
    UIDNEXT Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантируется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже если оно после этого стерто.
    UIDVALIDITY Уникальный валидатор почтового ящика
    UNSEEN Число сообщений, не имеющих установленного флага \Seen

    Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
    S: A042 OK STATUS completed

    5.3.11. Команда APPEND

    Аргументы : имя почтового ящика,
    опционно — флаг списка со скобками,
    опционно — строка даты и времени,
    литерал сообщения

    Отклики : команда не требует какого-либо специального отклика

    Результат: OK команда успешно исполнена
    NO команда не прошла: добавление в почтовый ящик не удалось, ошибка во флагах или дате/времени, или в тексте сообщения
    BAD команда неизвестна или неверен аргумент

    Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.

    Если специфицировано date_time, в результирующем сообщении должна быть установлена внутренняя дата, в противном случае, внутренняя дата и время результирующего сообщения будут установлены по умолчанию равными текущим значениям. Если команда append по какой-то причине не прошла, почтовый ящик должен быть возвращен в состояние, которое он имел до команды APPEND.

    Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не должен автоматически создавать новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика «[TRYCREATE]» в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND.

    Если в настоящее время почтовый ящик и выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS. Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK).

    Пример: C: A003 APPEND saved-messages (\Seen) <310>
    C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
    C: From: Fred Foobar
    C: Subject: afternoon meeting
    C: To: mooch@owatagu.siam.edu
    C: Message-Id:
    C: MIME-Version: 1.0
    C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    C:
    C: Hello Joe, do you think we can meet at 3:30 tomorrow?
    C:
    S: A003 OK APPEND completed

    Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [SMTP].

    5.4. Команды клиента в состоянии «выбор сделан»

    В состоянии «выбор сделан», разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.

    5.4.1. Команда CHECK

    Аргументы: отсутствуют.
    Отклики: команда не требует какого-либо специального отклика;
    Результат: OK — проверка завершена;
    BAD — команда неизвестна или неверен аргумент.

    Команда CHECK осуществляет проверку выбранного почтового ящика. Проверка относится к любым характеристикам, зависящим от реализации (например, выявление положения почтового ящика в памяти сервера и на диске). Если сервер не поддерживает таких возможностей, команда эквивалентна NOOP.

    Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK.

    Пример: C: FXXZ CHECK
    S: FXXZ OK CHECK Completed

    5.4.2. Команда CLOSE

    Аргументы: отсутствуют.
    Отклики: команда не требует какого-либо специального отклика.
    Результат: OK — команда выполнена, система в состоянии «аутентификация выполнена»;
    NO — команда не прошла, никакого ящика не выбрано;
    BAD — команда неизвестна или неверен аргумент.

    Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние «аутентификация выполнена». Никакого немаркированного отклика EXPUNGE не посылается.

    Никаких сообщений не удаляется и никаких флагов ошибки не возвращается, если почтовый ящик был выбран командой EXAMINE или находился в режиме «только для чтения».

    Даже если почтовый ящик выбран, команды SELECT, EXAMINE или LOGOUT могут быть использованы без предварительного исполнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT безоговорочно закрывают выбранный в данный момент почтовый ящик без удаления сообщений. Однако когда удалено много сообщений, последовательность CLOSE-LOGOUT или CLOSE-SELECT значительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, так как здесь не посылается никаких немаркированных откликов EXPUNGE (которые клиент вероятно проигнорирует).

    Пример: C: A341 CLOSE
    S: A341 OK CLOSE completed

    5.4.3. Команда EXPUNGE

    Аргументы: отсутствуют.
    Отклики: немаркированные отклики: EXPUNGE.
    Результат: OK — команда успешно завершена;
    NO — команда не прошла: стирание не выполнено (например, запрещено);
    BAD — команда неизвестна или неверен аргумент.

    Команда EXPUNGE навечно удаляет из выбранного почтового ящика все сообщения, которые помечены флагами \Deleted. Прежде чем выдать клиенту сигнал OK, посылается немаркированный отклик EXPUNGE для каждого из удаляемых сообщений.

    Пример: C: A202 EXPUNGE
    S: * 3 EXPUNGE
    S: * 3 EXPUNGE
    S: * 5 EXPUNGE
    S: * 8 EXPUNGE
    S: A2 02 OK EXPUNGE completed

    Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются.

    Аргументы: опционны, [CHARSET]-спецификация.
    Критерии поиска (один или более).
    Отклики: необходим немаркированный отклик: SEARCH.
    Результат: OK — поиск завершен;
    NO — ошибка: поиск для данного набора символов или критериев не возможен;
    BAD — команда неизвестна или неверен аргумент

    Команда SEARCH ищет почтовый ящик, который отвечает выбранным критериям отбора. Критерий отбора состоит из одного или более ключей поиска. Немаркированный отклик SEARCH от сервера содержит список номеров сообщений, которые соответствуют критериям отбора.

    Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающим заданным критериям. Например, критерий DELETED FROM «SMITH» SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994. (например, для объединения этих ключей с помощью функций OR и NOT).

    Опционная спецификация [CHARSET] состоит из слова «CHARSET», за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках, должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII. US-ASCII должно поддерживаться всегда, но могут использоваться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD).

    Для всех ключей поиска, которые используют строки, сообщение соответствует ключу, если строка является частью строки поля в сообщении. Соответствие не должно зависеть от использования строчных или прописных символов. Стандартными ключами поиска являются следующие слова и выражения.

    Сообщения с номерами, соответствующими специфицированному набору номеров
    ALL Все сообщения в почтовом ящике. Ключ отбора по умолчанию для применения команд AND
    ANSWERED Сообщения с установленным флагом \Answered.
    BCC Сообщения, которые содержат специфицированную строку в поле BCC структуры заголовка сообщения.
    BEFORE Сообщения, чьи внутренние даты раньше указанной.
    BODY Сообщения, которые содержат специфицированную строку в теле сообщения.
    CC Сообщения, которые содержат специфицированную строку в CC поле заголовка.
    DELETED Сообщения с установленным флагом \Deleted.
    DRAFT Сообщения с установленным флагом \Draft.
    FLAGGED Сообщения c установленным флагом \Flagged.
    FROM Сообщения, которые содержат специфицированную строку в поле FROM заголовка.
    HEADER Сообщения, которые содержат заголовок со специфицированным именем поля (в соответствии с [RFC-822]) и специфицированную строку в теле данного поля.
    KEYWORD Сообщения со специфицированным ключевыми словами.
    LARGER Сообщения с размером [RFC-822] больше чем специфицированное число октетов.
    NEW Сообщения, которые имеют установленный флаг \Recent, но не имеют флага \Seen. Это функционально эквивалентно «(RECENT UNSEEN)».
    NOT Сообщения, которые не содержат специфицированного ключевого слова.
    OLD Сообщения, которые не имеют флага \Recent. «NOT RECENT» (противоположно «NOT NEW»).
    ON Сообщения, чья внутренняя дата соответствует специфицированному значению даты.
    OR Сообщения, которые соответствуют любому из ключевых слов поиска.
    RECENT Сообщения, которые имеют установленный флаг \Recent.
    SEEN Сообщения, которые имеют установленный флаг \Seen.
    SENTBEFORE Сообщения, чье содержимое заголовка, соответствует дате ранее специфицированного значения [RFC-822].
    SENTON Сообщения, чье содержимое заголовка, соответствует специфицированной дате [RFC-822]
    SENTSINCE Сообщения, чье содержимое заголовка, соответствует [RFC-822]: специфицированному значению даты или позже.
    SINCE Сообщения, чья внутренняя дата соответствует или позже специфицированного значения.
    SMALLER Сообщения с размером [RFC-822] меньше чем специфицированное число октетов.
    SUBJECT Сообщения, которое содержит специфицированную строку в поле SUBJECT заголовка.
    TEXT Сообщения, которые содержат специфицированную строку в заголовке или теле сообщения
    TO Сообщения, которые содержат специфицированную строку в поле заголовка TO.
    UID Сообщения с уникальными идентификаторами, соответствующими заданному значению идентификатора.
    UNANSWERED <>Сообщения, которые не имеют флага \Answered.
    UNDELETED Сообщения, которые не имеют флага \Deleted.
    UNDRAFT Сообщения, которые не имеют флага \Draft.
    UNFLAGGED Сообщения, которые не имеют флага \Flagged.
    UNKEYWORD Сообщения, которые не содержат заданных ключевых слов.
    UNSEEN Сообщения, которые не имеют флага \Seen.

    Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM «Smith»
    S: * SEARCH 2 84 882
    S: A282 OK SEARCH completed

    5.4.5. Команда FETCH

    Аргументы: набор сообщений,
    имена информационных сообщений.
    Отклики: немаркированные отклики: FETCH
    Результат: OK — операция успешно завершена;
    NO — команда не прошла: не удалось доставить эти данные;
    BAD — команда неизвестна или неверен аргумент.

    Команда FETCH извлекает данные, соответствующие сообщению в почтовом ящике. В качестве доставляемых данных может выступать отдельный атом или список элементов, помещенных в скобки. В настоящее время определены следующие типы данных, которые могут быть доставлены:

    ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
    BODY Нерасширяемая форма BODYSTRUCTURE.
    BODY[ ]

    Текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен:

    HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT. Пустая спецификация относится ко всему сообщению, включая заголовок.

    Каждое сообщение имеет номер, по крайней мере, одной части.

    Сообщения не-[MIME-IMB] и несоставные сообщения [MIME-IMB] без инкапсуляции имеют только часть 1.

    Частям составных сообщений присваиваются последовательные номера в порядке появления. Если конкретная часть является составным сообщением, то его части должны быть выделены точкой, за которой следует номер части.

    Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT] MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка. Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях, вставляется разграничивающая пустая строка между заголовком и телом сообщения.

    Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей:

    HEADER ([RFC-822] заголовок сообщения)
    TEXT MULTIPART/MIXED
    1 TEXT/PLAIN
    2 APPLICATION/OCTET-STREAM
    3 MESSAGE/RFC822
    3.HEADER ([RFC-822] заголовок сообщения)
    3.TEXT ([RFC-822] текстовое тело сообщения)
    3.1 TEXT/PLAIN
    3.2 APPLICATION/OCTET-STREAM
    4 MULTIPART/MIXED
    4.1 IMAGE/GIF
    4.1.MIME ([MIME-IMB] заголовок для IMAGE/GIF)
    4.2 MESSAGE/RFC822
    4.2.HEADER ([RFC-822] заголовок сообщения)
    4.2.TEXT ([RFC-822] текстовое тело сообщения)
    4.2.1 TEXT/PLAIN
    4.2.2 MULTIPART/AL TERNATIVE
    4.2.2.1 TEXT/PLAIN
    4.2.2.2 TEXT/RICHTEXT

    Имеется возможность доставить субстроку определенного текста. Это делается путем присоединения к спецификатору части открытой угловой скобки (» сообщения длиной 1500 октетов пришлет BODY[] с литералом размера 1500, а не BODY[].

    BODY.PEEK[ ] Альтернативная форма BODY[ ], которая не устанавливает флаг \Seen.
    BODYSTRUCTURE Структура тела сообщения [MIME-IMB]. Она вычисляется сервером путем разбора полей заголовка [MIME-IMB] [RFC-822] и заголовков [MIME-IMB].
    ENVELOPE Структура заголовка сообщения. Она вычисляется сервером в результате разбора заголовка [RFC-822] на части, присваивая им значения по умолчания, если это необходимо.
    FAST Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE)
    FLAGS Флаги, присвоенные сообщению.
    FULL Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
    INTERNALDATE Внутренняя дата сообщения.
    RFC822 Функционально эквивалентно BODY[], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822).
    RFC822.HEADER Функционально эквивалентно BODY.PEEK[HEADER], отличается по синтаксису результирующих немаркированных данных FETCH (возвращает данные в формате RFC822.HEADER).
    RFC822.SIZE Размер сообщения [RFC-822].
    RFC822.TEXT Функционально эквивалентно BODY[TEXT], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822.TEXT).
    UID Уникальный идентификатор сообщения.

    Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
    S: * 2 FETCH .
    S: * 3 FETCH .
    S: * 4 FETCH .
    S: A654 OK FETCH completed

    5.4.6. Команда STORE

    Аргументы: набор сообщений,
    имя элемента сообщения,
    значение элемента сообщения.
    Отклики: немаркированные отклики: FETCH.
    Результат: OK — операция успешно завершена;
    NO — команда не прошла: данные не могут быть запомнены;
    BAD — команда неизвестна или неверен аргумент.

    Команда STORE заносит данные в почтовый ящик. В норме команда STORE возвращает обновленную версию данных с немаркированным откликом FETCH. «.SILENT» в имени элемента данных блокирует немаркированный отклик FETCH, и сервер должен предполагать, что клиент определил обновленное значение сам или ему обновленное значение не нужно.

    Замечание: вне зависимости от того используется или нет суффикс «.SILENT», сервер должен послать немаркированный отклик FETCH, если внешние причины вызвали изменение флагов сообщения.

    В настоящее время определены следующие элементы данных:

    FLAGS Заменить флаги для сообщения, приведенного в аргументе. Новое значение флагов присылается, как если бы выполнялась команда FETCH для этих флагов.
    FLAGS.SILENT Эквивалентно FLAGS, но без возвращения нового значения.
    +FLAGS Добавить аргумент к флагам сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.
    +FLAGS.SILENT Эквивалентно +FLAGS, но без возвращения нового значения.
    -FLAGS Удаляет аргумент из флагов сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.
    -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

    5.4.7. Команда COPY

    Аргументы: набор сообщений,
    имя почтового ящика.
    Отклики: команда не требует какого-либо специального отклика.

    Результат: OK команда успешно завершена;
    NO команда не прошла: не могут быть скопированы эти сообщения вообще или в данный почтовый ящик;
    BAD команда неизвестна или неверен аргумент.

    Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика. Флаги и внутренняя дата сообщения должны быть сохранены в копии.

    Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика «[TRYCREATE]» в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.

    Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик назначения в состояние, которое он имел до выполнения COPY.

    Пример: C: A003 COPY 2:4 MEETING
    S: A003 OK COPY completed

    5.4.8. Команда U >Аргументы: имя команды,
    аргументы команды.
    Отклики: немаркированные отклики: FETCH, SEARCH.
    Результат: OK — команда UID завершена;
    NO — команда UID не прошла;
    BAD — команда неизвестна или неверен аргумент.

    Команда UID имеет две формы. В первой форме она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений.

    Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению порядкового номера сообщения 1:100 и UID 443:557.

    Допускаются диапазоны номеров сообщений, однако, нет гарантии, что уникальные идентификаторы образуют монотонную последовательность без пропусков. Не существующие уникальные идентификаторы в списке сообщений игнорируются без генерации сообщения об ошибке.

    Число после «*» в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID. Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH.

    Пример: C: A999 UID FETCH 4827313:4828442 FLAGS
    S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
    S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
    S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
    S: A999 UID FETCH completed

    5.5. Команды клиента — экспериментальные и расширения
    5.5.1. Команда X

    Аргументы: определяется приложением.
    Отклики: определяется приложением.
    Результат: OK — команда выполнена;
    NO — отказ;
    BAD — команда неизвестна или неверен аргумент.

    Любая команда с префиксом X является экспериментальной командой. Команды, которые не являются частью этой спецификации стандарта, модификации стандарта или одобренного IESG экспериментального протокола, должны использовать префикс X.

    Любой добавленный немаркированный отклик, посланный экспериментальной командой также должен иметь префикс X. Реализации сервера не должны посылать такие немаркированные отклики, если только клиент не запрашивает их посредством какой-либо экспериментальной команды.

    Пример: C: a441 CAPABILITY
    S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
    S: a441 OK CAPABILI TY completed
    C: A442 XPIG-LATIN
    S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
    S: A442 OK XPIG-LATIN completed-cay

    6. Отклики сервера

    Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом «Содержимое:».

    Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде.

    Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом «*» вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также «незапрашиваемыми данными».

    Определенные данные от сервера должны записываться клиентом при получении. Такие данные несут критическую информацию, которая влияет на интерпретацию всех последующих команд и откликов (например, создание или уничтожение сообщений).

    Прочие данные сервера следует записывать для последующих ссылок, если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться.

    Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии «выбрано». В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.

    Отклики запросов продолжения команды используют символ «+» вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.

    6.1. Отклики сервера — отклики состояния

    Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE — всегда не маркированы.

    Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:

    ALERT Текстовое сообщение, содержащее специальное предупреждение, которое должно быть представлено пользователю в форме, привлекающей внимание.
    NEWNAME За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика.
    PARSE Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике.
    PERMANENTFLAGS Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике.
    READ-ONLY Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only.
    READ-WRITE Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write.
    TRYCREATE Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE
    UIDVALIDITY Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора.
    UNSEEN Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen.

    Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс «X», если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются.

    6.1.1. Отклик OK

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.

    Немаркированная форма используется также как один из трех видов оповещения об установлении начального соединения. Эта форма указывает, что еще не выполнена аутентификация и необходима команда LOGIN.

    Пример: S: * OK IMAP4rev1 server ready
    C: A001 LOGIN fred blurdybloop
    S: * OK [ALERT] System shutdown in 10 minutes
    S: A001 OK LOGIN Completed

    6.1.2. Отклик NO

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.

    Пример: C: A222 COPY 1:2 owatag usiam
    S: * NO Disk is 98% full, please delete unnecessary data
    S: A222 OK COPY completed
    C: A223 COPY 3:200 blurdybloop
    S: * NO Disk is 98% full, please delete unnecessary data
    S: * NO Disk is 99% full, please delete unnecessary data
    S: A223 NO COPY failed: disk is full

    6.1.3. Отклик BAD

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка отмечает команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера. Текстовое сообщение описывает условия.

    Пример: C: . very long command line.
    S: * BAD Command line too long
    C: . empty line.
    S: * BAD Empty command line
    C: A443 EXPUNGE
    S: * BAD Disk crash, attempting salvage to a new disk!
    S: * OK Salvage successful, no data lost
    S: A443 OK Expunge completed

    6.1.4. Отклик PREAUTH

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация, и команда LOGIN не нужна.

    Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith

    6.1.5. Отклик BYE

    Содержимое: опционный код отклика;
    текст, читаемый человеком

    Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:

    1. Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT.
    2. Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение.
    3. Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение.
    4. Как одно из трех возможных сообщений при установлении соединения, уведомляя, что сервер не может установить соединение с данным клиентом. Сервер немедленно разрывает соединение.

    Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.

    Пример: S: * BYE Autologout; idle for too long

    6.2. Отклики сервера — сообщения о состоянии сервера и почтового ящика

    Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя.

    6.2.1. Отклик CAPABILITY

    Содержимое: список возможностей.

    Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом «IMAP 4.1».

    Имя возможности, которое начинается с «AUTH=» указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.

    Имена возможностей должны либо начинаться с «X», либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа «X».

    Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от «IMAP 4.1», они должны игнорировать неизвестные имена возможностей.

    Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN

    6.2.2. Отклик LIST

    Содержимое: атрибуты имени, иерархический разделитель, имя.

    Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.

    Определено четыре атрибута имени:

    \Noinferiors Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем.
    \Noselect Не допускается использование данного имени для именования почтового ящика, который может быть выбран.
    \Marked Почтовый ящик помечен сервером как «interesting»; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран.
    \Unmarked Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран.

    Если сервер не может определить, является ли почтовый ящик «интересным», или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.

    Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.

    Пример: S: * LIST (\ Noselect) «/»

    6.2.3. Отклик LSUB

    Содержимое: атрибуты имени, иерархический разграничитель, имя.

    Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.

    Пример: S: * LSUB () «.» #news.comp.mail.misc

    6.2.4. Отклик STATUS

    Содержимое: имя, статусный список, заключенный в скобки.

    Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.

    Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)

    Содержимое: нуль или более чисел.

    Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH — их уникальные идентификаторы. Числа отделяются друг от друга пробелами.

    Пример: S: * SEARCH 2 3 6

    6.2.6. Отклик FLAGS

    Содержимое: список флагов, заключенный в скобки.

    Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.

    Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

    6.3. Отклики сервера — размер почтового ящика

    Эти отклики являются немаркированными. Они передают от сервера клиенту информацию об изменении размера почтового ящика. Число, которое следует за символом «*» определяет количество сообщений.

    6.3.1. Отклик EXISTS

    Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.

    Пример: S: * 23 EXISTS

    6.3.2. Отклик RECENT

    Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).

    Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением.

    Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.

    Пример: S: * 5 RECENT

    6.4. Отклики сервера — статусное сообщение

    Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом «*» следует число, которое является порядковым номером сообщения.

    6.4.1. Отклик EXPUNGE

    Отклик EXPUNGE уведомляет, сообщение с каким порядковым номером удалено из почтового ящика. Порядковые номера последующих сообщений немедленно уменьшаются на единицу.

    Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи «снизу-вверх» пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи «сверху вниз», пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.

    Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера.

    Информация отклика EXPUNGE должна регистрироваться клиентом.

    Пример: S: * 44 EXPUNGE

    6.4.2. Отклик FETCH

    Содержимое: текст сообщения.

    Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы:

    BODY Форма BODYSTRUCTURE без расширения данных.
    BODY[ ] >

    Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела.

    Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[ ] может быть укорочено, но BODY[ ] никогда не укорачивается.

    Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.

    Не текстовые данные, такие как двоичные, должны передаваться закодированными в текстуальной форме, например BASE64. Чтобы получить исходные двоичные данные клиент должен декодировать полученную последовательность.

    BODYSTRUCTURE — список, заключенный в скобки, который описывает [MIME-IMB],
    структура тела сообщения.

    Эта структура вычисляется сервером путем разбора полей заголовка [MIME-IMB], и подставления при необходимости значений по умолчанию.

    Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: («TEXT» «PLAIN» («CHARSET» «US-ASCII») NIL NIL «7BIT» 2279 48)

    Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой. Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).

    Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: ((«TEXT» «PLAIN» («CHARSET» «US-ASCII») NIL NIL «7BIT» 1152 23)(«TEXT» «PLAIN» («CHARSET» «US-ASCII» «NAME» «cc.diff») » » «Compiler diff» «BASE64» 4554 73) «MIXED»))

    Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат:

    Список параметров тела, заключенный в скобки.

    Список содержит пары атрибут/значение [например, («foo» «bar» «baz» «rag»), где «bar» представляет собой значение «foo», а «rag» является значением «baz»] как это определено в [MIME-IMB].

    Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.

    Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS].

    Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке:

    Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].

    Строка, описывающая имя субтипа, как это определено в [MIME-IMB].

    Список параметров тела, заключенный в скобки

    Список пар атрибут/значение, заключенный в скобки, [например, («foo» «bar» «baz» «rag»), где «bar» является значением «foo», а «rag» — значением «baz»], как это описано в [MIME-IMB].

    Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].

    Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].

    Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].

    Число, указывающее размер тела в октетах. Заметьте, что этот размер характеризует размер тела с учетом транспортного кодирования. Размер исходного текста может быть иным.

    Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.

    Тип тела TEXT сразу после базовых полей содержат размер тела в строках. Заметьте, что этот размер отражает размер фрагмента после выполнения транспортного кодирования.

    Данные расширения следуют после базовых полей и полей, перечисленных выше и зависящих от типа. Данные расширения никогда не транспортируются при передаче тела, но могут быть пересланы при доставке BODYSTRUCTURE. Данные расширения, если они присутствуют, должны быть упорядочены.

    Данные расширения для несоставной части тела располагаются в следующем порядке:

    Строка, содержащая значение MD5 тела, как это описано в [MD5].

    Список, заключенный в скобки, с тем же содержимым и функциями, что и размещение тела для составной части тела.

    Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].

    Любые последующие данные расширения пока не определены в данной версии протокола.

    ENVELOPE — список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения. Он вычисляется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.

    Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.

    Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [SMTP] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.

    Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.

    Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from.

    FLAGS Список флагов, установленных для данного сообщения, заключенный в скобки.
    INTERNALDATE Строка, представляющая внутреннюю дату сообщения.
    RFC822 Эквивалент BODY[].
    RFC822.HEADER Эквивалент BODY.PEEK[HEADER].
    RFC822.SIZE Число, выражающее размер сообщения [RFC-822].
    RFC822.TEXT Эквивалент BODY[TEXT].
    UID Число, выражающее уникальный идентификатор сообщения.

    Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

    6.5 Отклики сервера — запрос продолжения команды

    Отклик на запрос продолжения команды вместо метки выделяется символом «+». Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.

    Этот отклик используется командой AUTHORIZATION, для того чтобы передать данные от сервера клиенту, и запросить дополнительные данные у клиента. Этот отклик применяется также, если аргументом какой-то команды является литерал.

    Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.

    Пример: C: A001 LOGIN <11>
    S: + Ready for additional command text
    C: FRED FOOBAR <7>
    S: + Ready for additional command text
    C: fat man
    S: A001 OK LOGIN completed
    C: A044 BLURDYBLOOP <102856>
    S: A044 BAD No such command as «BLURDYBLOOP»

    7. Пример соединения IMAP 4.1

    Последующее является записью для соединения IMAP 4.1. (Данный пример и нижеприведенное описание синтаксиса практически без изменения взято из документа RFC-2060).

    S: * OK IMAP4rev1 Service Ready
    C: a001 login mrc secret
    S: a001 OK LOGIN completed
    C: a002 select inbox
    S: * 18 EXISTS
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
    S: * 2 RECENT
    S: * OK [UNSEEN 17] Message 17 is the first unseen message
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: a002 OK [READ-WRITE] SELECT completed
    C: a003 fetch 12 full
    S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE «17-Jul-1996 02:44:25 -0700»
    RFC822.SIZE 4286 ENVELOPE («Wed, 17 Jul 1996 02:23:25 -0700 (PDT)»
    «IMAP4rev1 WG mtg summary and minutes»
    ((«Terry Gray» NIL «gray» «cac.washington.edu»))
    ((«Terry Gray» NIL «gray» «cac.washington.edu»))
    ((«Terry Gray» NIL «gray» «cac.washington.edu»))
    ((NIL NIL «imap» «cac.washington.edu»))
    ((NIL NIL «minutes» «CNRI.Reston.VA.US»)
    («John Klensin» NIL «KLENSIN» «INFOODS.MIT.EDU»)) NIL NIL
    » «)
    BODY («TEXT» «PLAIN» («CHARSET» «US-ASCII») NIL NIL «7BIT» 3028 92))
    S: a003 OK FETCH completed
    C: a004 fetch 12 body[header]
    S: * 12 FETCH (BODY[HEADER] <350>
    S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
    S: From: Terry Gray gray@cac.washington.edu
    S: Subject: IMAP4rev1 WG mtg summary and minutes
    S: To: imap@cac.washington.edu
    S: cc: minutes@CNRI.Reston.VA.US, John Klensin KLENSIN@INFOODS.MIT.EDU
    S: Message-Id: B27397-0100000@cac.washington.edu
    S: MIME-Version: 1.0
    S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    S:
    S: )
    S: a004 OK FETCH completed
    C: a005 store 12 +flags \deleted
    S: * 12 FETCH (FLAGS (\Seen \Deleted))
    S: a005 OK +FLAGS completed
    C: a006 logout
    S: * BYE IMAP4rev1 server terminating connection
    S: a006 OK LOGOUT completed

    8. Формальный синтаксис

    Последующая синтаксическая спецификация использует нотацию Бакуса-Наура (BNF — Backus-Naur Form), как это описано в [RFC-822] с одним исключением, разделителем, используемым в конструкции «#», служит одиночный пробел (SPACE), а не одна или более запятых.

    В случае альтернативных или опционных правил, в которых последующее правило перекрывается с более ранним, более приоритетным считается правило, встретившееся первым. Некоторые, но не все случаи таких правил представлены ниже. Если не указано обратного, все буквенные символы не зависят от использования строчных или прописных букв. Конкретные программные реализации должны воспринимать такие строки при любом написании.

    ;; Будущее расширение. Реализации клиента должны воспринимать
    ;; флаги flag_extension. Реализации сервера не должны генерировать
    ;; флаги flag_extension, за исключением случаев, определенных в
    ;; будущих стандартах или зарегистрированных модификациях
    ;; данной спецификации.

    ;; Символьный набор [CHARSET] должен быть зарегистрирован IANA

    search_key ::= «ALL» / «ANSWERED» / «BCC» SPACE astring /
    «BEFORE» SPACE date / «BODY» SPACE astring /
    «CC» SPACE astring / «DELETED» / «FLAGGED» /
    «FROM» SPACE astring /
    «KEYWORD» SPACE flag_keyword / «NEW» / «OLD» /
    «ON» SPACE date / «RECENT» / «SEEN» /
    «SINCE» SPACE date / «SUBJECT» SPACE astring /
    «TEXT» SPACE astring / «TO» SPACE astring /
    «UNANSWERED» / «UNDELETED» / «UNFLAGGED» /
    «UNKEYWORD» SPACE flag_keyword / «UNSEEN» /

    ;; Выше этой строки все в [IMAP2]

    «DRAFT» /
    «HEADER» SPACE header_fld_name SPACE astring /
    «LARGER» SPACE number / «NOT» SPACE search_key /
    «OR» SPACE search_key SPACE search_key /
    «SENTBEFORE» SPACE date / «SENTON» SPACE date /
    «SENTSINCE» SPACE date / «SMALLER» SPACE number /
    «UID» SPACE set / «UNDRAFT» / set /
    «(» 1#search_key «)»
    section ::= «[» [section_text / (nz_number *[«.» nz_number]
    [«.» (section_text / «MIME»)])] «]»
    section_text ::= «HEADER» / «HEADER.FIELDS» [«.NOT»]
    SPACE header_list / «TEXT»
    select ::= «SELECT» SPACE mailbox
    sequence_num ::= nz_number / «*»

    ;; * является наибольшим используемым числом. Для порядковых номеров
    ;; сообщений оно равно количеству сообщений в почтовом ящике.
    ;; Для уникальных идентификаторов оно равно уникальному
    ;; идентификатору последнего сообщения в почтовом ящике./p>

    set ::= sequence_num / (sequence_num «:» sequence_num) /
    (set «,» set)

    ;; Идентифицирует набор сообщений. Для порядковых номеров
    ;; сообщений это последовательность чисел с 1 до числа
    ;; сообщений в почтовом ящике.
    ;; Запятая разграничивает индивидуальные номера, двоеточие
    ;; указывает на диапазон чисел включительно.
    ;; Пример для почтового ящика с 15 сообщениями: 2,4:7,9,12:*
    ;; эквивалентно 2,4,5,6,7,9,12,13,14,15.

    ;; Уникальные идентификаторы используются вместо
    ;; последовательных номеров сообщения.

    ;; В возрастающем порядке
    unsubscribe ::= «UNSUBSCRIBE» SPACE mailbox
    user > x_command ::= «X» atom
    zone ::= («+» / «-«) 4digit

    ;; Число из 4 цифр со знаком hhmm, представляющее часы и минуты к западу от Гринвича
    ;; (Это число отличается от Universal Time). Вычитая временную зону из данного времени, можно получить
    ;; форму UT. Зона Universal Time равна «+0000».

    9. Соображения безопасности

    Протокольные операции IMAP 4.1, включая данные электронной почты, передаются через сеть открытым текстом, если только не согласовано применение конфиденциальных методов обмена посредством команды AUTHENTICATE.

    Сообщения об ошибках сервера для команды AUTHENTICATE, которая не прошла из-за неверных параметров аутентификации, не должна уточнять какой из параметров содержит ошибку.

    Использование команды LOGIN осуществляет передачу паролей открытым текстом. Этого можно избежать, используя для этого команду AUTHENTICATE.

    АйТи бубен

    Инструменты пользователя

    Инструменты сайта

    Содержание

    Команды IMAP

    Протокол IMAP (Internet Mail Access Protocol) описывается в RFC 2060.

    В отличии от POP3, который просто скачивает входящие письма и сохраняет их локально, с IMAP вы работаете с почтой непосредственно на сервере

    Как и POP3, протокол IMAP использует концепцию клиент-сервер с набором команд. С помощью команд осуществляется передача сообщений электронной почты от сервера клиенту. Клиент устанавливает для этой цели TCP-соединение с портом 143 на сервере. Далее сервер должен ответить специальным сообщением-приглашением.

    В строке 1 показана команда на открытие сеанса с помощью telnet с портом 143 (порт IMAP по умолчанию). Строка 5 отображает приглашение, выданное сервером IMAP. В строке 6 клиентом задана команда закончить сеанс с сервером. Затем сервер посылает сообщение об окончании сеанса (строка 7) и закрывает соединение с клиентом.

    Каждая команда, выдаваемая клиентом, предваряется уникальным идентификатором. Сервер может затем использовать этот идентификатор в своих ответах, что позволяет клиенту определить, к какой команде относится ответ сервера. Это особенно важно при выполнении сервером нескольких команд за сеанс. Идентификатор обычно представляет собой короткую строку алфавитно-цифровых символов, которая генерируется клиентом. Так, в строке 6 листинга 7.1 клиентом был выбран идентификатор a001. Если бы клиенту потребовалось задавать и другие команды, то следующим идентификатором был бы a002 и т.д. Часто для упрощения идентификаторы команд в течение сеанса IMAP просто последовательно увеличивают один из своих разрядов.

    После установления соединения клиент находится в состоянии ожидания проверки подлинности, так как для выполнения каких-либо операций со своим почтовым ящиком на сервере он должен идентифицировать себя. После идентификации на сервере клиент может использовать команды IMAP для управления сообщениями на сервере. Протоколом IMAP предусмотрена возможность поддержки пользователем нескольких почтовых ящиков на одном сервере. При этом клиент может читать, отправлять и удалять сообщения в любом из принадлежащих ему почтовых ящиков.

    Методы проверки подлинности пользователя в IMAP

    Так же как и в протоколе POP3, в IMAP имеется несколько методов проверки подлинности клиента. Некоторые из них обеспечивают больший уровень безопасности, по сравнению с другими. В отличие от клиентов POP3, клиенты IMAP часто проводят довольно длительные сеансы с сервером при обработке сообщений. Таким образом, идентификатор пользователя и пароль не передаются по сети несколько раз в час, как это обычно происходит при работе по протоколу POP3.

    Команда LOGIN

    Команда LOGIN позволяет клиенту при регистрации на сервере IMAP использовать идентификатор пользователя и пароль в обычном текстовом виде.

    Команда AUTHENTICATE

    С помощью команды AUTHENTICATE клиент может использовать при регистрации на сервере IMAP альтернативные методы проверки подлинности. Индивидуальная проверка подлинности пользователей не является обязательной и поддерживается не всеми серверами IMAP. К тому же реализации такой проверки могут различаться в зависимости от сервера. Когда клиент выдает команду AUTHENTICATE, сервер отвечает на нее строкой вызова в кодировке base64. Далее в обязанности клиента входит ответ на вызов сервера о проверке подлинности, также закодированный base64. Если на сервере не поддерживается метод проверки подлинности, предложенный клиентом, он включает в свой ответ отрицательное слово NO. После этого клиент должен продолжить переговоры по согласованию метода проверки подлинности. Если все попытки определить метод проверки подлинности потерпели неудачу, то клиент предпринимает попытку зарегистрироваться на сервере посредством команды LOGIN. Пример сеанса с применением AUTHENTICATE:

    В строках 6–9 показаны попытки клиента согласовать с сервером IMAP метод проверки подлинности. Как видите, все они не увенчались успехом. А в строке 10 показано, что метод проверки, приемлемый и для клиента, и для сервера, найден. Отвечая, сервер в строке 11 выдает кодированную строку с вызовом в кодировке base64. Однако в строке 12 клиент отвергает попытку регистрации и возобновляет ее лишь в строке 14 с помощью команды LOGIN.

    Клиентская часть протокола IMAP

    После регистрации на сервере IMAP клиент может приступить к манипулированию сообщениями. Протокол IMAP предлагает довольном много команд для чтения, перемещения и удаления почтовых сообщений в почтовых ящиках на сервере. Помните, что протокол IMAP предполагает хранение всех сообщений на сервере. Загрузка почтовых сообщений на локальный компьютер производится лишь для отображения. При этом они не перемещаются и не копируются на локальный ПК клиента.

    Почтовый ящик для клиента по умолчанию носит название INBOX. Все новые сообщения ложатся именно в INBOX. Клиент имеет возможность создавать новые почтовые ящики (иногда называемые в программах-клиентах для работы с электронной почтой папками). Туда с целью упорядочения он может перемещать сообщения из папки INBOX.

    Каждому сообщению назначается уникальный идентификатор (UID), по которому они идентифицируются в почтовом ящике. Метка UID сохраняется в течение всех сеансов IMAP для того, чтобы клиентское программное обеспечение могло правильно идентифицировать сообщения в почтовом ящике. Каждому почтовому ящику соответствует уникальный идентификатор достоверности (UIDVALIDITY). Метка UIDVALIDITY должна присутствовать во время всех сеансов IMAP, только в том случае, если идентификаторы сообщений в ящике оставались неизменными. Если в почтовом ящике имеются сообщения с различными идентификаторами, то значение UIDVALIDITY при следующем сеансе должно увеличиться. Это позволяет клиентам быстро определять, появились ли в почтовом ящике новые сообщения с момента последнего к нему обращения.

    Каждое сообщение снабжается флагом, который отображает его статус. Флаг может быть постоянным или задаваться на время сеанса. Постоянные флаги могут изменяться клиентом и сохраняться вне зависимости от сеансов. Флаги, назначаемые на время сеанса, действительны только на время текущего сеанса IMAP. В табл. 7.1 представлены варианты флагов почтовых сообщений.

    Флаги почтового сообщения IMAP

    Почтовому сообщению может соответствовать 0 флагов или несколько флагов. Информация о флагах передается клиенту вместе с самим сообщением. В обязанности клиента входит интерпретация флагов соответствующим образом.

    В следующем разделе описываются команды IMAP, которые клиент может задавать серверу.

    Сервер должен отвечать соответствующим образом на заданные команды или отвечать отрицательно, если команда задана неправильно либо не поддерживается.

    Команда SELECT

    Команда SELECT используется, лишь когда почтовый ящик активен. По умолчанию, пока клиент не зарегистрирован в системе, ни один из принадлежащих ему почтовых ящиков не является выбранным. Далее клиент должен выбрать почтовый ящик, с которым он собирается работать. Обычно первый ящик, который выбирается клиентом, — это ящик INBOX, куда помещаются новые сообщения. Формат команды SELECT следующий:

    Здесь mailbox — это название почтового ящика, к которому обращается клиент. Во время одного сеанса IMAP может быть активен только один почтовый ящик. Если ящик существует и у клиента имеется соответствующий доступ к нему, то сервер дает многострочный ответ, где описывается состояние почтового ящика.

    Команда CREATE

    Команда CREATE используется для создания нового почтового ящика на сервере IMAP. Имя и местоположение новых почтовых ящиков определяются в соответствии с общими спецификациями ОС Linux. В рабочем каталоге пользователя создается новый почтовый ящик с именем, но без задания местоположения, так как оно известно каталогу $HOME клиента. Например, если рабочий каталог клиента находится в /home/riley и клиент задает команду CREATE для создания нового почтового ящика stuff/junk, то вновь созданный ящик на почтовом сервере под управлением ОС Linux будет иметь путь /home/riley/stuff/junk. В этом примере вы видите, как используется знак разделителя /. Однако это не является общим для всех серверов IMAP.

    Команда DELETE

    Команда DELETE применяется к почтовым ящикам, а не к сообщениям. Сервер IMAP при получении этой команды попытается удалить почтовый ящик с именем, указанным в качестве аргумента команды. В аргументе команды можно использовать стандартное описание путей ОС Linux, со знаком разделителя /, если только они не находятся в каталоге $HOME. Сообщения из удаленных почтовых ящиков восстановлению не подлежат и теряются вместе с ящиками.

    Команда RENAME

    С помощью команды RENAME клиент может изменить имя почтового ящика. При этом возможно применение двух параметров. Первый параметр — собственно имя почтового ящика, который требуется переименовать. И второй параметр — новое имя почтового ящика.

    Команда LIST

    Команда LIST используется для получения списка всех почтовых ящиков клиента. С ней используются два параметра. Формат команды LIST приведен ниже:

    Здесь reference — каталог, где находятся почтовые ящики. Если задается пустая строка вместо этого параметра («»), то почтовые ящики находятся в рабочем каталоге пользователя $HOME. Второй параметр mailbox является именем почтового ящика, который нужно просмотреть. Здесь допускается использование специальных символов, так же, как и при получении обычного списка каталогов, например группового символа (*). Если именем почтового ящика задана пустая строка («»), то сервер будет возвращать в качестве ответа иерархический разделитель (для Linux /) и имя корневого параметра.

    Команда LSUB

    Команда LSUB используется для устранения проблемы, которая описана для команды LIST. В отличие от команды LIST, с помощью которой отображается все содержимое рабочего каталога пользователя, с помощью команды LSUB отображаются лишь активизированные ранее описанной командой SUBSCRIBE почтовые ящики клиента. Параметры команды LSUB точно такие же, что и для команды LIST, т.е. ссылка (reference) и имя почтового ящика. Подобно команде LIST, параметр ссылки указывает путь к каталогу, в котором находятся почтовые ящики с соответствующими именами (каталог $HOME, если указано «»). Соответственно, под именем почтового ящика понимается имя ящика или имена ящиков, которые требуется вывести в списке (допускается групповой символ (*).

    Почтовые ящики могут затем добавляться в список активных ящиков с помощью команды SUBSCRIBE, а удаляться из списка с помощью команды UNSUBSCRIBE. С помощью этих команд можно реализовать на базе клиента IMAP чтение групп новостей. При этом каждая группа новостей реализована как отдельный почтовый ящик на сервере, на которую затем можно подписаться. Сегодня большинство программ для работы с электронной почтой включают функцию чтения групп новостей, так что выполнение этих операций в IMAP не требуется.

    Команда APPEND

    APPEND — еще одна команда из семейства команд IMAP. Как правило, протокол IMAP применяется исключительно для чтения сообщений из почтовых ящиков. С помощью команды APPEND появляется возможность посылать сообщения в почтовый ящик, добавляя сообщение к концу файла почтового ящика. Эта функция работает не совсем корректно и она является довольно опасной, поэтому не рекомендуем увлекаться ею в качестве альтернативы SMTP. Это, скорее, приятное излишество протокола IMAP, а не рабочая лошадка. Основной формат команды APPEND следующий:

    Команда CHECK

    Команда CHECK используется для установки контрольной точки в почтовом ящике. Любые операции, такие, например, как запись данных из памяти сервера на его жесткий диск, должны выполняться при соответствующем состоянии почтового ящика. Именно для проверки целостности почтового ящика после дисковых и других подобных им операций и применяется команда CHECK. Эта команда используется без параметров.

    Команда CLOSE

    Команда CLOSE полностью соответствует своему названию — она закрывает почтовый ящик.

    Действие команды CLOSE четко прослеживается на только что открытом новом почтовом ящике. Открытый почтовый ящик закрывается также с помощью команды LOGOUT. Команда CLOSE не имеет параметров.

    Команда EXPUNGE

    Ответ сервера на команду EXPUNGE представляет собой отчет о новом состоянии почтового ящика.

    В строке 8 пользователь alex выбирает почтовый ящик с именем newbox. Строки 9–16 представляют собой ответ сервера с информацией относительно выбранного почтового ящика. Строка 9 говорит о том, что в нем находится 6 сообщений. В строках 17 и 20 пользователь alex воспользовался командой STORE, чтобы пометить два сообщения как удаленные (\DELETED). Затем в строке 23 пользователь alex выдает команду STATUS. Из строки 24 можно сделать заключение, что, с точки зрения сервера IMAP, в почтовом ящике все еще находятся шесть сообщений, хотя два из них помечены как удаленные. В строке 26 пользователь выдает команду EXPUNGE, по которой сообщения, помеченные как удаленные, стираются. Ответ сервера в строках 27–31 подтверждает, что сообщения были удалены из ящика и в нем осталось четыре сообщения. Это же подтверждает и команда STATUS, заданная в строке 32. На нее сервер отвечает, что в почтовом ящике теперь только четыре сообщения.

    Команда SEARCH является одним из наиболее мощных средств из арсенала IMAP. С помощью этой команды производится поиск сообщений по критериям в активном почтовом ящике с последующим отображением результатов в виде номера сообщения. Формат команды SEARCH следующий:

    Здесь CHARSET specification состоит из служебного слова CHARSET, за которым следует обозначение набора символов. Набор символов по умолчанию — ASCII , так что, как правило, этот параметр опускается. Параметр search criteria определяет ключевые критерии поиска и их значения. Критерии поиска описаны в табл. 7.3.

    Таблица. Критерии поиска для команды SEARCH

    Как видно из таблицы существует огромное количество критериев поиска сообщений. Это очень удобно, когда требуется найти специфическое сообщение в почтовых ящиках, которые заполнены большим количеством сообщений. Ниже представлен короткий пример с использованием команды SEARCH.

    В строках 17, 20 и 23 показаны примеры использования команды SEARCH. Строки 18, 21 и 24 являются ответами сервера IMAP на команду SEARCH. В ответе содержатся номера сообщений, которые соответствуют критерию поиска. Если соответствий не найдено, то сервер возвращает слово SEARCH без идентификатора сообщения UID.

    Команда FETCH

    Команда FETCH используется для получения текста почтового сообщения. Она применяется только для отображения сообщений. В отличие от POP3, клиент IMAP не сохраняет копию сообщения на клиентском ПК.

    Команда STORE

    Команда STORE применяется для изменения информации о сообщении. Формат команды следующий:

    Аргумент задает диапазон номеров сообщений, к которым применяется команда STORE. В настоящее время для этой команды определено только два типа данных ( ). Тип FLAGS определяет набор флагов, установленных для сообщения. Тип FLAGS.SILENT также определяет набор флагов, установленных для сообщения, но при этом сервер IMAP не возвращает их новое значение в своем ответе.

    Поведением этих типов данных можно управлять, задав перед ними знак плюс (+) или минус (-). Знак плюс означает, что значение типа данных ( ) будет добавлено к сообщению, минус — что оно будет удалено из сообщения.

    В строке 18 этого листинга показано, как устанавливается флаг \DELETED для сообщения в активном почтовом ящике с номером 1. Обратите внимание, что перед флагом задан знак плюс (+). Можно было бы также задать флаг (-). Тогда флаг \DELETED был бы отменен для сообщения (один из способов восстановить удаленное сообщение до того, как вступят в силу контрольные точки сообщения).

    Команда COPY

    Команда COPY используется для копирования сообщений из одного почтового ящика в другой. Формат команды COPY приведен ниже:

    Здесь задает диапазон номеров сообщений, которые нужно скопировать из активного почтового ящика, а указывает имя ящика, в который их нужно скопировать.

    Для протокола IMAP не определена команда перемещения сообщений, но очевидно, что эта операция есть не что иное, как копирование сообщений в другой почтовый ящик с заданием для оригиналов сообщений флага \DELETED. После следующей ротации почтового ящика (расстановки контрольных точек) оригиналы сообщений будут удалены, и останутся только их копии.

    Команда CAPABILITY

    С помощью команды CAPABILITY клиент может запрашивать у сервера IMAP информацию о его возможностях.

    Команда NOOP

    Действия команды NOOP, как мы знаем, соответствует ее названию, т.е. она ничего не делает. Она может применяться для поддержки активности во время сеанса для того, чтобы сеанс не прекратился по таймеру интервала ожидания. Ответ сервера на команду NOOP всегда должен быть положительным. Так как сервер часто в ответе возвращает состояние выполнения той или иной команды, то NOOP вполне можно использовать как триггер для периодического запроса о состоянии сервера. Если что-то произошло с почтовым ящиком во время периода ожидания, например сервер удалил сообщения согласно правилам, установленным для почтового ящика администратором почтовой системы, то в ответ на команду NOOP будет возвращена обновленная информация о его состоянии.

    Команда LOGOUT

    Команда LOGOUT используется для завершения сеанса для текущего идентификатора пользователя и закрытия всех открытых почтовых ящиков. Если какие-либо сообщения были помечены флагом \DELETED, то с помощью этой команды они будут физически удалены из почтового ящика.

    Протоколы электронной почты: POP3, IMAP4, SMTP

    В этой статье рассмотрены наиболее часто используемые протоколы электронной почты в Интернете — POP3, IMAP и SMTP. Каждый из них имеет определенную функцию и способ работы. В содержании статьи разъясняется, какая конфигурация лучше всего подходит для конкретных потребностей пользователя при использовании e-mail-клиента. А также раскрывается ответ на вопрос о том, какой протокол поддерживает электронную почту e-mail.

    Что такое POP3?

    Протокол почтового отделения третьей версии (POP3) — это стандартный почтовый протокол, используемый для приема электронной почты с удаленного сервера на локальный почтовый клиент. Позволяет загружать сообщения на ваш локальный компьютер и читать их, даже если пользователь находится в автономном режиме. Обратите внимание, что при использовании протокола POP3 для подключения к вашей учетной записи сообщения загружаются локально и удаляются с сервера электронной почты.

    По умолчанию протокол POP3 работает на двух портах:

    порт 110 — это незашифрованный порт POP3;

    порт 995 — его нужно использовать, если вы хотите безопасно подключиться к POP3.

    Что такое IMAP?

    Протокол доступа к интернет-сообщениям (IMAP) — это протокол получения сообщений электронной почты, используемый для доступа к ней на удаленном веб-сервере от локального клиента. IMAP и POP3 являются двумя наиболее часто используемыми протоколами для получения писем и поддерживаются всеми современными почтовыми клиентами и веб-серверами.

    Протокол POP3 предполагает, что ваш адрес электронной почты доступен только из одного приложения, а IMAP позволяет совершить одновременный вход сразу с нескольких клиентов. Вот почему IMAP подойдет лучше, если вы собираетесь получать доступ к своей электронной почте из разных мест или если ваши сообщения управляются несколькими пользователями.

    Протокол IMAP работает на двух портах:

    порт 143 — это незашифрованный порт IMAP по умолчанию;

    порт 993 — его необходимо использовать, если вы хотите безопасно подключиться с помощью IMAP.

    Что такое SMTP?

    Протокол Simple Mail Transfer Protocol (SMTP) — это стандартный протокол для отправки электронной почты через Интернет.

    SMTP работает в трех портах:

    порт 25 — это незашифрованный порт SMTP по умолчанию;

    порт 2525 — он открывается на всех серверах SiteGround, если порт 25 фильтруется (например, вашим интернет-провайдером), и вы хотите отправлять незашифрованные электронные письма с помощью SMTP;

    порт 465 — он используется, если вы хотите безопасно отправлять сообщения с помощью SMTP.

    По каким протоколам происходит обмен электронной почтой? Понятия и термины

    Термин «сервер электронной почты» относится к двум серверам, необходимым для отправки и получения писем, то есть к SMTP и POP.

    Сервер входящей почты — это сервер, связанный с вашей учетной записью адреса электронной почты. Для нее не может быть более одного входящего почтового сервера. Для доступа к входящим сообщениям необходим почтовый клиент — программа, которая может получать электронную почту из учетной записи, позволяя пользователю читать, пересылать, удалять и отвечать на сообщения. В зависимости от вашего сервера, вы можете использовать выделенный почтовый клиент (например, Outlook Express) или веб-браузер. Так, Internet Explorer применяют для доступа к учетным записям на основе электронной почты. Письма хранятся на сервере входящей почты до его загрузки. После того, как вы загрузили свою почту с почтового сервера, сделать повторно это будет нельзя. Чтобы успешно загрузить данные, необходимо ввести правильные настройки в электронной почтовой программе. Большинство входящих почтовых серверов используют один из следующих протоколов: IMAP, POP3, HTTP.

    Исходящий почтовый сервер (SMTP)

    Это сервер, используемый только для отправки писем (для переноса их из вашей почтовой клиентской программы в приемник). Большинство исходящих почтовых серверов используют SMTP-протокол (Simple Mail Transfer Protocol) для отправки корреспонденции. В зависимости от ваших сетевых параметров сервер исходящей почты может принадлежать вашему интернет-провайдеру или серверу, на котором вы настраиваете свою учетную запись. В качестве альтернативы вы можете использовать SMTP-сервер на основе подписки, который позволит вам отправлять электронные письма с любой учетной записи. Из-за проблем со спамом большинство исходящих почтовых серверов не позволяют отправлять электронные письма, если вы не вошли в свою сеть. Сервер с открытым ретранслятором позволит вам использовать его для отправки электронных писем, независимо от того, принадлежите ли вы к его сетевой группе или нет.

    Порты электронной почты

    Для сетей порт означает конечную точку логического соединения. Номер порта определяет его тип. Ниже перечислены порты электронной почты по умолчанию:

    безопасный SMTP (SSMTP) — порт 465;

    безопасный IMAP (IMAP4-SSL) — порт 585;

    IMAP4 через SSL (IMAPS) — порт 993;

    Secure POP3 (SSL-POP) — порт 995.

    Протоколы электронной почты: IMAP, POP3, SMTP и HTTP

    В основном протокол относится к стандартному методу, используемому на каждом конце канала связи. Чтобы иметь дело с электронной почтой, вы должны использовать специальный клиент для доступа к почтовому серверу. В свою очередь, они могут обмениваться информацией друг с другом, используя при этом совершенно различные протоколы.

    Протокол IMAP

    IMAP (протокол доступа к интернет-сообщениям) — стандартный протокол для доступа к электронной почте с вашего локального сервера. IMAP — это протокол типа «клиент/сервер», в котором электронная почта получена, и данные сохраняются вашим интернет-сервером. Поскольку для этого требуется только небольшая передача данных, он хорошо работает даже при медленном соединении, например, при подключении с помощью модема. При попытке прочитать конкретное сообщение электронной почты клиент загружает данные с сервера. Вы также можете создавать и управлять папками или почтовыми ящиками на сервере, удалять сообщения.

    Протокол POP3

    Протокол передачи электронной почты POP (Post Office Protocol 3) обеспечивает простой, стандартизированный способ доступа пользователей к почтовым ящикам и загрузки сообщений на их компьютеры.

    При использовании протокола POP все ваши сообщения электронной почты будут загружены с почтового сервера на локальный компьютер. Вы также можете оставить копии своих электронных писем на сервере. Преимущество заключается в том, что после загрузки ваших сообщений вы можете отключить интернет-соединение и прочитать свой e-mail на досуге, не прибегая к дополнительным расходам на связь. С другой стороны, с помощью этого протокола вы получаете и загружаете много нежелательных сообщений (включая спам или вирусы).

    Протокол SMTP

    Протокол SMTP (Simple Mail Transfer Protocol) используется агентом передачи почты (MTA) для доставки электронных сообщений на определенный сервер получателя. SMTP можно использовать только для отправки электронных писем, а не для их получения. В зависимости от настроек вашей сети или интернет-провайдера вы можете использовать SMTP-протокол только в определенных условиях.

    Протоколы HTTP

    HTTP не является протоколом, предназначенным для связи по электронной почте, но его можно использовать для доступа к вашему почтовому ящику. Его также нередко называют веб-электронной почтой. Он может использоваться для составления или получения электронных писем из вашей учетной записи. Hotmail — хороший пример использования HTTP в качестве протокола электронной почты.

    Управляемые передачи файлов и сетевые решения

    Ваша способность отправлять и получать электронную почту в основном обусловлена ​тремя протоколами TCP. Ими являются SMTP, IMAP и POP3.

    Начнем с SMTP, потому что его основная функция отличается от двух других. Протокол SMTP, или Simple Mail Transfer Protocol, в основном используется для отправки электронной почты от почтового клиента (например, Microsoft Outlook, Thunderbird или Apple Mail) на сервер электронной почты. Он также используется для ретрансляции или пересылки почтовых сообщений с одного почтового сервера на другой. Это необходимо в случае, если у отправителя и получателя есть разные поставщики услуг электронной почты.

    SMTP, который указан в RFC 5321, использует порт 25 по умолчанию. Он также может использовать порт 587 и порт 465. Последний, который был представлен как порт выбора для безопасного SMTP (a.k.a. SMTPS), считается устаревшим. Но на самом деле он по-прежнему используется несколькими поставщиками почтовых услуг.

    Протокол почтового отделения, или POP, используется для извлечения сообщений электронной почты с почтового сервера на e-mail-клиент. Последняя версия, которая широко используется, — это версия 3, отсюда и термин «POP3».

    POP, версия 3, указанная в RFC 1939, поддерживает расширения и несколько механизмов аутентификации. Функции проверки подлинности необходимы, чтобы злоумышленники не получали доступ к сообщениям пользователей.

    Клиент POP3 получает электронную почту следующим образом:

    подключается к почтовому серверу на порту 110 (или 995 для соединений SSL/TLS);

    извлекает сообщения электронной почты;

    удаляет копии сообщений, хранящихся на сервере;

    отключается от сервера.

    Хотя клиенты POP могут быть настроены так, чтобы сервер мог продолжать хранить копии загруженных сообщений, описанные выше шаги являются обычной практикой.

    IMAP, особенно текущая версия (IMAP4), является более сложным протоколом. Это позволяет пользователям группировать связанные сообщения и размещать их в папках, которые, в свою очередь, могут быть организованы иерархически. Он также оснащен флагами сообщений, которые указывают, было ли сообщение прочитано, удалено или получено. Он даже позволяет пользователям выполнять поиск по почтовым ящикам сервера.

    Логика работы (настройки imap4):

    подключается к почтовому серверу через порт 143 (или 993 для соединений SSL / TLS);

    извлекает сообщения электронной почты;

    служит для подключения до закрытия приложения почтового клиента и загрузки сообщений по требованию.

    Обратите внимание, что сообщения не удаляются на сервере. Это может иметь серьезные последствия. Спецификации IMAP можно найти в RFC 3501.

    Выбор между IMAP и POP3

    Поскольку основная функция SMTP принципиально отлична, дилемма выбора лучшего протокола обычно включает только IMAP и POP3.

    Если для вас важно место для хранения на сервере, то выбирайте POP3. Сервер с ограниченным объемом памяти является одним из основных факторов, которые могут заставить вас поддержать POP3. Поскольку IMAP оставляет сообщения на сервере, он может потреблять пространство памяти быстрее, чем POP3.

    Если вы хотите получить доступ к почте в любое время, то лучше остановиться на IMAP. Есть одна веская причина, по которой IMAP был предназначен для хранения сообщений на сервере. Он используется для поиска сообщений с нескольких устройств — иногда даже одновременно. Поэтому если у вас есть iPhone, планшет Android, ноутбук и рабочий стол и вы хотите читать электронную почту с любого или всех этих устройств, то IMAP будет лучшим выбором.

    Синхронизация — еще одно преимущество IMAP. Если вы получаете доступ к сообщениям электронной почты с нескольких устройств, скорее всего, захотите, чтобы все они отображали любые действия, которые вы выполняли.

    Например, если вы читаете сообщения A, B и C, то хотите, чтобы они также были помечены как «прочитанные» на других устройствах. Если вы удалили письма B и C, то захотите, чтобы те же сообщения удалялись из вашего почтового ящика на всех гаджетах. Все эти синхронизации могут быть достигнуты только в том случае, если вы используете IMAP.

    Поскольку IMAP позволяет пользователям упорядочивать сообщения в иерархическом порядке и размещать их в папках, это помогает пользователям лучше организовывать свою корреспонденцию.

    Разумеется, все функциональные возможности IMAP имеют свою цену. Эти решения сложнее реализовать, и в конечном итоге протокол потребляет намного больше ЦП и ОЗУ, особенно когда он выполняет процесс синхронизации. Фактически высокая загрузка процессора и памяти может произойти как на стороне клиента, так и на стороне сервера, если есть тонна сообщений для синхронизации. С этой точки зрения протокол POP3 менее затратен, хотя и менее функционален.

    Конфиденциальность также является одной из проблем, которая будет сильно зависеть от конечных пользователей. Они, как правило, предпочли бы загружать все сообщения электронной почты и не оставлять их копии на неизвестном сервере.

    Скорость — преимущество, которое варьируется и зависит от ситуации. POP3 имеет возможность загружать все почтовые сообщения при подключении. А IMAP может при необходимости (например, при недостаточном количестве трафика) загружать только заголовки сообщений или определенные части и оставлять вложения на сервере. Только когда пользователь решит, что оставшиеся части стоят загрузки, они станут доступны для него. Поэтому IMAP можно считать более быстрым.

    Однако если все сообщения на сервере должны загружаться каждый раз, то POP3 будет работать гораздо быстрее.

    Как вы можете увидеть, каждый из описываемых протоколов имеет свои преимущества и недостатки. Вам решать, какие функции или возможности важнее.

    Также желаемый способ доступа к e-mail-клиенту определяет предпочтительность протокола. Пользователи, работающие только с одной машины и использующие веб-почту для доступа к своим новым электронным письмам, оценят POP3.

    Однако пользователи, которые обмениваются почтовыми ящиками или получают доступ к своим электронным письмам с разных компьютеров, предпочтут IMAP.

    Спам-брандмауэры с SMTP, IMAP и POP3

    Большинство брандмауэров для спама имеют дело только с протоколом SMTP и защищают его. Серверы отправляют и получают электронную почту SMTP, и они будут проверяться спамом-брандмауэром на шлюзе. Однако некоторые брандмауэры для спама дают возможность защищать POP3 и IMAP4, когда внешним пользователям нужны эти службы для доступа к их электронной почте.

    Брандмауэры SMTP прозрачны для конечных пользователей; для клиентов нет изменений конфигурации. Пользователи по-прежнему получают и отправляют почтовые сообщения на сервер электронной почты. Так, Exchange или Dominos должны настраивать маршрутизацию сообщений на брандмауэр на основе прокси-сервера при отправке электронной почты, а также обеспечивать возможность отправки писем с брандмауэра.

    Что такое код imap_close

    Протокол IMAP представляет собой альтернативу POP3.

    POP3 имеет ряд недостатков, и наиболее серьёзный из них — отсутствие возможностей по управлению перемещением и хранением сообщений на сервере. Сообщения, как правило, загружаются с почтового сервера все сразу, после чего они с сервера удаляются, то есть отсутствует возможность выбирать сообщения для получения.

    Для решения проблем, связанных с этой особенностью POP3, в Вашингтонском университете был разработан новый протокол, предполагающий возможность получения пользователями электронной почты из одного почтового ящика из различных мест, при этом сообщения не распределяются между точками получения. Пользователю предоставляется возможность управлять сообщениями в его почтовом ящике и дополнительными функциями по обслуживанию почтовых ящиков на сервере.

    Преимущества по сравнению с POP3

    При использовании POP3 клиент подключается к серверу только на промежуток времени, необходимый для загрузки новых сообщений. При использовании IMAP соединение не разрывается, пока пользовательский интерфейс активен, а сообщения загружаются только по требованию клиента. Это позволяет уменьшить время отклика для пользователей, в чьих ящиках имеется много сообщений большого объёма.

    Протокол POP требует, чтоб текущий клиент был единственным подключенным к ящику. IMAP позволяет одновременный доступ нескольких клиентов к ящику и предоставляет клиенту возможность отслеживать изменения, вносимые другими клиентами, подключенными одновременно с ним.

    Благодаря системе флагов, определенной в IMAP4, клиент может отслеживать состояние сообщения (прочитано, отправлен ответ, удалено и т. д.); данные о флагах хранятся на сервере.

    Клиенты IMAP4 могут создавать, переименовывать и удалять ящики и перемещать сообщения между ящиками. Кроме того, можно использовать расширение IMAP4 Access Control List (ACL) Extension (RFC 4314) для управления правами доступа к ящикам.

    Поиск сообщений происходит на стороне сервера.

    IMAP4 имеет явный механизм расширения.

    Версии протокола IMAP

    • Original IMAP (1986, спецификация отсутствует)
    • IMAP2 (1988 — RFC 1064, 1990 — RFC 1176)
    • IMAP3 (1991, RFC 1203)
    • IMAP2bis (спецификация существует только в черновом варианте 1993 года)
    • IMAP4 (переименованный IMAP2bis)

    Сообщения и их атрибуты

    IMAP работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.

    Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами.

    Каждому сообщению ставится в соответствие 32-битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Чем позже сообщение пришло, тем больше его UID.

    UID ассоциируется с почтовым ящиком и посылается в виде кода uidvalidity отклика (ok) на фазе выбора почтового ящика. Если UID из предыдущей сессии по какой-то причине не может быть использован, UID должен быть инкрементирован.

    UID сообщения не должно изменяться в пределах сессии, его не следует изменять и от сессии к сессии. Однако если невозможно сохранить UID сообщения в последующей сессии, каждая следующая сессия должна иметь новый уникальный код идентификатора, который должен быть больше, чем любой UID, использованный ранее.

    Порядковый номер сообщения

    Порядковый номер сообщения в почтовом ящике начинается с 1. Каждое сообщение, начиная со второго, имеет порядковый номер ровно на 1 больше, чем предшествующее ему.

    В течение сессии допустимо изменение порядкового номера сообщения. Например, когда сообщение удаляется из почтового ящика, номера всех последующих сообщений изменяются.

    Флаги сообщения

    Этот атрибут представляет собой список из нуля или более именованных лексем, соотнесенный данному сообщению. Флаг устанавливается путём его добавления к этому списку и обнуляется путём его удаления. В IMAP 4.1 существует два типа флагов. Флаг может быть постоянным или действующим только на время данной сессии.

    Системным флагом является флаг, имя которого определено в спецификации протокола. Все системные флаги начинаются с символа \ .

    В настоящее время определены следующие системные флаги:

    • \seen — сообщение прочитано
    • \answered — на сообщение отправлен ответ
    • \flagged — сообщение отмечено как «важное»
    • \deleted — сообщение отмечено как удаленное
    • \draft — сообщение отмечено как черновик
    • \recent — недавнее сообщение (впервые появилось в ящике в ходе текущей сессии)

    Внутренние дата и время сообщения на сервере

    Время и дата получения сообщения. В случае доставки сообщения посредством протокола SMTP — дата и время доставки конечному адресату. Для сообщений, доставленных командой копирования — внутренняя дата и время отправителя сообщения. При использовании команды append — дата и время, заданные параметрами команды.

    Прочие атрибуты

    • размер сообщения — число октетов в сообщении.
    • структура конверта сообщения.
    • структура тела сообщения

    Взаимодействие клиента и сервера

    Соединение IMAP 4.1 подразумевает установление связи между клиентом и сервером. Клиент посылает серверу команды, сервер клиенту — данные и уведомления о статусе выполнения запроса. Все сообщения, как клиента, так и сервера имеют форму строк, завершающихся специальной последовательностью.

    Любая процедура начинается с команды клиента. Любая команда клиента начинается с префикса-идентификатора (обычно короткая буквенно-цифровая строка, например, A0001 , A0002 и т. д.), называемого меткой (tag). Для каждой команды клиент генерирует свою метку.

    Возможны два случая, когда строка, отправленная клиентом, не представляет собой законченную команду. В первом — аргумент команды снабжается кодом, определяющим число октетов в строке. Во втором — аргументы команды требуют отклика со стороны сервера. В обоих случаях сервер посылает запрос продолжения команды, начинающийся с символа + .

    Клиент должен завершить отправку одной команды, прежде чем отправить другую.

    Протокольный приемник сервера читает строку команды, пришедшей от клиента, осуществляет её разбор, выделяет параметры и передает серверу данные. По завершении команды сервер посылает отклик.

    Данные, передаваемые сервером клиенту, а также статусные отклики, которые не указывают на завершение выполнения команды, имеют префикс * и называются непомеченными откликами.

    Данные могут быть отправлены сервером в ответ на команду клиента или по собственной инициативе. Формат данных не зависит от причины отправки.

    Отклик указывает на удачное/неудачное выполнение операции. Он использует ту же метку, что и команда клиента, запустившая процедуру. Таким образом, если осуществляется более чем одна команда, метка сервера указывает на команду, вызвавшую данный отклик. Имеется три вида отклика завершения сервера: ok (успешное выполнение), no (неудача), bad (протокольная ошибка, например, не узнана команда или зафиксирована синтаксическая ошибка).

    Протокольный приемник клиента IMAP 4.1 читает строку отклика от сервера и предпринимает действия в соответствии с первым символом * или + .

    Клиент должен быть готов принять любой отклик сервера в любое время. Данные сервера должны быть записаны так, чтобы клиент мог их непосредственно использовать, не посылая серверу уточняющих запросов.

    Состояния сервера IMAP

    Сервер IMAP 4.1 находится в одном из четырёх состояний.

    Большинство команд можно использовать только в определенных состояниях.

    В состоянии без аутентификации клиент должен предоставить имя и пароль, прежде чем ему станет доступно большинство команд. Переход в это состояние производится при установлении соединения без предварительной аутентификации.

    В состоянии аутентификации клиент идентифицирован и должен выбрать почтовый ящик, после чего ему станут доступны команды для работы с сообщениями. Переход в это состояние происходит при установлении соединение с предварительной аутентификацией, когда выданы все необходимые идентификационные данные или при ошибочном выборе почтового ящика.

    В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика.

    В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.

    • (1) Соединение без предварительной аутентификации
    • (2) Соединение с предварительной аутентификацией
    • (3) Соединение отвергнуто
    • (4) Успешное завершение команды LOGIN или AUTHENTICATE
    • (5) Успешное завершение команды SELECT или EXAMINE
    • (6) Выполнение команды CLOSE или неудачная команда SELECT или EXAMINE
    • (7) Выполнение команды LOGOUT , закрытие сервера, или прерывание соединения

    Национальная библиотека им. Н. Э. Баумана
    Bauman National Library

    Персональные инструменты

    IMAP (Internet Message Access Protocol)

    IMAP
    Международный стандарт: Internet Message Access Protocol
    Уровень (по модели OSI): Прикладной
    Семейство: стек протоколов TCP/IP
    Порт/ID: 143/TCP, 993/TCP (IMAP over SSL)
    Назначение протокола: Доступ к почтовым ящикам
    Спецификация: RFC 3501
    Основные реализации (клиенты): MUA (Outlook Express, Opera, Mozilla Thunderbird, The Bat!, Claws Mail, mutt)
    Основные реализации (серверы): UW IMAP,
    Courier,
    Cyrus,
    Dovecot
    Вступил в силу с: 1986

    IMAP (англ. Internet Message Access Protocol ) — протокол прикладного уровня для доступа к электронной почте. Базируется на транспортном протоколе TCP и использует порт 143. IMAP предоставляет пользователю обширные возможности для работы с почтовыми ящиками, находящимися на центральном сервере. Почтовая программа, использующая этот протокол, получает доступ к хранилищу корреспонденции на сервере так, как будто эта корреспонденция расположена на компьютере получателя. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без постоянной пересылки с сервера и обратно файлов с полным содержанием писем.

    Для отправки писем используется обычно протокол SMTP, так как собственная команда отправки протокола IMAP, называемая APPEND, считается «неудачной» и «небезопасной».

    Содержание

    Область применения

    Область применения протокола IMAP аналогична области применения протокола POP3: он тоже предназначен для получения почты и используется на участке между MUA получателя и хранилищем сообщений. IMAP предоставляет более широкие возможности работы с почтовыми ящиками, чем POP3: он позволяет работать с несколькими почтовыми ящиками на одном или нескольких серверах IMAP как с файлами и каталогами на собственной машине пользователя. Обычно почтовые ящики сервера IMAP действительно представляют собой файлы в специальном каталоге сервера и его подкаталогах.

    Версии IMAP

    • Original IMAP
    • IMAP2
    • IMAP3
    • IMAP2bis
    • IMAP4
    • IMAP4rev1

    Преимущества IMAP над POP3

    При использовании POP3 клиент подключается к серверу только на промежуток времени, необходимый для загрузки новых сообщений. При использовании IMAP соединение не разрывается, пока пользовательский интерфейс активен, а сообщения загружаются только по требованию клиента. Это позволяет уменьшить время отклика для пользователей, в чьих ящиках имеется много сообщений большого объёма.

    Протокол POP требует, чтобы текущий клиент был единственным подключенным к ящику. IMAP позволяет одновременный доступ нескольких клиентов к ящику и предоставляет клиенту возможность отслеживать изменения, вносимые другими клиентами, подключенными одновременно с ним.

    Благодаря системе флагов, определенной в IMAP4, клиент может отслеживать состояние сообщения (прочитано, отправлен ответ, удалено и т. д.); данные о флагах хранятся на сервере. Клиенты IMAP4 могут создавать, переименовывать и удалять ящики и перемещать сообщения между ящиками. Кроме того, можно использовать расширение IMAP4 Access Control List для управления правами доступа к ящикам.

    Поиск сообщений происходит на стороне сервера. IMAP4 имеет явный механизм расширения.

    Недостатки IMAP

    Множественный доступ к почтовым ящикам связан с рядом проблем, особенно, если информация в ящиках доступна для записи.

    Хотя программное обеспечение, реализующее протокол IMAP , постоянно совершенствуется, IMAP менее защищен, чем POP3. Возможность хранить сообщения на сервере может стать причиной злоупотреблений со стороны пользователей, которые будут переполнять хранилище сообщений ненужной информацией.

    Протокол IMAP предполагает в основном работу пользователей с почтовыми ящиками непосредственно на сервере, в отличие от протокола POP3, который ориентирован на то, что клиент забирает пришедшую почту и разбирает ее уже на своей машине. Это делает IMAP неудобным для пользователей, подключающихся к сети кратковременно, только для того, чтобы получить или отослать почту. При работе по протоколу IMAP клиенту желательно иметь доступ к сети все время, пока он работает с почтой.

    Большие возможности, предоставляемые протоколом IMAP , создают большие сложности при разработке, настройке и эксплуатации серверов и клиентов.

    Общие сведения

    Допускается иерархическое расположение почтовых ящиков в каталогах и их подкаталогах, причем имена каталогов и почтовых ящиков сами по себе не различаются. Почтовый ящик может быть только конечным элементом иерархической структуры, он не может содержать никаких нижестоящих элементов. Каталог может содержать подкаталоги и почтовые ящики, но он не содержит сообщений и не может быть выбран командой SELECT .

    Символ, используемый в качестве иерархического разделителя, может различаться в зависимости от используемого на сервере программного обеспечения. Обычно это косая черта: / , если сервер работает под управлением операционной системы, совместимой с UNIX , обратная косая черта: \ для операционной системы Windows и точка для имен групп новостей USENET.

    Допускается использование различных пространств имен почтовых ящиков и, соответственно, разных иерархических разделителей. Например, если сервер IMAP предоставляет доступ к ящикам, расположенным в каталогах файловой системы UNIX и к группам новостей USENET , то в первом случае в качестве иерархического разделителя используется косая черта, а во втором – точка. Чтобы использовать и различать разные пространства имен на одном сервере IMAP , имена, принадлежащие каждому из используемых пространств, должны начинаться с некоторого префикса, обычно начинающегося символом «#». Естественно, запросы, в которых путь к ящику начинается с одного префикса, будут давать отличные результаты от таких же запросов, начинающихся с другого префикса. Используемое по умолчанию пространство имен может префикса не иметь.

    Клиент может выяснить, какие именно пространства имен для почтовых ящиков каких типов поддерживаются данным сервером IMAP , если сервер поддерживает расширение NAMESPACE. Префикс и иерархический разделитель конкретного имени почтового ящика или каталога можно выяснить при помощи команды LIST.

    Состояния сервера

    Сервер IMAP ожидает соединения от клиентов на порту TCP 143. После установления соединения сервер посылает свое приветствие клиенту, и начинается диалог, в котором клиент посылает серверу команды, а сервер сообщает о результатах их выполнения или присылает затребованную клиентом информацию. Как и сеанс POP3, сеанс IMAP делится на несколько состояний ( states ). Допустимый набор команд зависит от текущего состояния сеанса. Сеанс может находиться в одном из следующих состояний:

    • Неаутентифицированное состояние
    • Аутентифицированное состояние
    • Выбранное состояние
    • Состояние выхода
    1. Соединение без предварительной аутентификации
    2. Соединение с предварительной аутентификацией
    3. Отвергнутое соединение
    4. Успешная аутентификация
    5. Успешное выполнение команды SELECT или EXAMINE
    6. Команда CLOSE или неудачное завершение команды SELECT или EXAMINE
    7. Команда LOGOUT или потеря связи

    Команды протокола IMAP

    Команды клиента и ответы сервера IMAP

    Команда клиента состоит из идентификатора (ярлыка) – короткой строкой, состоящей из букв и цифр, не повторяющейся в других командах в течение всего сеанса. За ярлыком следует сама команда и ее аргументы. Регистр символов в названиях команд, как и в большинстве аргументов, как правило, не имеет значения.

    Кроме стандартных команд, которые обязательно должны поддерживаться, имеются также дополнительные команды, описанные в стандартах и поддерживаемые серверами IMAP как элементы расширений. Разработчики также могут добавлять в своих реализациях новые команды. Названия таких нестандартизированных команд должны начинаться с буквы Х. Имена стандартных команд с буквы Х начинаться не могут.

    Все ответы сервера начинаются с метки, после которой следует отделенный пробелом текст.

    В ответах сервера, сообщающих об исполнении команд, в качестве метки используется ярлык соответствующей команды. Это помеченные ответы. За ним следует одно из ключевых слов:

    • OK (успешное выполнение)
    • NO (невыполнение)
    • BAD (ошибка в команде)

    Ответы, содержащие информацию, запрошенную клиентом или посылаемую сервером без запроса, начинаются с метки «*», такие ответы называются непомеченными. После метки следуют номер опрашиваемого сообщения и ключевое слово или только ключевое слово. Ключевых слов для непомеченных ответов предусмотрено значительно больше, чем для помеченных, обычно они соответствуют имени команды или характеру передаваемой клиенту информации.

    Каждая команда должна получить один помеченный ответ сервера, свидетельствующий о возможности или невозможности исполнения команды, и, возможно, один или несколько непомеченных ответов, содержащих запрошенную или дополнительную информацию.

    Клиент может послать несколько команд подряд, не дожидаясь ответа на каждую из них, если принятие решения о следующей команде не зависит от ответа на предыдущую. Сервер, получив несколько команд подряд, может выполнять их параллельно, если для успешного выполнения следующей команды не требуется выполнение предыдущей. Ответы в этом случае могут поступать в порядке, отличном от того, в каком команды посылались. Соответствие помеченных ответов посланным командам клиент определяет по ярлыкам.

    Надо соблюдать осторожность и следить за тем, чтобы при одновременном выполнении команд не возникало неоднозначностей. Например, при удалении сообщения из ящика изменяется нумерация оставшихся сообщений, что может привести к неоднозначной интерпретации команды, одновременно обращающейся к другому сообщению в том же почтовом ящике.

    Информация, передаваемая в команде или в непомеченном ответе, не обязательно должна укладываться в одну строку. Данные, которые передаются как продолжение команды или непомеченного ответа, называются литералом. На конце строки, которая должна быть продолжена литералом, ставится его размер в октетах, заключенный в фигурные скобки.

    Сервер может передавать литерал, не дожидаясь разрешения клиента, клиент, прежде чем передавать литерал, должен дождаться разрешения – строки, начинающейся с метки «+». Например:

    Команды, допустимые при любом состоянии сеанса IMAP

    CAPABILITY

    В ответ на эту команду сервер присылает непомеченную строку с ключевым словом CAPABILITY, содержащую список поддерживаемых возможностей (расширений) и их параметров. В число возможностей входит в частности поддерживаемая версия протокола IMAP – IMAP4rev1 и механизмы аутентификации. Возможности IMAP описываются в различных RFC или могут вводиться разработчиками. В последнем случае их названия должны начинаться с буквы Х. Названия стандартных возможностей с этой буквы начинаться не могут.

    Не выполняет никаких действий. Однако эта команда сбрасывает таймер неактивности, что позволяет избежать разрыва соединения по таймауту. Кроме того, при определенных обстоятельствах эта или другая команда служит неявным запросом информации об обновлениях, произошедших на сервере. Таким образом, с помощью команды NOOP можно периодически проверять, не появились ли новые сообщения или не изменился ли статус старых. Это можно делать и с помощью других команд, но, поскольку команда NOOP не производит никаких других действий, использование ее с описанной целью предпочтительнее.

    LOGOUT

    Команды неаутентифицированного состояния

    Клиент должен успешно аутентифицироваться, чтобы перейти в следующее состояние. Алгоритмы аутентификации для протокола IMAP не отличаются принципиально от рассматривавшихся в предыдущих главах алгоритмов аутентификации для протоколов SMTP и POP3.

    Серверы IMAP могут допускать анонимный доступ к некоторым почтовым ящикам. Анонимный пользователь регистрируется под именем anonymous, в качестве пароля используется адрес электронной почты пользователя, имя его домена, произвольный набор символов или пустая строка. Анонимный доступ возможен как при передаче пароля открытым текстом, так и с использованием SASL. Возможности анонимного клиента должны быть строго ограничены, как правило, он не получает прав на изменение какой-либо информации на сервере.

    STARTTLS

    Перевод сеанса в защищенный режим. После получения сервером команды STARTTLS клиент и сервер согласовывают параметры дальнейшего взаимодействия. Все данные, которыми обмениваются клиент и сервер после успешного завершения этой команды, передаются в зашифрованном виде. Однако аутентификация при помощи этой команды не производится, сеанс остается в неаутентифицированном состоянии.

    LOGIN

    LOGIN регистрационное_имя_пользователя пароль

    Аутентификация при помощи регистрационного имени и пароля, передаваемых открытым текстом.

    AUTHENTICATE

    Передача зашифрованных аутентификационных данных с использованием SASL.

    Команды аутентифицированного состояния

    В аутентифицированном состоянии клиент производит различные манипуляции с почтовыми ящиками.

    SELECT

    Открывает доступ к указанному почтовому ящику. Сеанс переходит в состояние выбора, после этого клиент может работать с отдельными сообщениями в ящике.

    В ответ на эту команду сервер присылает ряд непомеченных ответов, содержащих информацию о почтовом ящике: количество сообщений, список допустимых флагов, количество новых сообщений, номер первого непрочитанного сообщения, идентификатор почтового ящика.

    EXAMINE

    Аналогично команде SELECT , но почтовый ящик открывается только для чтения.

    CREATE

    Создает новый почтовый ящик или каталог.

    Если объект создается не в корневом каталоге, то надо указать путь к нему.

    Если на конце указанного имени стоит символ, используемый в качестве иерархического разделителя, создается каталог.

    DELETE

    Удаляет указанный почтовый ящик. Эта же команда удаляет также и каталоги, если они не содержат почтовые ящики.

    RENAME

    RENAME имя_ящика новое_имя_ящика

    Переименование почтового ящика.

    SUBSCRIBE

    Почтовый ящик помечается как «активный». Эта пометка используется для вывода списка почтовых ящиков при помощи команды LSUB.

    UNSUBSCRIBE

    Снимает с почтового ящика пометку «активный». Эта пометка может быть снята с почтового ящика только при помощи команды UNSUBSCRIBE. Даже если ящик больше не существует, это не может само по себе стать причиной снятия пометки «активный».

    LIST путь_к_ящику имя_ящика

    Возвращает список каталогов и почтовых ящиков, соответствующих указанным аргументам.

    В имени ящика могут использоваться групповые символы: * , обозначающий любые символы и % , обозначающий любые символы кроме иерархических разделителей.

    Если имя ящика само по себе содержит полный путь к ящику, то первый аргумент игнорируется.

    В ответ сервер присылает одну или несколько непомеченных строк с ключевым словом LIST. Каждая из них содержит атрибуты, если таковые имеются, иерархический разделитель и имя почтового ящика или каталога, отвечающего заданным в аргументах условиям. Атрибуты заключаются в скобки, иерархический разделитель – в кавычки.

    RFC 3501 предусматривает четыре атрибута:

    • \Noinferiors – объект нижнего уровня иерархии – почтовый ящик, не каталог
    • \Noselect – объект – каталог, он не может быть выбран командой SELECT
    • \Marked – почтовый ящик отмечен как представляющий интерес, это означает, что со времени последнего обращения к ящику туда были добавлены новые сообщения
    • \Unmarked – со времени последнего обращения в почтовый ящик не поступило новых сообщений

    В описанном в RFC 3348 расширении CHILDREN предусмотрены еще два атрибута, позволяющие определить, содержит ли каталог почтовые ящики или подкаталоги:

    • \HasChildren – каталог содержит почтовые ящики или подкаталоги;
    • \HasNoChildren – объект не содержит почтовых ящиков или подкаталогов, доступных пользователю, аутентифицированному в данном сеансе.

    Оставив пустым второй аргумент команды LIST , можно выяснить используемый в первом аргументе префикс пространства имен. В этом случае ответ сервера вместо имени ящика будет содержать имя корневого каталога, то есть префикс пространства имен с иерархическим разделителем на конце.

    Если оба аргумента команды LIST пустые, то сервер возвращает только используемый по умолчанию иерархический разделитель.

    LSUB путь_к_ящику имя_ящика

    Команда LSUB аналогична команде LIST , но она возвращает только имена почтовых ящиков с пометкой «активный».

    STATUS

    STATUS имя_ящика (имена_элементов)

    Возвращает запрошенные элементы информации об указанном почтовом ящике. Имена элементов информации разделяются пробелами и все вместе заключаются в скобки. Предусмотрены следующие имена элементов информации:

    • MESSAGES – общее количество сообщений в ящике
    • RECENT – количество новых сообщений
    • UIDNEXT –уникальный идентификатор, который изменяется всякий раз, когда в почтовый ящик помещается новое сообщение
    • UIDVALIDITY – уникальный идентификатор почтового ящика
    • UNSEEN – количество сообщений, не помеченных как прочитанные

    Ответ представляет собой непомеченную строку с ключевым словом STATUS , за которым следует имя опрашиваемого почтового ящика, после которого в скобках перечисляются имена запрошенных элементов и их числовые значения.

    Добавляет сообщение в конец указанного почтового ящика. В качестве аргументов указываются имя ящика, флаги сообщения (не обязательно), метка времени (не обязательно) и само сообщение – заголовок и тело.

    Имеются следующие флаги сообщений:

    • \ Seen – прочитано
    • \ Answered – написан ответ
    • \ Flagged – срочное
    • \ Deleted – помечено для удаления
    • \ Draft – черновик
    • \Recent – новое сообщение, оно поступило в почтовый ящик после окончания прошлого сеанса

    Если в команде указаны флаги, то они устанавливаются для добавляемого сообщения. В любом случае для сообщения устанавливается флаг \Recent.

    Если в команде задана метка времени, то это время будет установлено в качестве времени создания сообщения, в противном случае за время создания принимается текущее время.

    Поскольку сообщение состоит не из одной строки, используются литералы.

    Команды выбранного состояния

    В выбранном состоянии клиент может выполнять те же действия, что и в аутентифицированном состоянии, и производить манипуляции с сообщениями в выбранном почтовом ящике.

    CHECK

    Команда производит проверку выбранного почтового ящика, характер которой зависит от реализации программного обеспечения сервера.

    CLOSE

    Выбранный почтовый ящик закрывается. При этом, если почтовый ящик был открыт для чтения и записи, все помеченные для удаления сообщения в ящике удаляются. Сеанс возвращается в аутентифицированное состояние.

    EXPUNGE

    Из выбранного почтового ящика удаляются все помеченные для удаления сообщения. Для каждого удаляемого сообщения посылается непомеченный ответ, содержащий номер сообщения и ключевое слово EXPUNGE .

    SEARCH кодировка_символов критерии_поиска

    Поиск в выбранном почтовом ящике сообщений, отвечающих указанным критериям поиска.

    Необязательный первый аргумент команды состоит из слова «CHARSET» и названия кодировки, используемой в критериях поиска. Кодировку нужно указывать, только если она отличается от стандартной US-ASCII.

    Второй аргумент содержит один или более критериев поиска.

    Критерий поиска состоит из ключевого слова и аргумента. Критерии также можно объединять, заключая в скобки. Это бывает удобно при использовании ключевых слов NOT и OR.

    Непомеченные ответы на команду SEARCH содержат номера сообщений, отвечающих указанным критериям.

    FETCH

    FETCH х:у имя_элемента_сообщения_или_макрос

    Сервер возвращает информацию, относящуюся к сообщениям, обозначенным первым аргументом команды. Это может быть либо число, обозначающее номер сообщения, либо интервал от номера х до номера у, записанный в формате х:у.

    Во втором аргументе перечисляются запрашиваемые информационные элементы.

    COPY х:у имя_ящика

    Копирует сообщения с номерами от х до у из текущего почтового ящика в указанный почтовый ящик.

    UID команда аргументы Команда UID принимает в качестве аргументов команды COPY, FETCH или STORE с их аргументами, но наряду с номерами сообщений в ответах указываются уникальные идентификаторы сообщений.

    Также команду UID можно использовать совместно с командой SEARCH. В этом случае интерпретация аргументов команды SEARCH не изменяется, но в ответах на эту команду будут приведены уникальные идентификаторы сообщений.

    Выполнить imap_close не работает

    У меня есть страница с клиентами и с ajax im загружается информация о том, отправляют ли они нам электронную почту или нет.

    Код выглядит следующим образом:

    Но на одной странице есть примерно 20-30 клиентов, поэтому для выполнения этого процесса иногда требуется около 10-20 секунд, и я не смог оптимизировать процесс.

    Но когда клиент пытается перезагрузить страницу, он все еще ждет, пока закончится imap_search , поэтому при перезагрузке это может занять 20 секунд, прежде чем перезагрузка страницы.

    Я попытался прервать ajax с помощью функции beforeunload и закрыть imap , но это не работает.

    Но даже если ajax прерван и imap_close вызывается при удерживании переменной imap_open , для перезагрузки страницы все равно требуется 10-20 секунд, поэтому я предполагаю, что imap не был закрыт.

    Как закрыть imap , чтобы страница могла немедленно перезагрузиться?

    Я бы рекомендовал убить его, создав файл, который вызывает перерыв:

    Затем на вашем выходе ajax просто вызовите php script, который просто создает этот файл. и он сломает ваш цикл и удалит файл.

    Если я правильно понял, длительный код лежит внутри цикла foreach().

    Теперь, даже если вы сделаете второй запрос, чтобы убить сеанс IMAP, этот цикл foreach() будет продолжаться до тех пор, пока он не завершится, или PHP не убьет его, если (и когда) время выполнения превышает настройку max_execution_time.

    В любом случае вам нужно что-то в вашем цикле foreach(), который будет проверять каждый раунд, если было выполнено условие прерывания, чтобы переключаться на прерывание текущего запроса и разрешить клиенту создавать новый.

    Я предлагаю вам взглянуть на функцию PHP connection_aborted(), которую вы могли бы использовать, чтобы обнаружить, как клиент прекратит текущий запрос, и больше обычно вы можете прочитать на тему обработку подключения, чтобы лучше понять, как обрабатываются соединения и запросы в PHP.

    Что такое код imap_close

    imap_close — закрывает IMAP-поток.

    Описание

    int imap_close (int imap_stream [, int flags])

    Закрывает imap-поток. Принимает необязательный флаг flag CL_EXPUNGE, который скрыто вычёркивает mailbox перед закрытием, удаляя все сообщения, помеченные для удаления.


    Назад Оглавление Вперёд
    imap_clearflag_full Вверх imap_createmailbox

    Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:

    IMAP Почтовый клиент

    Столкнулся со следующей проблемой. Когда посылаю команду, например, LIST «» «*», возвращается только одна строка ответа. При дальнейшем считывании ssl потока, считываются и остальные. Вопрос в том, какое условие поставить для цикла чтения из ssl? Не парсить же, пока придёт ответ «OK LIST Completed».

    27.08.2015, 21:59

    SMTP,POP3,IMAP Почтовый клиент
    Во общем smtp клиентское приложение должно отправлять письма на сервер(насколько я понял)а с этого.

    Почтовый клиент
    Мне нужен был почтовый клиент и я нашёл его в интернете. Как его оживить (не получает доступ к.

    Мини почтовый клиент. Авторизация по IMAP или POP3
    Приветствую, возникла такая проблема, хотелось бы написать свой мини почтовый клиент, но возникли.

    Почтовый клиент (SMTP)
    Написал код почтового клиента, но отправки писем так и не добился. Пробовал и с яндекса и с.

    Почтовый клиент для приема сообщений
    Скажите, реально ли написать программу, которое будет заходить на почтовый сервер, считывать письма.

    Работа с входящей почтой через протокол IMAP средствами PHP

    На днях мне пришло задание написать небольшой модуль на PHP, который бы позволил работать с входящей почтой. Немного по гуглив я увидел что для данного задания мне подходит один из протоколов POP3 и IMAP .
    Но выбор был очевиден что использовать я буду IMAP так как он более функциональный и современней, протокола POP3.

    Теперь мне надо было быстренько разобраться как работать с протоколам IMAP , как получить письма из почтового сервера Yandex/Google.

    Для более удобной работы я выбрал библиотеку PhpImap, так как она может быстро и легко реализует все нужные для меня задачи.

    Подключение к почтовому серверу.

    Теперь когда мы определились с выбором протокола и выбором библиотеки, будем пробовать подключатся к почтовому серверу.

    Для полноценной работы PHP с протоколом IMAP, необходимо подключить расширение php_imap.dll/imap.so в файле php.ini.

    Для начало попробуем подключится к Yandex почте так как у меня меньше всего возникло с ней проблем.

    Как мы видим конструктор класса Mailbox принимает следующие аргументы:

    • MAIL_IMAP_PATH — Cодержит в себе адрес сервера (MAIL_IMAP_SERVER), порт подключения (MAIL_IMAP_SERVER_PORT), тип соединения (imap) и показываем что соединение будет зашифровано (ssl). После фигурных скобок указываем папку к которой будем подключаться, в данном случае к входящим сообщениям (INBOX).
    • MAIL_IMAP_LOGIN — Почтовый ящик которому будем подключатся.
    • MAIL_IMAP_PASS — Пароль (чаще всего это пароль от почтового ящика).
    • __DIR__ — Это путь к папке в которой будут сохраняться вложенные файлы и почтовые сообщения.

    После этого мы проверим, создалось ли наше подключение через метод getImapStream() если по какой-то причине подключения не создастся то приложение выбрасывает исключения с причиной не удачного подключения.

    Важно учесть во внимание то что в настройках Yandex почты у вас может быть отключена возможность подключения по протоколу IMAP.

    Теперь давайте сравним подключение к почте Gmail.

    Как мы видим оно практически не отличается от предыдущего подключения, но скорей всего у Вас сработает исключение при подключении к серверу.
    Это проблема связана с тем что в Gmail работа протокола IMAP отключена по умолчанию. Включить её можно в настройках во вкладке Пересылка и POP/IMAP в опции Доступ по протоколу IMAP ⇒ Включить IMAP.

    После того когда мы включили работу по протоколу IMAP нам надо создать пароль приложение. Для того чтобы его можно было создать нам необходимо сделать двух факторную авторизацию для данного профиля. После чего можно приступить к его созданию. Когда мы создадим новый пароль для приложения нам необходимо его будет вписать в константу MAIL_IMAP_PASS для подключения к серверу.

    Учтите что при создании пароля приложений у Вас может быть так и не получится подключиться к серверу это связно с тем что данный пароль еще не применялся окончательно к сервису Gmail обычно это занимает 5-60 минут.

    Выборка данных

    После успешного подключения, мы можем выполнить запрос для получения потовых сообщений из сервера. Для этого мы будем использовать метод searchMailBox(string $criteria) который по сути является оберткой метода imap_search. Тут важно понять что аргумент $criteria является неким критерием поиска нужных нам сообщений, сам метод возвращает идентификаторы элементов которые в последствии нам пригодятся для получения детальной информации почтового сообщения.

    Как Вы уже догадались тут мы получаем все сообщения.
    А теперь давайте попробуем разобраться и с другими не менее важными критериями поиска:

    Данный пример хорошо отражает основы использование критериев поиска.

    Получение информации

    Теперь когда у нас есть массив идентификаторов сообщений мы готовы его обработать:

    Вот мы и получили сообщения из нашего письма и его вложения без всяких заморочек.

    Дополнительные возможности.

    В данной библиотеке также присутствие ряд полезных методов для более удобной работы с почтовыми сообщениями:

    Сохраняем сообщения по его ид.

    Устанавливаем сообщения как непрочитанное по его id.

    Устанавливаем сообщения как прочитанное по его id.

    Устанавливаем на сообщение пометку по его id.

    Удаляем сообщения по его id.

    Естественно мы здесь рассмотрели только незначительную часть но очень важную при работе с входящими почтовыми сообщениями. Также вы можете скачать рассмотренное нами приложение.

    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL