протокол imap4

протокол IMAP4

Протокол IМАР4 (Internet Message Access Protocol, Version 4, Протокол доступу до електронної пошти Internet, версія 4) дозволяє клієнтам отримувати Доступ і маніпулювати повідомленнями електронної пошти на сервері.

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

Принципи роботи

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

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

Якщо сервер використовує таймер контролю часу з'єднання, він повинен бути встановлений не менше ніж на 30-хвилинний проміжок "неактивності" клієнта, т. Е. Якщо сервер протягом 30 хвилин отримує хоча б одну команду, таймер скидається.

Весь обмін даними між клієнтом і сервером організований у вигляді рядків, що завершуються символами , або у вигляді послідовності байт заданої довжини. Кожна команда клієнта починається з ідентифікатора або тега команди. Тег, як правило, являє собою коротку рядок, що складається з букв і цифр, (наприклад, А0001, А0002 та т. Д.). Тег є унікальним ідентифікатором даної команди клієнта. Відповіді сервера або такі команди клієнта можуть посилатися на дану команду по її тегу.

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

Рядки даних, що передаються з сервера у відповідь на команду клієнта, можуть не містити тег, а містити символ "*". Це означає, що вони є

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

Якщо сервер виявив помилку в команді, він відправляє повідомлення BAD клієнту з тегом неправильної команди. Якщо команда успішно оброблена - повертається повідомлення ОК з тегом команди. Якщо команда повернула негативний результат, наприклад, в разі неможливості виконати дану команду - повертається повідомлення NO з тегом невиконаною команди.

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

Для роботи в такому режимі, клієнт і сервер повинні фіксувати весь потік даних обміну, оскільки як сервер так і клієнт в своїх запитах і відповідях можуть посилатися на команди і дані, введені на попередніх стадіях сесії обміну.

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

Атрибути повідомлень системи IMAP

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

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

Крім унікального ідентифікатора, повідомлення в системі IMAP має порядковий номер, т. Е. Все повідомлення в даному поштовому ящику послідовно нумеруються. Якщо в поштову скриньку додається нове повідомлення, йому присвоюється номер на 1 більше кількості повідомленні в поштовій скриньці. При видаленні будь-якого повідомлення з даної папки порядкові номери всіх повідомлень перераховуються, тому порядковий номер повідомлення може змінюватися під час сесії. Більшість команд IMAP4 працюють з порядковими номерами повідомлень, а не з UID.

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

"\ Recent" - повідомлення "тільки що" надійшло в поштову скриньку, т. Е. Дана сесія - перша, яка може прочитати це повідомлення.

"\ Recent" - приклад прапора, який не збережеться в наступній сесії

Основні команди

IMAP4 - гнучкий і багатофункціональний протокол з широкими можливостями. Він обслуговує понад 20 різних команд клієнта з управління станом своєї пошти. Детальний опис всіх команд і відповідей IМАР4-сервера ви можете знайти, в RFC-2060. Далі будуть описані лише деякі з клієнтських команд, і на прикладах їх обробки показана загальна схема взаємодії клієнта і сервера IMAP4.

IMAP4 підтримує текстові команди і відповіді сервера, т. Е. ASCII-послідовності символів. Рядок команди або даних завершується послідовністю . 8-бітові дані, відповідно до специфікації MIME, не можуть передаватися у IMAP4 в "відкритому" вигляді. Як правило, реалізації IMAP4 перед передачею двійкових даних кодують їх base64.

Так само як і РОРЗ-сервер, 1МАР4-сервер обробляє команди в залежності від одного з чотирьох станів, в якому він знаходиться:

  1. Стан поза аутентифікації, в якому клієнт повинен для початку роботи зареєструватися в сервері.
  2. Стан аутентифікації, в якому клієнт може вибрати для роботи папку з повідомленнями.
  3. Стан роботи з поштовою текою, в якому клієнт здійснює основну роботу з повідомленнями.
  4. Стан від'єднання, в якому сервер завершує транзакцію роботи клієнта.

Далі при описі команд, символом "S:" буде позначатися потік даних від сервера IMAP4, а символом "С:" - потік даних від клієнта.

Команда LOGIN. Після того як з транспортного протоколу (наприклад, TCP), було встановлено з'єднання, і від сервера прийшла рядок привітання, клієнт повинен зареєструватися в системі. Для цього найчастіше використовується команда LOGIN. Аргументом команди є рядок з ідентифікатором і паролем клієнта:

S: * OK IMAP4revl Service Ready

З: aOOl login ali sesaro

S: aOOl OK LOGIN completed

Команда LOGIN передає пароль і ідентифікатор користувача по мережі у відкритому вигляді. Якщо користувачеві необхідний захист інформації своєї пошти, він може користуватися командою AUTHENTICATE. Аргументом команди є рядок, яка вказує механізм аутентифікації, яким бажає скористатися даний користувач. Залежно від обраного типу аутентифікації будується подальший обмін між сервером і клієнтом. Наприклад, при використанні механізму шифрування KERBEROS, аутентифікація виглядає наступним чином:

S: * OK KerberosV4 IMAP4revl Server

З: AOOl AUTHENTICATE KERBEROS_V4

S: AOOl OK Kerberos V4 authentication successful