Протокол доступа к сообщениям в Интернете
набор интернет-протоколов
Уровень приложений
Transport layer
Internet layer
Link layer

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

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

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

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

Internet Message Access Protocol — это интернет-протокол прикладного уровня , который позволяет почтовому клиенту получать доступ к электронной почте на удаленном почтовом сервере . Текущая версия определена RFC  9051. Сервер IMAP обычно прослушивает известный порт 143, тогда как IMAP через SSL/TLS (IMAPS) использует 993. [2] [3]

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

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

История

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

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

Оригинальный IMAP-протокол

Первоначальный протокол Interim Mail Access Protocol был реализован как клиент Xerox Lisp Machine и сервер TOPS-20 .

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

IMAP2

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

IMAP3

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

IMAP2bis

С появлением 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).

IMAP4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Серверные push-уведомления

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

Недостатки

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

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

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

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

Клиентам IMAP4 необходимо поддерживать соединение TCP/IP с сервером IMAP, чтобы получать уведомления о прибытии новой почты. Уведомление о прибытии почты осуществляется посредством внутриполосной сигнализации , что несколько усложняет обработку протокола IMAP на стороне клиента. [18] Частное предложение push IMAP расширило бы IMAP для реализации push-email путем отправки всего сообщения вместо одного уведомления. Однако push IMAP не был общепринятым, и текущая работа IETF решает эту проблему другими способами (см. Lemonade Profile для получения дополнительной информации).

В отличие от некоторых фирменных протоколов, которые объединяют операции отправки и извлечения, отправка сообщения и сохранение копии в папке на стороне сервера с помощью клиента IMAP базового уровня требует передачи содержимого сообщения дважды, один раз на SMTP для доставки и второй раз на IMAP для сохранения в папке отправленной почты. Это решается набором расширений, определенных профилем IETF Lemonade для мобильных устройств: 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: * OK IMAP4rev1 Service ReadyC: a001 логин mrc секретS: a001 OK ВХОД завершёнC: a002 выберите входящиеС: * 18 СУЩЕСТВУЕТS: * ФЛАГИ (\Отвечено \Помечено \Удалено \Просмотрено \Черновик)С: * 2 ПОСЛЕДНИЕС: * ОК [НЕ ПРОСМОТРЕННОЕ 17] Сообщение 17 — первое невидимое сообщение.S: * OK [UIDVALIDITY 3857529045] UID действительныS: a002 OK [ЧТЕНИЕ-ЗАПИСЬ] ВЫБОР завершенC: a003 получить 12 полныйS: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" RFC822.SIZE 4286 КОНВЕРТ ("Ср, 17 июля 1996 02:23:25 -0700 (PDT)" «IMAP4rev1 WG mtg summary и протоколы» (("Терри Грей" NIL "gray" "cac.washington.edu")) (("Терри Грей" NIL "gray" "cac.washington.edu")) (("Терри Грей" NIL "gray" "cac.washington.edu")) ((НОЛЬ НИЛ "imap" "cac.washington.edu")) ((НОЛЬ НОЛЬ "минуты" "CNRI.Reston.VA.US") («Джон Кленсин» НОЛЬ «КЛЕНСИН» «MIT.EDU»)) НОЛЬ НОЛЬ «<B27397-0100000@cac.washington.edu>») ТЕЛО ("ТЕКСТ" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))S: a003 OK FETCH завершенC: a004 выборка 12 тело[заголовок]S: * 12 ВЫБОРКА (ТЕЛО[ЗАГОЛОВОК] {342}С:
С:
С:
С:
С: С:
С:
С:
С: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)From: Terry Gray <gray@cac.washington.edu>Subject: IMAP4rev1 WG mtg summary and minutesTo: imap@cac.washington.eduCc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>Message-Id: <B27397-0100000@cac.washington.edu>MIME-Version: 1.0Content-Type: TEXT/PLAIN; CHARSET=US-ASCIIС:С: )S: a004 OK FETCH завершенC a005 сохранить 12 +флаги \удаленоS: * 12 FETCH (ФЛАГИ (\Просмотрено \Удалено))S: a005 OK +ФЛАГИ завершеныC: a006 выход из системыS: * BYE IMAP4rev1 сервер завершает соединениеS: a006 OK ВЫХОД ЗАВЕРШЕН

Смотрите также

