IMAP

Модель TCP/IP (RFC 1122)
Прикладний рівень
BGP DHCP DNS FTP Gopher GTP HTTP HTTPS IMAP IRC LDAP MGCP MQTT NNTP NTP POP3 RIP RPC RTCP RTP RTSP SDP SIP SMTP SNMP SOAP SSH STUN Telnet TLS/SSL VNC XMPP докладніше
Транспортний рівень
TCP UDP DCCP SCTP RSVP ECN докладніше
Мережевий рівень
IP IPv4 IPv6 ICMP ICMPv6 IGMP IPsec докладніше
Канальний рівень
ARP RARP NDP MPLS OSPF Tunnels (L2TP) MAC-адреса Ethernet DSL ISDN FDDI Драйвер докладніше
Цей шаблон: переглянути обговорити редагувати

IMAP (англ. Internet Message Access Protocol — «Протокол доступу до інтернет-повідомлень») — мережевий протокол прикладного рівня для доступу до електронної пошти.

Аналогічно до POP3, служить для роботи з вхідними листами, однак забезпечує додаткові функції, зокрема, можливість пошуку за ключовим словом без збереження пошти в локальній пам'яті.

IMAP надає користувачеві великі можливості для роботи з поштовими скриньками, розташованими на центральному сервері. Поштовий клієнт, що використовує цей протокол, отримує доступ до сховища кореспонденції на сервер так, начебто ця кореспонденція розташована на комп'ютері одержувача. Електронними листами можна маніпулювати з комп'ютера користувача (клієнта) без постійного пересилання з сервера і назад файлів з повним змістом листів. Для відправки листів використовується протокол SMTP.

IMAP був розроблений для заміни простішого протоколу POP3 і має такі переваги в порівнянні з останнім:

• Листи зберігаються на сервері, а не на машині клієнта. Можливий доступ до одної і тої ж поштової скриньки з різних клієнтів. Підтримується також одночасний доступ декількох клієнтів. У протоколі є механізми, за допомогою яких клієнт може бути проінформований про зміни, зроблені іншими клієнтами.
• Підтримка декількох поштових скриньок (або тек). Клієнт може створювати, вилучати і перейменовувати поштові скриньки на сервері, а також переміщати листи з одної поштової скриньки в інші.
• Можливе створення спільних папок, до яких можуть мати доступ декілька користувачів.
• Інформація про стан листів зберігається на сервері і доступна всім клієнтам. Листи можуть бути позначені як прочитані, важливі тощо
• Підтримка пошуку на сервері. Немає необхідності завантажувати з сервера безліч повідомлень для того, щоб знайти одне потрібне.
• Підтримка онлайн-роботи. Клієнт може підтримувати з сервером постійне з'єднання, при цьому сервер у реальному часі інформує клієнта про зміни в поштових скриньках, у тому числі про нові листи.
• Передбачено механізм розширення можливостей протоколу.

Поточна версія протоколу має позначення IMAP4rev1 (IMAP, версія 4, ревізія 1). Протокол підтримує передачу пароля користувача в зашифрованому вигляді. Крім того, IMAP-трафік можна зашифрувати за допомогою SSL.

• отримані листи зберігаються на сервері
• надіслані повідомлення зберігаються на сервері
• повідомлення можна синхронізувати та отримати доступ до них на кількох пристроях^[1]

• електронні листи зберігаються на одному пристрої
• надіслані повідомлення зберігаються на одному пристрої
• до листів можна отримати доступ лише з одного пристрою
• щоб зберігати повідомлення на сервері, необхідно увімкнути параметр «Зберігати електронну пошту на сервері», інакше всі повідомлення буде видалені з сервера після завантаження їх додатком^[2].

• Original IMAP (1986, специфікація відсутня)
• IMAP2 (1988 — RFC 1064, 1990 — RFC 1176)
• IMAP3 (1991, RFC 1203)
• IMAP2bis (специфікація існує тільки в чорновому варіанті 1993 року)
• IMAP4 (перейменований IMAP2bis, 1994 — RFC 1730)
• IMAP4rev1 (1996 — RFC 2060, 2003 — RFC 3501)

IMAP працює тільки з повідомленнями і не вимагає яких-небудь пакетів зі спеціальними заголовками. Кожне повідомлення має кілька пов'язаних із ним атрибутів. Ці атрибути можуть бути визначені індивідуально або спільно з іншими атрибутами.

Кожному повідомленню ставиться у відповідність 32-бітовий код, який при використанні спільно з унікальним ідентифікатором утворює 64-бітову послідовність, яка гарантуватиме однозначну ідентифікацію повідомлення в поштовій скриньці. Чим пізніше повідомлення прийшло, тим більше його UID.

