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

редактировать
Интернет-протокол прикладного уровня для получения и хранения электронной почты

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

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

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

Содержание

  • 1 Протоколы электронной почты
  • 2 История
    • 2.1 Исходный IMAP
    • 2.2 IMAP2
    • 2.3 IMAP3
    • 2.4 IMAP2bis
    • 2.5 IMAP4
  • 3 Преимущества перед POP
    • 3.1 Режимы подключения и отключения
    • 3.2 Несколько одновременных клиентов
    • 3.3 Доступ к частям сообщения MIME и частичная выборка
    • 3.4 Информация о состоянии сообщения
    • 3.5 Несколько почтовых ящиков на сервере
    • 3.6 Поиск на стороне сервера
    • 3.7 Встроенный механизм расширения
  • 4 Недостатки
  • 5 Безопасность
  • 6 Пример диалога
  • 7 См. Также
  • 8 Ссылки
  • 9 Дополнительная литература
  • 10 Внешние ссылки

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

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

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

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

История

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

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

Исходный IMAP

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

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

IMAP2

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

IMAP3

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

IMAP2bis

С появлением MIME протокол IMAP2 был расширен для поддержки структур тела MIME и добавления функций управления почтовыми ящиками (создание, удаление, переименование, загрузка сообщений), которые отсутствовали в IMAP2. Эта экспериментальная версия получила название IMAP2bis; его спецификация никогда не публиковалась в не-черновой форме. Интернет-проект IMAP2bis был опубликован рабочей группой IETF IMAP в октябре 1993 года. Этот проект был основан на следующих более ранних спецификациях: неопубликованный документ IMAP2bis.TXT, RFC1176 и RFC1064 (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 специально разрешает одновременный доступ для нескольких клиентов и предоставляет клиентам механизмы для обнаружения изменений, внесенных в почтовый ящик другими, одновременно подключенными, клиентами. См., Например, раздел 5.2 RFC3501, в котором в качестве примера конкретно приводится «одновременный доступ к одному и тому же почтовому ящику несколькими агентами».

Доступ к частям сообщения 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 недействительными без каких-либо ограничений, что практически противоречит их назначению.

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

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

В отличие от некоторых проприетарных протоколов, которые объединяют операции отправки и получения, отправка сообщения и сохранение копии в папке на стороне сервера с клиентом 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, который использует TLS. Начиная с RFC 8314, это рекомендуемый механизм.

В качестве альтернативы, STARTTLS можно использовать для обеспечения безопасной связи между MUA, взаимодействующим с MSA или MTA, реализующими Протокол SMTP.

Пример диалогового окна

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

C: S: * OK IMAP4rev1 Service Ready C: a001 логин mrc secret S: a001 OK ВХОД завершен C: a002 выберите почтовый ящик S: * 18 СУЩЕСТВУЕТ S: * FLAGS (\ Ansaged \ Flagged \ Deleted \ Seen \ Draft) S: * 2 НЕДАВНИЕ S: * OK [UNSEEN 17] Сообщение 17 - первое невидимое сообщение S: * OK [UIDVALIDITY 3857529045] Действительные UID S: a002 OK [READ-WRITE] SELECT завершен C: a003 выборка 12 полных S: * 12 FETCH (FLAGS (\ Seen) INTERNALDATE "17-июл- 1996 02:44:25 -0700 "RFC822.SIZE 4286 ENVELOPE (" среда, 17 июля 1996 г. 02:23:25 -0700 (PDT) "" IMAP4rev1 WG mtg summary and minutes "((" Terry Gray "NIL" gray " "cac.washington.edu")) (("Терри Грей" NIL "серый" "cac.washington.edu")) (("Terry Gray" NIL "серый" "cac.washington.edu")) ((NIL NIL "imap" "cac.washington.edu")) ((NIL NIL "минуты" "CNRI.Reston.VA.US") ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL "") BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) S: a003 OK FETCH завершен C: a004 выборка 12 body [заголовок] S: * 12 FETCH (BODY [ ЗАГОЛОВОК] {342} S: Дата: среда, 17 июля 1996 г., 02:23:25 -0700 (PDT) S: От: Терри Грей S: Тема: IMAP4rev1 WG, сводка mtg и протоколы S: Кому: imap @ cac.washington.edu S: cc: [email#160;protected], John Klensin S: Идентификатор сообщения: S: Версия MIME: 1.0 S: Тип содержимого: TEXT / PLAIN; CHARSET = US-ASCII S: S:) S: a004 OK FETCH завершено C a005 сохранить 12 + флаги \ удалено S: * 12 FETCH (FLAGS (\ Seen \ Deleted)) S: a005 OK + FLAGS завершено C: a006 выйти из системы S : * BYE Сервер IMAP4rev1 завершает соединение S: a006 OK ВЫХОД завершен

См. Также

Ссылки

Дополнительная литература

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

Найдите IMAP в Викисловаре, бесплатном словаре.
Последняя правка сделана 2021-05-24 04:58:54
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте