В вычислительной технике протокол доступа к сообщениям Интернета ( IMAP ) — это стандартный протокол Интернета , используемый почтовыми клиентами для получения сообщений электронной почты с почтового сервера через соединение TCP/IP . [1] IMAP определен в RFC 9051.
IMAP был разработан с целью обеспечить полное управление почтовым ящиком несколькими почтовыми клиентами, поэтому клиенты обычно оставляют сообщения на сервере до тех пор, пока пользователь явно не удалит их. Сервер IMAP обычно прослушивает порт номер 143. IMAP через SSL/TLS ( IMAPS ) назначается номер порта 993. [2] [3]
Практически все современные почтовые клиенты и серверы поддерживают IMAP, который наряду с более ранним POP3 (протоколом почтового отделения) является двумя наиболее распространенными стандартными протоколами для получения электронной почты. [4] Многие поставщики услуг веб-почты , такие как Gmail и Outlook.com, также обеспечивают поддержку IMAP и POP3.
Протокол доступа к сообщениям Интернета — это интернет-протокол прикладного уровня , который позволяет клиенту электронной почты получать доступ к электронной почте на удаленном почтовом сервере . Текущая версия определена в RFC 9051. Сервер IMAP обычно прослушивает общеизвестный порт 143, а IMAP через SSL/TLS (IMAPS) использует 993. [2] [3]
Входящие сообщения электронной почты отправляются на сервер электронной почты, который хранит сообщения в почтовом ящике получателя. Пользователь получает сообщения с помощью почтового клиента, который использует один из нескольких протоколов получения электронной почты. Хотя некоторые клиенты и серверы преимущественно используют собственные протоколы, специфичные для конкретного поставщика , [5] почти все поддерживают POP и IMAP для получения электронной почты, что позволяет многим свободно выбирать между множеством почтовых клиентов , таких как Pegasus Mail или Mozilla Thunderbird , для доступа к этим серверам и позволяет клиентам использоваться с другими серверами .
Почтовые клиенты, использующие IMAP, обычно оставляют сообщения на сервере до тех пор, пока пользователь явно не удалит их. Эта и другие характеристики работы IMAP позволяют нескольким клиентам управлять одним и тем же почтовым ящиком. Большинство почтовых клиентов поддерживают IMAP в дополнение к протоколу почтового отделения (POP) для получения сообщений. [6] IMAP обеспечивает доступ к хранилищу почты. Клиенты могут хранить локальные копии сообщений, но они считаются временным кешем.
IMAP был разработан Марком Криспином в 1986 году как протокол почтового ящика удаленного доступа, в отличие от широко используемого POP, протокола для простого получения содержимого почтового ящика.
Прежде чем появилась текущая ВЕРСИЯ 4rev1 (IMAP4), он прошел несколько итераций, как подробно описано ниже:
Исходный протокол временного доступа к почте был реализован в виде клиента Xerox Lisp Machine и сервера TOPS-20 .
Никаких копий оригинальной временной спецификации протокола или его программного обеспечения не существует. [7] [8] Хотя некоторые из его команд и ответов были похожи на IMAP2, во временном протоколе отсутствовала маркировка команд/ответов, и поэтому его синтаксис был несовместим со всеми другими версиями IMAP.
Временный протокол был быстро заменен протоколом интерактивного доступа к почте (IMAP2), определенным в RFC 1064 (в 1988 году) и позже обновленным RFC 1176 (в 1990 году). IMAP2 представил тегирование команд/ответов и стал первой общедоступной версией.
IMAP3 — чрезвычайно редкий вариант IMAP. [9] Он был опубликован как RFC 1203 в 1991 году. Он был написан специально как встречное предложение к RFC 1176, который сам предлагал изменения в IMAP2. [10] IMAP3 никогда не был принят на рынке. [11] [12] В 1993 году IESG реклассифицировала RFC1203 «Протокол интерактивного доступа к почте – версия 3» как исторический протокол. Рабочая группа IMAP использовала RFC 1176 (IMAP2), а не RFC 1203 (IMAP3) в качестве отправной точки. [13] [14]
С появлением MIME IMAP2 был расширен для поддержки структур тела MIME и добавления функций управления почтовыми ящиками (создание, удаление, переименование, загрузка сообщений), которые отсутствовали в IMAP2. Эта экспериментальная версия называлась IMAP2bis; его спецификация никогда не публиковалась в черновом виде. Интернет-проект IMAP2bis был опубликован рабочей группой IETF IMAP в октябре 1993 года. Этот проект был основан на следующих более ранних спецификациях: неопубликованный документ IMAP2bis.TXT , RFC 1176 и RFC 1064 (IMAP2). [15] Проект IMAP2bis.TXT документировал состояние расширений IMAP2 по состоянию на декабрь 1992 года. [16] Ранние версии Pine были широко распространены с поддержкой IMAP2bis [9] (Pine 4.00 и более поздние версии поддерживают IMAP4rev1).
Рабочая группа IMAP, созданная в IETF в начале 1990-х годов, взяла на себя ответственность за разработку IMAP2bis. Рабочая группа IMAP решила переименовать IMAP2bis в IMAP4, чтобы избежать путаницы.
При использовании POP клиенты обычно подключаются к серверу электронной почты ненадолго, ровно столько времени, сколько необходимо для загрузки новых сообщений. При использовании IMAP4 клиенты часто остаются на связи, пока активен пользовательский интерфейс, и загружают содержимое сообщения по требованию. Для пользователей с большим количеством или большими сообщениями этот шаблон использования IMAP4 может привести к более быстрому времени ответа.
После успешной аутентификации протокол POP обеспечивает полностью статическое представление текущего состояния почтового ящика и не предоставляет механизма отображения каких-либо внешних изменений состояния во время сеанса. Напротив, протокол IMAP обеспечивает динамическое представление и требует, чтобы внешние изменения состояния, включая вновь поступившие сообщения, а также изменения, внесенные в почтовый ящик другими одновременно подключенными клиентами, обнаруживались, и между командами отправлялись соответствующие ответы, а также во время команды IDLE , как описано в RFC 2177. См. также раздел 5.2 RFC 3501, в котором конкретно упоминается «одновременный доступ к одному и тому же почтовому ящику несколькими агентами».
Обычно вся электронная почта Интернета передается в формате MIME , что позволяет сообщениям иметь древовидную структуру , в которой листовые узлы представляют собой любой из множества одночастных типов контента, а неконечные узлы представляют собой любой из множества составных типов. Протокол IMAP4 позволяет клиентам получать любую из отдельных частей MIME отдельно, а также получать части отдельных частей или всего сообщения. Эти механизмы позволяют клиентам получать текстовую часть сообщения без извлечения прикрепленных файлов или передавать содержимое в потоковом режиме по мере его получения.
Благодаря использованию флагов, определенных в протоколе IMAP4, клиенты могут отслеживать состояние сообщения: например, было ли сообщение прочитано, на него ответили или было удалено. Эти флаги хранятся на сервере, поэтому разные клиенты, обращающиеся к одному и тому же почтовому ящику в разное время, могут обнаружить изменения состояния, внесенные другими клиентами. POP не предоставляет клиентам механизма для хранения такой информации о состоянии на сервере, поэтому, если один пользователь обращается к почтовому ящику с двумя разными клиентами POP (в разное время), информация о состоянии, например, был ли осуществлен доступ к сообщению, не может быть синхронизирована между клиенты. Протокол IMAP4 поддерживает как предопределенные системные флаги, так и ключевые слова, определяемые клиентом. Системные флаги указывают информацию о состоянии, например, было ли прочитано сообщение. Ключевые слова, которые поддерживаются не всеми серверами IMAP, позволяют присваивать сообщениям один или несколько тегов , значение которых зависит от клиента. Ключевые слова IMAP не следует путать с собственными метками веб- служб электронной почты, которые иногда переводятся в папки IMAP соответствующими проприетарными серверами.
Клиенты IMAP4 могут создавать, переименовывать и удалять почтовые ящики (обычно представленные пользователю в виде папок) на сервере, а также копировать сообщения между почтовыми ящиками. Поддержка нескольких почтовых ящиков также позволяет серверам предоставлять доступ к общим и общедоступным папкам. Расширение списка управления доступом (ACL) IMAP4 ( RFC 4314) может использоваться для регулирования прав доступа.
IMAP4 предоставляет клиенту механизм запроса сервера на поиск сообщений, отвечающих множеству критериев. Этот механизм позволяет избежать необходимости загрузки клиентами каждого сообщения в почтовом ящике для выполнения такого поиска.
Отражая опыт более ранних интернет-протоколов, IMAP4 определяет явный механизм, с помощью которого его можно расширить. Было предложено множество расширений базового протокола IMAP4, которые широко используются. У IMAP2bis не было механизма расширения, а у POP теперь есть механизм, определенный в RFC 2449.
IMAP IDLE предоставляет почтовому серверу возможность уведомлять подключенных клиентов об изменениях в почтовом ящике, например, о прибытии новой почты. POP не предоставляет сопоставимых функций, и почтовым клиентам необходимо периодически подключаться к POP-серверу для проверки наличия новой почты.
Хотя IMAP устраняет многие недостатки POP, это по своей сути вносит дополнительную сложность. Большая часть этой сложности (например, одновременное обращение нескольких клиентов к одному и тому же почтовому ящику) компенсируется обходными путями на стороне сервера, такими как Maildir или серверные части базы данных.
Спецификацию IMAP критиковали за то, что она недостаточно строгая и допускает поведение, которое фактически сводит на нет ее полезность. Например, в спецификации указано, что каждое сообщение, хранящееся на сервере, имеет «уникальный идентификатор», позволяющий клиентам идентифицировать сообщения, которые они уже видели между сеансами. Однако спецификация также позволяет объявлять эти UID недействительными практически без ограничений, что практически противоречит их цели. [17]
С административной и ресурсной точки зрения протокол IMAP можно рассматривать как раннюю реализацию облачных вычислений , поскольку цель и цель IMAP — поддерживать структуру вашего почтового ящика (содержимое, структуру папок, состояние отдельных сообщений и т. д.) на почтовый сервер, тогда как при использовании POP все это сохраняется на локальном устройстве пользователя. Таким образом, IMAP требует гораздо больше ресурсов на стороне сервера, что приводит к значительно более высоким затратам на почтовый ящик.
Если алгоритмы хранения, индексирования и поиска почты на сервере не будут тщательно реализованы, клиент потенциально может потреблять большие объемы ресурсов сервера при поиске в больших почтовых ящиках.
Клиентам IMAP4 необходимо поддерживать соединение TCP/IP с сервером IMAP, чтобы получать уведомления о прибытии новой почты. Уведомление о прибытии почты осуществляется посредством внутриполосной сигнализации , что в некоторой степени усложняет обработку протокола IMAP на стороне клиента. [18] Частное предложение, push IMAP , расширит IMAP для реализации принудительной отправки электронной почты путем отправки всего сообщения, а не только уведомления. Однако push IMAP не получил общепринятого признания, и текущая работа IETF решает проблему другими способами ( дополнительную информацию см. в профиле Lemonade ).
В отличие от некоторых проприетарных протоколов, которые сочетают в себе операции отправки и получения, отправка сообщения и сохранение копии в папке на стороне сервера с помощью клиента IMAP базового уровня требует передачи содержимого сообщения дважды: один раз в SMTP для доставки и второй раз в IMAP для доставки. хранить в папке отправленных писем. Это решается набором расширений, определенных в профиле IETF Lemonade Profile для мобильных устройств: URLAUTH ( RFC 4467) и CATENATE ( RFC 4469) в IMAP и BURL ( RFC 4468) в SMTP-SUBMISSION. В дополнение к этому Courier Mail Server предлагает нестандартный метод отправки с использованием IMAP путем копирования исходящего сообщения в выделенную папку «Исходящие». [19]
Для криптографической защиты соединений IMAP между клиентом и сервером можно использовать IMAPS на TCP-порту 993, который использует SSL/TLS. [2] [3] По состоянию на январь 2018 года TLS является рекомендуемым механизмом. [20]
В качестве альтернативы STARTTLS можно использовать для шифрования соединения при подключении к порту 143 после первоначальной связи в виде открытого текста .
Это пример соединения IMAP, взятый из раздела 8 RFC 3501:
C: <открытое соединение>S: * ОК. Служба IMAP4rev1 готова.C: a001 вход в секрет mrcS: a001 ОК ВХОД завершенC: a002 выберите почтовый ящикСУБЪЕКТ: * 18 СУЩЕСТВУЕТS: * ФЛАГИ (\Отвечено\Помечено\Удалено\Просмотрено\Черновик)СУБЪЕКТ: * 2 ПОСЛЕДНИЕСУБЪЕКТ: * ОК [НЕВИДИМОЕ 17] Сообщение 17 — первое невидимое сообщение.S: * ОК [UIDVALIDITY 3857529045] UID действительныS: a002 ОК [ЧТЕНИЕ-ЗАПИСЬ] ВЫБОР завершенC: a003 получить 12 полныхS: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17 июля 1996 02:44:25 -0700" RFC822.SIZE 4286 КОНВЕРТ ("Ср, 17 июля 1996 г., 02:23:25 -0700 (PDT)" «Сводка и протокол работы рабочей группы IMAP4rev1» (("Терри Грей" НОЛЬ "грей" "cac.washington.edu")) (("Терри Грей" НОЛЬ "грей" "cac.washington.edu")) (("Терри Грей" НОЛЬ "грей" "cac.washington.edu")) ((НОЛЬ НИЛ "imap" "cac.washington.edu")) ((НОЛЬ НОЛЬ "минуты" "CNRI.Reston.VA.US") («Джон Кленсин» НОЛЬ «КЛЕНСИН» «MIT.EDU»)) НОЛЬ НОЛЬ «<[email protected]>») BODY ("ТЕКСТ" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))S: a003 ОК FETCH завершенC: a004 получить 12 тело [заголовок]S: * 12 FETCH (ТЕЛО[ЗАГОЛОВОК] {342}С: С: С: С: С: С: С: С:Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)From: Terry Gray <[email protected]>Subject: IMAP4rev1 WG mtg summary and minutesTo: [email protected]Cc: [email protected], John Klensin <[email protected]>Message-Id: <[email protected]>MIME-Version: 1.0Content-Type: TEXT/PLAIN; CHARSET=US-ASCIIС:С: )S: a004 ОК FETCH завершенC a005 сохранить 12 +флагов \удаленоS: * 12 FETCH (ФЛАГИ (\Seen\Deleted))S: a005 ОК +ФЛАГИ завершеноC: выход из системы a006S: * ПОКА сервер IMAP4rev1 прерывает соединениеS: a006 ОК ВЫХОД завершен
Знания об исходном IMAP (до IMAP2) существуют в первую очередь в моем сознании, поскольку все исходные спецификации и реализации IMAP были заменены IMAP2.
