Протокол доступа к сообщениям Интернета

«IMAP» перенаправляется сюда. Не путать с MAPI , API почтового клиента.

«IMAP» перенаправляется сюда. Информацию о космическом корабле НАСА см. в разделе « Межзвездное картографирование и зонд ускорения» . Чтобы узнать о нейролептике, см. Флуспирилен .

В вычислительной технике протокол доступа к сообщениям Интернета ( IMAP ) — это Интернета, стандартный протокол используемый почтовыми клиентами для получения сообщений электронной почты с почтового сервера через соединение TCP/IP . IMAP определяется РФК   9051 .

IMAP был разработан с целью обеспечить полное управление почтовым ящиком несколькими почтовыми клиентами, поэтому клиенты обычно оставляют сообщения на сервере до тех пор, пока пользователь явно не удалит их. Сервер IMAP обычно прослушивает порт номер 143. IMAP через SSL/TLS ( IMAPS ) назначает номер порта 993.

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

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

Протокол доступа к сообщениям Интернета — это Интернет-протокол прикладного уровня , который позволяет клиенту электронной почты получать доступ к электронной почте на удаленном почтовом сервере . Текущая версия определяется РФК   9051 . Сервер IMAP обычно прослушивает общеизвестный порт 143, а IMAP через SSL/TLS (IMAPS) использует 993.

Входящие сообщения электронной почты отправляются на сервер электронной почты, который хранит сообщения в почтовом ящике получателя. Пользователь получает сообщения с помощью почтового клиента, который использует один из нескольких протоколов получения электронной почты. Хотя некоторые клиенты и серверы предпочитают использовать собственные протоколы , специфичные для конкретного поставщика , почти все они поддерживают POP и IMAP для получения электронной почты, что дает возможность свободно выбирать между многими почтовыми клиентами , такими как Pegasus Mail или Mozilla Thunderbird, для доступа к этим серверам, а также позволяет использовать клиенты с другими серверами .

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

История

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

Прежде чем появилась текущая ВЕРСИЯ 4rev1 (IMAP4), он прошел несколько итераций, как подробно описано ниже:

Оригинальный IMAP

Исходный протокол временного доступа к почте был реализован в виде клиента Xerox Lisp Machine и сервера TOPS-20 .

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

IMAP2

Временный протокол был быстро заменен протоколом интерактивного доступа к почте (IMAP2), определенным в RFC   1064 (в 1988 г.), позднее обновленный RFC   1176 (1990 г.). IMAP2 представил тегирование команд/ответов и стал первой общедоступной версией.

IMAP3

IMAP3 — чрезвычайно редкий вариант IMAP. Он был опубликован как RFC   1203 1991 года. Он был написан специально как встречное предложение RFC   1176 , который сам предлагал модификации IMAP2. IMAP3 никогда не был принят на рынке. В 1993 году IESG . реклассифицировала RFC1203 «Протокол интерактивного доступа к почте - версия 3» как исторический протокол. Рабочая группа IMAP использовала RFC 1176 (IMAP2), а не RFC 1203 (IMAP3) в качестве отправной точки

IMAP2bis

С появлением MIME IMAP2 был расширен для поддержки структур тела MIME и добавления функций управления почтовыми ящиками (создание, удаление, переименование, загрузка сообщений), которые отсутствовали в IMAP2. Эта экспериментальная версия называлась IMAP2bis; его спецификация никогда не публиковалась в виде черновика. Интернет-проект IMAP2bis был опубликован рабочей группой IETF IMAP в октябре 1993 года. Этот проект был основан на следующих более ранних спецификациях: неопубликованный IMAP2bis.TXT , документ RFC   1176 и RFC   1064 (IMAP2). Проект IMAP2bis.TXT документировал состояние расширений IMAP2 по состоянию на декабрь 1992 года. Ранние версии Pine были широко распространены с поддержкой IMAP2bis. (Pine 4.00 и более поздние версии поддерживают IMAP4rev1).

IMAP4

Рабочая группа IMAP, созданная в IETF в начале 1990-х годов, взяла на себя ответственность за разработку IMAP2bis. Рабочая группа IMAP решила переименовать IMAP2bis в IMAP4, чтобы избежать путаницы.

Преимущества перед POP

Подключенный и отключенный режимы

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

Отчетность о внешних изменениях

После успешной аутентификации протокол POP обеспечивает полностью статическое представление текущего состояния почтового ящика и не предоставляет механизма отображения каких-либо внешних изменений состояния во время сеанса. Напротив, протокол IMAP обеспечивает динамическое представление и требует, чтобы внешние изменения состояния, включая вновь поступившие сообщения, а также изменения, внесенные в почтовый ящик другими одновременно подключенными клиентами, обнаруживались, и между командами отправлялись соответствующие ответы, а также во время команды IDLE , как описано в РФК   2177 . См. также В разделе 5.2 RFC   3501 конкретно упоминается «одновременный доступ к одному и тому же почтовому ящику нескольких агентов».

Доступ к частям сообщения MIME и частичная выборка

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

Информация о состоянии сообщения