UID асоціюється з поштовою скринькою і надсилається у вигляді коду uidvalidity відгуку (ok) на фазі вибору поштової скриньки. Якщо UID з попередньої сесії з якоїсь причини не може бути використаний, UID повинен бути інкременторований.

UID повідомлення не повинно змінюватися в межах сесії, його не слід змінювати і від сесії до сесії. Однак якщо неможливо зберегти UID повідомлення в подальшій сесії, кожна наступна сесія повинна мати новий унікальний код ідентифікатора, який повинен бути більше, ніж будь який UID, використаний раніше.

Порядковий номер повідомлення в поштовій скриньці починається з 1. Кожне повідомлення, починаючи з другого, має порядковий номер рівно на 1 більше, ніж попереднє йому.   Протягом сесії допустимо зміна порядкового номера повідомлення. Наприклад, коли повідомлення буде видалене з поштової скриньки, номери усіх наступних повідомлень змінюються.

Цей атрибут являє собою список з нуля або більше іменованих лексем, співвіднесених з даним повідомленням. Прапор встановлюється шляхом його додавання до цього списку і обнуляється шляхом його видалення. В IMAP 4.1 існує два типи прапорів. Прапор може бути постійним або чинним лише на час даної сесії.

Системним прапором є прапор, ім'я якого визначено в специфікації протоколу. Всі системні прапори починаються з символу \ .

В даний час визначені наступні системні прапори:

