Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Электронные протоколы [ править ]

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

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

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

История [ править ]

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

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

Исходный IMAP [ править ]

Первоначальный промежуточный протокол доступа к почте был реализован как клиент машины Xerox Lisp и сервер 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 (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 требует, чтобы текущий подключенный клиент был единственным клиентом, подключенным к почтовому ящику. Напротив, протокол IMAP, в частности, разрешает одновременный доступ нескольким клиентам и предоставляет клиентам механизмы для обнаружения изменений, внесенных в почтовый ящик другими, одновременно подключенными, клиентами. См., Например, раздел 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 . 

Недостатки [ править ]

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

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

Unless the mail storage and searching algorithms on the server are carefully implemented, a client can potentially consume large amounts of server resources when searching massive mailboxes.

IMAP4 clients need to maintain a TCP/IP connection to the IMAP server in order to be notified of the arrival of new mail. Notification of mail arrival is done through in-band signaling, which contributes to the complexity of client-side IMAP protocol handling somewhat.[18] A private proposal, push IMAP, would extend IMAP to implement push e-mail by sending the entire message instead of just a notification. However, push IMAP has not been generally accepted and current IETF work has addressed the problem in other ways (see the Lemonade Profile for more information).

Unlike some proprietary protocols which combine sending and retrieval operations, sending a message and saving a copy in a server-side folder with a base-level IMAP client requires transmitting the message content twice, once to SMTP for delivery and a second time to IMAP to store in a sent mail folder. This is addressed by a set of extensions defined by the IETF Lemonade Profile for mobile devices: URLAUTH (RFC 4467) and CATENATE (RFC 4469) in IMAP, and BURL (RFC 4468) in SMTP-SUBMISSION. In addition to this, Courier Mail Server offers a non-standard method of sending using IMAP by copying an outgoing message to a dedicated outbox folder.[19]

Security[edit]

To cryptographically protect IMAP connections, IMAPS on TCP port 993 can be used, which utilizes SSL/TLS.[2][3] As of January 2018, TLS is the recommended mechanism.[20]

Alternatively, STARTTLS can be used to provide secure communications between the MUA communicating with the MSA or MTA implementing the SMTP Protocol.

Dialog example[edit]

This is an example IMAP connection as taken from RFC 3501 section 8:

C: <open connection>S: * OK IMAP4rev1 Service ReadyC: a001 login mrc secretS: a001 OK LOGIN completedC: a002 select inboxS: * 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 completedC: a003 fetch 12 fullS: * 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 completedC: 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 completedC a005 store 12 +flags \deletedS: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completedC: a006 logoutS: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed

See also[edit]

  • List of mail server software
  • Comparison of email clients
  • Comparison of mail servers
  • IMAP IDLE
  • JSON Meta Application Protocol (JMAP)
  • Post Office Protocol (POP)
  • Push-IMAP
  • Simple Mail Access Protocol
  • Simple Mail Transfer Protocol
  • Webmail

References[edit]

  1. ^ Dean, Tamara (2010). Network+ Guide to Networks. Delmar. p. 519. ISBN 978-1-42390245-4.
  2. ^ a b c Blum, Richard (December 15, 2002). Open Source E-mail Security. Sams Publishing. ISBN 9780672322372 – via Google Books.
  3. ^ a b c Garfinkel, Simson; Spafford, Gene; Schwartz, Alan (December 15, 2003). "Practical UNIX and Internet Security". "O'Reilly Media, Inc." – via Google Books.
  4. ^ Komarinski, Mark (2000). Red Hat Linux System Administration Handbook. Prentice Hall. p. 179.
  5. ^ For example, Microsoft's Outlook client uses MAPI, a Microsoft proprietary protocol, to communicate with a Microsoft Exchange Server. IBM's Notes client works in a similar fashion when communicating with a Domino server.
  6. ^ Mullet, Diana (2000). Managing IMAP. O'Reilly. p. 25. ISBN 0-596-00012-X.
  7. ^ Crispin, Mark (13 February 2012). "Re: [imap5] Designing a new replacement protocol for IMAP". imap5 (Mailing list). [email protected]. Retrieved 26 November 2014. Knowledge of the original IMAP (before IMAP2) exists primarily in my mind as all the original IMAP specifications and implementations were replaced with IMAP2.
  8. ^ Service Name and Transport Protocol Port Number Registry. Iana.org (2013-07-12). Retrieved on 2013-07-17.
  9. ^ a b "RFC 2061 - IMAP4 COMPATIBILITY WITH IMAP2BIS". IETF. 1996. Retrieved 2010-08-21.
  10. ^ "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3". IETF. 1991. Retrieved 2010-08-21.
  11. ^ "IMAP2, IMAP2bis, IMAP3, IMAP4, IMAP4rev1 (LAN Mail Protocols)". Retrieved 2010-08-21.
  12. ^ "IMAP Overview, History, Versions and Standards". Retrieved 2010-08-21.
  13. ^ "Protocol Action: Interactive Mail Access Protocol — Version 3 to Historic (IETF mail archive)". 1993. Retrieved 2010-08-21.
  14. ^ "Innosoft and POP/IMAP protocols? (mail archive)". 1993. Retrieved 2010-08-21.
  15. ^ "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis (Internet Draft)". IETF. 1993. Retrieved 2010-08-21.
  16. ^ "IMAP2BIS -- EXTENSIONS TO THE IMAP2 PROTOCOL (DRAFT)". 1992. Archived from the original on 2011-07-18. Retrieved 2010-08-21.
  17. ^ "IMAP implementation in Sup, an e-mail client written in Ruby". rubyforge.com. Archived from the original on 2007-12-12. Retrieved 2011-02-22.
  18. ^ "IMAP IDLE: The best approach for 'push' e-mail". Isode.com. Retrieved 2009-07-30.
  19. ^ "Courier-IMAP: Sending mail via an IMAP connection". Double Precision, Inc. Retrieved 2013-09-24.
  20. ^ RFC 8314. doi:10.17487/RFC8314.

Further reading[edit]

  • Crispin, Mark (1988–2016). "Ten Commandments of How to Write an IMAP client". University of Washington. Archived from the original on 2016-08-29. Retrieved 2018-11-02.
  • Heinlein, P; Hartleben, P (2008). The Book of IMAP: Building a Mail Server with Courier and Cyrus. No Starch Press. ISBN 978-1-59327-177-0.
  • Hughes, L (1998). Internet e-mail Protocols, Standards and Implementation. Artech House Publishers. ISBN 0-89006-939-5.
  • Johnson, K (2000). Internet E-mail Protocols: A Developer's Guide. Addison-Wesley Professional. ISBN 0-201-43288-9.
  • Loshin, P (1999). "Essential E-mail Standards: RFCs and Protocols Made Practical". Programming Internet Mail. O'Reilly. ISBN 1-56592-479-7.

External links[edit]

  • "IMAP Protocol Mailing List".
  • RFC 3501 — specification of IMAP version 4 revision 1
  • RFC 2683 — IMAP Implementation Suggestions RFC
  • RFC 2177 — IMAP4 IDLE command