IMAP англ Internet Message Access Protocol Протокол доступу до інтернет повідомлень мережевий протокол прикладного рівня

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

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

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

Переваги в порівнянні з POP3

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

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

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

Відмінності між POP3 та IMAP

IMAP

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

POP3

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

Версії протоколу IMAP

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

UID

Кожному повідомленню ставиться у відповідність 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

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

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

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

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

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

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

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

Команди протоколу IMAP

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 цілком можна використовувати як тригер для періодичного запиту про стан сервера.

Примітки

. Mailbird. 24 липня 2020. Архів оригіналу за 24 вересня 2020. Процитовано 4 серпня 2020.
. https://help.aol.com/ (амер.). Архів оригіналу за 26 вересня 2020. Процитовано 4 серпня 2020.

Посилання

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

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

[1] . Mailbird. 24 липня 2020. Архів оригіналу за 24 вересня 2020. Процитовано 4 серпня 2020.

[2] . https://help.aol.com/ (амер.). Архів оригіналу за 26 вересня 2020. Процитовано 4 серпня 2020.