Благодаря использованию флагов, определенных в протоколе IMAP4, клиенты могут отслеживать состояние сообщения: например, было ли сообщение прочитано, на него ответили или было удалено. Эти флаги хранятся на сервере, поэтому разные клиенты, обращающиеся к одному и тому же почтовому ящику в разное время, могут обнаружить изменения состояния, внесенные другими клиентами. POP не предоставляет клиентам механизма для хранения такой информации о состоянии на сервере, поэтому, если один пользователь обращается к почтовому ящику с двумя разными клиентами POP (в разное время), информация о состоянии, например, был ли осуществлен доступ к сообщению, не может быть синхронизирована между клиенты. Протокол IMAP4 поддерживает как предопределенные системные флаги, так и ключевые слова, определенные клиентом. Системные флаги указывают информацию о состоянии, например, было ли прочитано сообщение. Ключевые слова, которые поддерживаются не всеми серверами IMAP, позволяют присваивать сообщениям один или несколько тегов , значение которых зависит от клиента. Ключевые слова IMAP не следует путать с собственными метками веб- служб электронной почты, которые иногда переводятся в папки IMAP соответствующими проприетарными серверами.

Несколько почтовых ящиков на сервере

Клиенты IMAP4 могут создавать, переименовывать и удалять почтовые ящики (обычно представленные пользователю в виде папок) на сервере, а также копировать сообщения между почтовыми ящиками. Поддержка нескольких почтовых ящиков также позволяет серверам предоставлять доступ к общим и общедоступным папкам. IMAP4 Расширение списка управления доступом (ACL) ( RFC   4314 ) может использоваться для регулирования прав доступа.

Поиск на стороне сервера

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

Встроенный механизм расширения.

Отражая опыт более ранних интернет-протоколов, IMAP4 определяет явный механизм, с помощью которого его можно расширить. Было предложено множество расширений базового протокола IMAP4, которые широко используются. У IMAP2bis не было механизма расширения, а у POP теперь есть механизм, определенный РФК   2449 .

Push-уведомления сервера

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

Недостатки

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

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

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

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

Клиентам IMAP4 необходимо поддерживать соединение TCP/IP с сервером IMAP, чтобы получать уведомления о прибытии новой почты. Уведомление о прибытии почты осуществляется посредством внутриполосной сигнализации , что в некоторой степени усложняет обработку протокола IMAP на стороне клиента. Частное предложение 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 путем копирования исходящего сообщения в выделенную папку «Исходящие».

Безопасность

Для криптографической защиты соединений IMAP между клиентом и сервером можно использовать IMAPS на TCP-порту 993, который использует SSL/TLS. По состоянию на январь 2018 года TLS является рекомендуемым механизмом.

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

Пример диалога

Это пример соединения IMAP, взятый из раздела 8 RFC 3501 :

C: <open connection>
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" "MIT.EDU")) NIL NIL
      "<[email protected]>")
      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] {342}
S:   Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:   From: Terry Gray <[email protected]>
S:   Subject: IMAP4rev1 WG mtg summary and minutes
S:   To: [email protected]
S:   Cc: [email protected], John Klensin <[email protected]>
S:   Message-Id: <[email protected]>
S:   MIME-Version: 1.0
S:   Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:   )
S:   a004 OK FETCH completed
C    a005 store 12 +flags \deleted
S:   * 12 FETCH (FLAGS (\Seen \Deleted))
S:   a005 OK +FLAGS completed
C:   a006 logout
S:   * BYE IMAP4rev1 server terminating connection
S:   a006 OK LOGOUT completed

См. также

• Список программного обеспечения почтового сервера
• Сравнение почтовых клиентов
• Сравнение почтовых серверов
• IMAP в режиме ожидания
• Протокол метаприложений JSON (JMAP)
• Протокол почтового отделения (POP)
• Push-IMAP
• Простой протокол доступа к почте
• Простой протокол передачи почты
• Веб-почта

Дальнейшее чтение

• Криспин, Марк (1988–2016). «Десять заповедей о том, как написать клиент IMAP» . Университет Вашингтона . Архивировано из оригинала 29 августа 2016 г. Проверено 2 ноября 2018 г.
• Хайнлайн, П; Хартлебен, П. (2008). Книга IMAP: Создание почтового сервера с помощью Courier и Cyrus . Нет крахмального пресса. ISBN  978-1-59327-177-0 .
• Хьюз, Л. (1998). Протоколы электронной почты Интернета, стандарты и реализация . Издательство «Артех Хаус». ISBN  0-89006-939-5 .
• Джонсон, К. (2000). Протоколы электронной почты Интернета: Руководство разработчика . Аддисон-Уэсли Профессионал. ISBN  0-201-43288-9 .
• Лошин, П (1999). «Основные стандарты электронной почты: RFC и протоколы стали практичными». Программирование Интернет-почты . О'Рейли. ISBN  1-56592-479-7 .

Внешние ссылки

• «Список рассылки протокола IMAP» .
• RFC   9051 — Спецификация IMAP версии 4, редакция 2
• RFC   2683 — предложения по реализации IMAP RFC
• RFC   2177 — команда IMAP4 IDLE