Ссылки

  1. ^ Дин, Тамара (2010). Network+ Guide to Networks. Delmar. стр. 519. ISBN 978-1-42390245-4. Архивировано из оригинала 2021-02-05 . Получено 2020-12-25 .
  2. ^ abc Blum, Richard (15 декабря 2002 г.). Безопасность электронной почты с открытым исходным кодом. Sams Publishing. ISBN 9780672322372. Архивировано из оригинала 5 февраля 2021 г. . Получено 25 декабря 2020 г. – через Google Books.
  3. ^ abc Гарфинкель, Симсон; Спаффорд, Джин; Шварц, Алан (15 декабря 2003 г.). Практические рекомендации по UNIX и безопасности в Интернете. "O'Reilly Media, Inc.". ISBN 9780596003234. Архивировано из оригинала 5 февраля 2021 г. . Получено 25 декабря 2020 г. – через Google Books.
  4. ^ Комарински, Марк (2000). Справочник по системному администрированию Red Hat Linux . Prentice Hall. стр. 179.
  5. ^ Например, клиент Outlook от Microsoft использует MAPI , собственный протокол Microsoft , для связи с сервером Microsoft Exchange . Клиент Notes от IBM работает аналогичным образом при связи с сервером Domino .
  6. ^ Маллет, Диана (2000). Управление IMAP . O'Reilly . стр. 25. ISBN 0-596-00012-X.
  7. ^ Криспин, Марк (13 февраля 2012 г.). "Re: [imap5] Разработка нового протокола замены для IMAP". imap5 (список рассылки). alpine.OSX.2.00.1202131243200.38441@hsinghsing.panda.com. Архивировано из оригинала 24 сентября 2015 г. Получено 26 ноября 2014 г. Знание оригинального IMAP (до IMAP2) существует в основном в моем сознании, поскольку все оригинальные спецификации и реализации IMAP были заменены на IMAP2.
  8. ^ Реестр имен служб и номеров портов транспортных протоколов. Архивировано 18 апреля 2010 г. на Wayback Machine . Iana.org (12 июля 2013 г.). Получено 17 июля 2013 г.
  9. ^ ab "RFC 2061 – Совместимость IMAP4 с IMAP2BIS". IETF. 1996. Архивировано из оригинала 2011-06-23 . Получено 2010-08-21 .
  10. ^ "Interactive Mail Access Protocol – Version 3". IETF. 1991. Архивировано из оригинала 2010-03-04 . Получено 2010-08-21 .
  11. ^ "IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (протоколы локальной почты)". Архивировано из оригинала 2010-06-15 . Получено 2010-08-21 .
  12. ^ "Обзор, история, версии и стандарты IMAP". Архивировано из оригинала 29-11-2010 . Получено 21-08-2010 .
  13. ^ «Действие протокола: протокол интерактивного доступа к почте — версия 3 до исторической (архив почты IETF)». 1993. Архивировано из оригинала 2012-08-11 . Получено 2010-08-21 .
  14. ^ "Innosoft и протоколы POP/IMAP? (архив почты)". 1993. Архивировано из оригинала 2011-07-15 . Получено 2010-08-21 .
  15. ^ "Interactive Mail Access Protocol – Version 2bis (internet draft)". IETF. 1993. Архивировано из оригинала 2012-10-08 . Получено 2010-08-21 .
  16. ^ "IMAP2BIS – Расширения протокола IMAP2 (черновик)". 1992. Архивировано из оригинала 2011-07-18 . Получено 2010-08-21 .
  17. ^ "Реализация IMAP в Sup, почтовом клиенте, написанном на Ruby". rubyforge.com. Архивировано из оригинала 2007-12-12 . Получено 2011-02-22 .
  18. ^ "IMAP IDLE: Лучший подход для 'push' электронной почты". Isode.com. Архивировано из оригинала 2009-02-28 . Получено 2009-07-30 .
  19. ^ "Courier-IMAP: Отправка почты через соединение IMAP". Double Precision, Inc. Архивировано из оригинала 2013-09-27 . Получено 2013-09-24 .
  20. ^ RFC 8314. doi : 10.17487/RFC8314 .

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

  • Криспин, Марк (1988–2016). «Десять заповедей о том, как написать клиент IMAP». Вашингтонский университет . Архивировано из оригинала 29-08-2016 . Получено 02-11-2018 .
  • Хайнлайн, П.; Хартлебен, П. (2008). Книга IMAP: Создание почтового сервера с помощью Courier и Cyrus . No Starch Press. ISBN 978-1-59327-177-0.
  • Хьюз, Л. (1998). Протоколы электронной почты Интернета, стандарты и реализация . Artech House Publishers. ISBN 0-89006-939-5.
  • Джонсон, К. (2000). Протоколы электронной почты Интернета: Руководство разработчика . Addison-Wesley Professional. ISBN 0-201-43288-9.
  • Лошин, П. (1999). "Основные стандарты электронной почты: RFC и протоколы, реализованные на практике". Программирование интернет-почты . O'Reilly. ISBN 1-56592-479-7.
Найдите информацию об IMAP в Викисловаре, бесплатном словаре.
  • «Список рассылки протокола IMAP».[ постоянная мертвая ссылка ‍ ]
  • RFC  9051 — Спецификация IMAP версии 4, редакция 2
  • RFC  2683 — Предложения по реализации IMAP RFC
  • RFC  2177 — команда IMAP4 IDLE
Retrieved from "https://en.wikipedia.org/w/index.php?title=Internet_Message_Access_Protocol&oldid=1264169375#IMAP4"