• \Seen — повідомлення прочитане
• \Answered — на повідомлення відправлена відповідь
• \Flagged — повідомлення відзначене як «важливе»
• \Deleted — повідомлення відзначене як вилучене
• \Draft — повідомлення відзначене як чернетку
• \Recent — нещодавнє повідомлення (вперше з'явилося в ящику в ході поточної сесії)

Дата і час повідомлення залежать від специфіки його доставки:

• Протокол SMTP — час доставки кінцевому адресату.
• Команда копіювання — внутрішній час відправника.
• Команда append — час, заданий параметрами команди.

• Розмір повідомлення — число октетів у повідомленні.
• Структура конверта повідомлення.
• Структура тіла повідомлення.

З'єднання IMAP 4.1 на увазі встановлення зв'язку між клієнтом і сервером. Клієнт посилає серверу команди, сервер клієнтові — дані та повідомлення про статус виконання запиту. Всі повідомлення, як клієнта, так і сервера мають форму рядків, що завершуються спеціальною послідовністю.

Будь-яка процедура починається з команди клієнта. Будь-яка команда клієнта починається з префікса-ідентифікатора (зазвичай короткий літерно-цифровий рядок, наприклад, A0001, A0002 тощо), званого міткою (tag). Для кожної команди клієнт генерує свою мітку.

Можливі два випадки, коли рядок, відправлений клієнтом, не є закінченою командою. У першому — аргумент команди забезпечується кодом, що визначає число октетів в рядку. У другому — аргументи команди вимагають відгуку з боку сервера. В обох випадках сервер посилає запит продовження команди, що починається з символу +.

Клієнт повинен завершити відправку однієї команди, перш ніж відправити іншу.

Протокольний приймач сервера читає рядок команди, що прийшла від клієнта, здійснює її розбір, виділяє параметри і передає серверу дані. По завершенні команди сервер посилає відгук.

Дані, що передаються сервером клієнтові, а також статусні відгуки, які не вказують на завершення виконання команди, мають префікс * і називаються Непоміченими відгуками.

Дані можуть бути відправлені сервером у відповідь на команду клієнта або за власною ініціативою. Формат даних не залежить від причини відправки.

Відгук вказує на вдале / невдале виконання операції. Він використовує ту ж мітку, що і команда клієнта, запустивши процедуру. Таким чином, якщо здійснюється більш ніж одна команда, мітка сервера вказує на команду, яка викликала даний відгук. Є три види відгуку завершення сервера: ok (успішне виконання), no (невдача), bad (протокольна помилка, наприклад, не розпізнана команда або зафіксована синтаксична помилка).

Протокольний приймач клієнта IMAP 4.1 читає рядок відгуку від сервера і вживає дії згідно з першим символом * або + .

Клієнт повинен бути готовий прийняти будь-який відгук сервера в будь-який час. Дані сервера повинні бути записані так, щоб клієнт міг їх безпосередньо використовувати, не посилаючи серверу уточнюючих запитів.

IMAP протокол за замовчуванням працює через порт 143 TCP. IMAP через SSL/TLS (IMAPS) працює через 993 порт TCP.

Сервер IMAP 4.1 знаходиться в одному з чотирьох станів.

Більшість команд можна використовувати лише в певних станах.

У стані без аутентифікації клієнт повинен надати ім'я і пароль, перш ніж йому стане доступна більшість команд. Перехід в цей стан виробляється при встановленні з'єднання без попередньої аутентифікації.

У стані аутентифікації клієнт ідентифікований і повинен вибрати поштову скриньку, після чого йому стануть доступні команди для роботи з повідомленнями. Перехід в цей стан відбувається при встановленні з'єднання з попередньою аутентифікацією, коли видані всі необхідні ідентифікаційні дані або при помилковому виборі поштової скриньки.

У стан вибору система потрапляє, коли успішно здійснений вибір поштової скриньки.

У стан виходу система потрапляє при перериванні з'єднання в результаті запиту клієнта або внаслідок незалежного рішення сервера.

1. З'єднання без попередньої аутентифікації
2. З'єднання з попередньою аутентифікацією
3. З'єднання відкинуто
4. Успішне завершення команди LOGIN або AUTHENTICATE
5. Успішне завершення команди SELECT або EXAMINE
6. Виконання команди CLOSE або невдала команда SELECT або EXAMINE
7. Виконання команди LOGOUT, закриття сервера, або переривання з'єднання

LOGIN

Дозволяє клієнту при реєстрації на сервері IMAP використовувати ідентифікатор користувача та пароль у звичайному текстовому вигляді. Це не найкращий метод, але іноді це єдина можливість підключитися до сервера.

AUTHENTICATE

Дозволяє клієнту використовувати при реєстрації на сервері IMAP альтернативні методи перевірки автентичності. Індивідуальна перевірка справжності користувачів не є обов'язковою і підтримується не всіма серверами IMAP. До того ж реалізації такої перевірки можуть розрізнятися залежно від сервера. Коли клієнт видає команду AUTHENTICATE, сервер відповідає на неї рядком виклику в кодуванні base64. Далі клієнт повинен відправити відповідь на виклик сервера про перевірку справжності, також закодований base64. Якщо на сервері не підтримується метод перевірки автентичності, запропонований клієнтом, він включає в свою відповідь слово NO. Після цього клієнт повинен продовжити переговори з узгодження методу перевірки автентичності. Якщо всі спроби визначити метод перевірки автентичності зазнали невдачі, то клієнт робить спробу зареєструватися на сервері допомогою команди LOGIN.

CLOSE

Закриває поштову скриньку. Коли поштова скринька закритий, то всі повідомлення, помічені прапором \DELETED, фізично видаляються з нього. Не має параметрів.

LOGOUT

Завершує сеанс для поточного ідентифікатора користувача і закриває всі відкриті поштові скриньки. Якщо які-небудь повідомлення були помічені прапором \deleted, то за допомогою цієї команди вони будуть фізично видалені з поштової скриньки.

CREATE

Створює новий поштову скриньку. Ім'я та місце розташування нових поштових скриньок визначаються відповідно до загальних специфікаціями сервера.

DELETE

Застосовується до поштових скриньок. Сервер IMAP при отриманні цієї команди спробує видалити поштову скриньку з ім'ям, зазначеним як аргумент команди. Повідомлення видаляються разом з ящиками і відновленню не підлягають.

RENAME

Змінює ім'я поштової скриньки. Ця команда має два параметри — ім'я поштової скриньки, який потрібно перейменувати, і нове ім'я поштової скриньки.

SUBSCRIBE

Додає поштову скриньку в список активних ящиків клієнта. В цей команді використовується тільки один параметр — ім'я поштової скриньки, який потрібно внести в список. Поштова скринька не обов'язково повинен існувати, щоб його можна було додати до списку активних ящиків — це дозволяє додавати в список активних ящиків ящики, які ще не створені, або видаляти їх, якщо вони порожні.

UNSUBSCRIBE

Видаляє поштові скриньки зі списку активних. У ній так само використовується один параметр — ім'я поштової скриньки, який видаляється зі списку активних ящиків клієнта. При цьому сам по собі поштову скриньку не видаляється.

LIST

Отримати список всіх поштових скриньок клієнта; має два параметри.

LSUB

На відміну від команди LIST використовується для отримання списку ящиків, активізованих командою SUBSCRIBE . Параметри — такі ж, як у LIST.

STATUS

Формує запит про поточний стан поштової скриньки. Першим параметром для цієї команди є ім'я поштової скриньки, до якого вона застосовується. Другий параметр — це список критеріїв, за якими клієнт хоче отримати інформацію. Команда STATUS може використовуватися для отримання інформації про стан поштової скриньки без його відкриття за допомогою команд SELECT або EXAMINE.

Користувач може одержати інформацію за критеріями:

* MESSAGES — загальне число повідомлень в поштовій скриньці

* RECENT — число повідомлень з прапором \recent

* UIDNEXT — ідентифікатор UID, який буде призначений новим повідомленням

* UIDVALIDITY — унікальний ідентифікатор поштової скриньки

* UNSEEN — число повідомлень без прапора \seen

APPEND

Додає повідомлення в кінець вказаного поштової скриньки. Як аргументи указуються ім'я ящика, прапори повідомлення (не обов'язково), мітка часу (не обов'язково) і саме повідомлення — заголовок і тіло.

Є наступні прапори повідомлень:

* \Seen — прочитано

* \Answered — написана відповідь

* \Flagged — термінове

* \Deleted — позначено для видалення

* \Draft — чернетка

* \Recent — нове повідомлення, воно надійшло у поштову скриньку після закінчення минулого сеансу: Якщо в команді вказані прапори, то вони встановлюються для доданого повідомлення. У будь-якому випадку для повідомлення встановлюється прапор \Recent.

Якщо в команді задана мітка часу, то цей час буде встановлено як час створення повідомлення, в іншому випадку за час створення береться поточний час.

Оскільки повідомлення складається не з одного рядка, використовуються літерали.

Приклад:

C A003 APPEND saved-messages (\ Seen) {247}
S + Ready for literal data
C Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C From: Fred Foobar <foobar@Blurdybloop.COM>
C Subject: afternoon meeting
C To: mooch@owatagu.siam.edu
C Message-Id: <B27397-0100000@Blurdybloop.COM>
C
C Hello Joe, do you think we can meet at 3:30 tomorrow?
S A003 OK APPEND completed

Розширення MULTIAPPEND, описане в RFC 3502, дозволяє однією командою додавати в поштову скриньку кілька повідомлень.

CHECK

Встановлює контрольну точку в поштовій скриньці. Будь-які операції, такі, наприклад, як запис даних з пам'яті сервера на його жорсткий диск, повинні виконуватися при відповідному стані поштової скриньки. Саме для перевірки цілісності поштової скриньки після дискових та інших подібних їм операцій і застосовується команда CHECK. Ця команда використовується без параметрів.

EXPUNGE

Видаляє з поштової скриньки всі повідомлення, помічені прапором \DELETED, при цьому поштова скринька не закривається. Відповідь сервера на команду EXPUNGE являє собою звіт про новий стан поштової скриньки.

 

SEARCH

Пошук повідомлень за критеріями в активному поштовій скриньці з подальшим відображенням результатів у вигляді номера повідомлення.

Можливий пошук повідомлень, в тілі яких є певна текстовий рядок, або мають певний прапор, або отриманих до певної дати і т. д.

FETCH

Отримати текст поштового повідомлення. Команда застосовується тільки для відображення повідомлень. На відміну від POP3, клієнт IMAP не зберігає копію повідомлення на клієнтському ПК.

STORE

Змінює інформацію про повідомлення.

COPY

Копіює повідомлення з однієї поштової скриньки в інший.

UID

Використовується в зв'язці з командами FETCH, COPY, STORE або SEARCH. З її допомогою в цих командах можна використовувати реальні ідентифікаційні номери UID замість послідовності чисел з діапазону номерів повідомлень.

CAPABILITY

Запит у сервера IMAP інформацію про його можливості.

NOOP

Команда нічого не робить. Вона може застосовуватися для підтримки активності під час сеансу для того, щоб сеанс не припинився по таймеру інтервалу очікування. Відповідь сервера на команду NOOP завжди повинен бути позитивним. Так як сервер часто у відповіді повертає стан виконання тієї чи іншої команди, то NOOP цілком можна використовувати як тригер для періодичного запиту про стан сервера.

• RFC 3501 Internet Message Access Protocol v4rev1 (англ.)
• The IMAP Connection(англ.) (Вашингтонський університет, штат Вашингтон, США)
• Howto: Configuring KMail with Gmail — IMAP and Disconnected IMAP[Архівовано 4 червня 2011 у Wayback Machine.](англ.)
• Network ports for clients and mail flow in Exchange

Ця стаття потребує додаткових посилань на джерела для поліпшення її перевірності. Будь ласка, допоможіть удосконалити цю статтю, додавши посилання на надійні (авторитетні) джерела. Зверніться на сторінку обговорення за поясненнями та допоможіть виправити недоліки. Матеріал без джерел може бути піддано сумніву та вилучено. (вересень 2015)

Це незавершена стаття про Інтернет. Ви можете допомогти проєкту, виправивши або дописавши її.