IMAP: відмінності між версіями
| [неперевірена версія] | [неперевірена версія] |
Вилучено вміст Додано вміст
Vagobot (обговорення | внесок) м r2.7.2) (робот додав: sr:IMAP |
Немає опису редагування |
||
Рядок 19:
Поточна версія протоколу має позначення IMAP4rev1 (IMAP, версія 4, ревізія 1). Протокол підтримує передачу пароля користувача в зашифрованому вигляді. Крім того, IMAP-трафік можна зашифрувати за допомогою [[SSL]].
== Версії протоколу IMAP ==
* Original IMAP (1986, специфікація відсутня)
* IMAP2 (1988 - RFC 1064, 1990 - RFC 1176)
* IMAP3 (1991, RFC 1203)
* IMAP2bis (специфікація існує тільки в чорновому варіанті 1993 року)
* IMAP4 (перейменований IMAP2bis)
== Повідомлення та їх атрибути ==
IMAP працює тільки з повідомленнями і не вимагає яких-небудь пакетів зі спеціальними заголовками.
Кожне повідомлення має кілька пов'язаних із ним атрибутів. Ці атрибути можуть бути визначені індивідуально або спільно з іншими атрибутами.
=== UID ===
Кожному повідомленню ставиться у відповідність 32-бітовий код, який при використанні спільно з унікальним ідентифікатором утворює 64-бітову послідовність, яка гарантуватиме однозначну ідентифікацію повідомлення в поштовій скриньці. Чим пізніше повідомлення прийшло, тим більше його UID.
UID асоціюється з поштовою скринькою і надсилається у вигляді коду uidvalidity відгуку (ok) на фазі вибору поштової скриньки. Якщо UID з попередньої сесії з якоїсь причини не може бути використаний, UID повинен бути інкрементірован.
UID повідомлення не повинно змінюватися в межах сесії, його не слід змінювати і від сесії до сесії. Однак якщо неможливо зберегти UID повідомлення в подальшій сесії, кожна наступна сесія повинна мати новий унікальний код ідентифікатора, який повинен бути більше, ніж будь UID, використаний раніше.
=== Порядковий номер повідомлення ===
Порядковий номер повідомлення в поштовій скриньці починається з 1. Кожне повідомлення, починаючи з другого, має порядковий номер рівно на 1 більше, ніж попереднє йому.
Протягом сесії допустимо зміна порядкового номера повідомлення. Наприклад, коли повідомлення буде видалене з поштової скриньки, номери усіх наступних повідомлень змінюються.
=== Прапори повідомлення ===
Цей атрибут являє собою список з нуля або більше іменованих лексем, співвіднесених з даним повідомленням. Прапор встановлюється шляхом його додавання до цього списку і обнуляється шляхом його видалення. В IMAP 4.1 існує два типи прапорів. Прапор може бути постійним або чинним лише на час даної сесії.
Системним прапором є прапор, ім'я якого визначено в специфікації протоколу. Всі системні прапори починаються з символу <code> \ </ code>.
В даний час визначені наступні системні прапори:
* <code> \ Seen </ code> - повідомлення прочитане
* <code> \ Answered </ code> - на повідомлення відправлений відповідь
* <code> \ Flagged </ code> - повідомлення відзначене як «важливе»
* <code> \ Deleted </ code> - повідомлення відзначене як вилучене
* <code> \ Draft </ code> - повідомлення відзначене як чернетку
* <code> \ Recent </ code> - нещодавнє повідомлення (вперше з'явилося в ящику в ході поточної сесії)
=== Внутрішні дата і час повідомлення на сервері ===
Час і дата отримання повідомлення. У разі доставки повідомлення за допомогою протоколу SMTP - дата та час доставки кінцевому адресату. Для повідомлень, доставлених командою копіювання - внутрішня дата і час відправника повідомлення. При використанні команди <code> append </ code> - дата та час, задані параметрами команди.
=== Інші атрибути ===
* Розмір повідомлення - число октетів в повідомленні.
* Структура конверта повідомлення.
* Структура тіла повідомлення
== '''Взаємодія клієнта і сервера''' ==
З'єднання IMAP 4.1 на увазі встановлення зв'язку між клієнтом і сервером. Клієнт посилає серверу команди, сервер клієнтові - дані та повідомлення про статус виконання запиту. Всі повідомлення, як клієнта, так і сервера мають форму рядків, що завершуються спеціальною послідовністю.
Будь-яка процедура починається з команди клієнта. Будь-яка команда клієнта починається з префікса-ідентифікатора (зазвичай коротка буквено-цифрова рядок, наприклад, <code> A0001 </ code>, <code> A0002 </ code> і т. д.), званого міткою (tag). Для кожної команди клієнт генерує свою мітку.
Можливі два випадки, коли рядок, відправлена клієнтом, не є закінченою команду. У першому - аргумент команди забезпечується кодом, що визначає число октетів в рядку. У другому - аргументи команди вимагають відгуку з боку сервера. В обох випадках сервер посилає запит продовження команди, що починається з символу <code> + </ code>.
Клієнт повинен завершити відправку однієї команди, перш ніж відправити іншу.
Протокольний приймач сервера читає рядок команди, що прийшла від клієнта, здійснює її розбір, виділяє параметри і передає серверу дані. По завершенні команди сервер посилає відгук.
Дані, що передаються сервером клієнтові, а також статусні відгуки, які не вказують на завершення виконання команди, мають префікс <code> * </ code> і називаються Непомічені відгуками.
Дані можуть бути відправлені сервером у відповідь на команду клієнта або за власною ініціативою. Формат даних не залежить від причини відправки.
Відгук вказує на вдале / невдале виконання операції. Він використовує ту ж мітку, що і команда клієнта, запустивши процедуру. Таким чином, якщо здійснюється більш ніж одна команда, мітка сервера вказує на команду, яка викликала даний відгук. Є три види відгуку завершення сервера: <code> ok </ code> (успішне виконання), <code> no </ code> (невдача), <code> bad </ code> (протокольна помилка, наприклад, не пізнана команда або зафіксована синтаксична помилка).
Протокольний приймач клієнта IMAP 4.1 читає рядок відгуку від сервера і вживає дії у відповідності з першим символом <code> * </ code> або <code> + </ code>.
Клієнт повинен бути готовий прийняти будь відгук сервера в будь-який час. Дані сервера повинні бути записані так, щоб клієнт міг їх безпосередньо використовувати, не посилаючи сервера уточнюючих запитів.
== Стани сервера IMAP ==
Сервер IMAP 4.1 знаходиться в одному з чотирьох станів.
Більшість команд можна використовувати лише в певних станах.
У стані'' без аутентифікації'' клієнт повинен надати ім'я і пароль, перш ніж йому стане доступна більшість команд. Перехід в цей стан виробляється при встановленні з'єднання без попередньої аутентифікації.
У стані'' аутентифікації'' клієнт ідентифікований і повинен вибрати поштову скриньку, після чого йому стануть доступні команди для роботи з повідомленнями. Перехід в цей стан відбувається при встановленні з'єднання з попередньою аутентифікацією, коли видані всі необхідні ідентифікаційні дані або при помилковому виборі поштової скриньки.
У стан'' вибору'' система потрапляє, коли успішно здійснений вибір поштової скриньки.
У стан'' виходу'' система потрапляє при перериванні з'єднання в результаті запиту клієнта або внаслідок незалежного рішення сервера.
[[File:Imap modes.jpg]]
* (1) З'єднання без попередньої аутентифікації
* (2) З'єднання з попередньою аутентифікацією
* (3) З'єднання відкинуто
* (4) Успішне завершення команди <code> LOGIN </ code> або <code> AUTHENTICATE </ code>
* (5) Успішне завершення команди <code> SELECT </ code> або <code> EXAMINE </ code>
* (6) Виконання команди <code> CLOSE </ code> або невдала команда <code> SELECT </ code> або <code> EXAMINE </ code>
* (7) Виконання команди <code> LOGOUT </ code>, закриття сервера, або переривання з'єднання
== Команди протоколу IMAP ==
; LOGIN: Дозволяє клієнту при реєстрації на сервері IMAP використовувати ідентифікатор користувача та пароль у звичайному текстовому вигляді. Це не найкращий метод, але іноді це єдина можливість підключитися до сервера.
; AUTHENTICATE: Дозволяє клієнту використовувати при реєстрації на сервері IMAP альтернативні методи перевірки автентичності. Індивідуальна перевірка справжності користувачів не є обов'язковою і підтримується не всіма серверами IMAP. До того ж реалізації такої перевірки можуть розрізнятися залежно від сервера. Коли клієнт видає команду <code> AUTHENTICATE </ code>, сервер відповідає на неї рядком виклику в кодуванні [[base64]]. Далі клієнт повинен відправити відповідь на виклик сервера про перевірку справжності, також закодований base64. Якщо на сервері не підтримується метод перевірки автентичності, запропонований клієнтом, він включає в свою відповідь слово <code> NO </ code>. Після цього клієнт повинен продовжити переговори з узгодження методу перевірки автентичності. Якщо всі спроби визначити метод перевірки автентичності зазнали невдачі, то клієнт робить спробу зареєструватися на сервері допомогою команди <code> LOGIN </ code>.
; CLOSE: Закриває поштову скриньку. Коли поштова скринька закритий, то всі повідомлення, помічені прапором <code> \ DELETED </ code>, фізично видаляються з нього. Не має параметрів.
; LOGOUT: Завершує сеанс для поточного ідентифікатора користувача і закриває всі відкриті поштові скриньки. Якщо які-небудь повідомлення були помічені прапором <code> \ deleted </ code>, то за допомогою цієї команди вони будуть фізично видалені з поштової скриньки.
; CREATE: Створює новий поштову скриньку. Ім'я та місце розташування нових поштових скриньок визначаються відповідно до загальних специфікаціями сервера.
; DELETE: Застосовується до поштових скриньок. Сервер IMAP при отриманні цієї команди спробує видалити поштову скриньку з ім'ям, зазначеним в якості аргументу команди. Повідомлення видаляються разом з ящиками і відновленню не підлягають.
; RENAME: Змінює ім'я поштової скриньки. Ця команда має два параметри - ім'я поштової скриньки, який потрібно перейменувати, і нове ім'я поштової скриньки.
; SUBSCRIBE: Додає поштову скриньку в список активних ящиків клієнта. В цей команді використовується тільки один параметр - ім'я поштової скриньки, який потрібно внести в список. Поштова скринька не обов'язково повинен існувати, щоб його можна було додати до списку активних ящиків - це дозволяє додавати в список активних ящиків ящики, які ще не створені, або видаляти їх, якщо вони порожні.
; UNSUBSCRIBE: Видаляє поштові скриньки зі списку активних. У ній так само використовується один параметр - ім'я поштової скриньки, який видаляється зі списку активних ящиків клієнта. При цьому сам по собі поштову скриньку не видаляється.
; LIST: Отримати список всіх поштових скриньок клієнта; має два параметри.
; LSUB: На відміну від команди <code> LIST </ code> використовується для отримання списку ящиків, активізованих командою <code> SUBSCRIBE </ code>. Параметри - такі ж, як у <code> LIST </ code>.
; STATUS: Формує запит про поточний стан поштової скриньки. Першим параметром для цієї команди є ім'я поштової скриньки, до якого вона застосовується. Другий параметр - це список критеріїв, за якими клієнт хоче отримати інформацію. Команда <code> STATUS </ code> може використовуватися для отримання інформації про стан поштової скриньки без його відкриття за допомогою команд <code> SELECT </ code> або <code> EXAMINE </ code>.
: Користувач може одержати інформацію за критеріями:
: * <code> MESSAGES </ code> - загальне число повідомлень в поштовій скриньці
: * <code> RECENT </ code> - число повідомлень з прапором <code> \ recent </ code>
: * <code> UIDNEXT </ code> - ідентифікатор UID, який буде призначений новим повідомленням
: * <code> UIDVALIDITY </ code> - унікальний ідентифікатор поштової скриньки
: * <code> UNSEEN </ code> - число повідомлень без прапора <code> \ seen </ code>
; APPEND: Додає повідомлення в кінець вказаного поштової скриньки. В якості аргументів указуються ім'я ящика, прапори повідомлення (не обов'язково), мітка часу (не обов'язково) і саме повідомлення - заголовок і тіло.
: Є наступні прапори повідомлень:
: * <code> \ Seen </ code> - прочитано
: * <code> \ Answered </ code> - написана відповідь
: * <code> \ Flagged </ code> - термінове
: * <code> \ Deleted </ code> - позначено для видалення
: * <code> \ Draft </ code> - чернетка
: * <code> \ Recent </ code> - нове повідомлення, воно надійшло у поштову скриньку після закінчення минулого сеансу
: Якщо в команді вказані прапори, то вони встановлюються для доданого повідомлення. У будь-якому випадку для повідомлення встановлюється прапор <code> \ Recent </ code>.
: Якщо в команді задана мітка часу, то цей час буде встановлено в якості часу створення повідомлення, в іншому випадку за час створення приймається поточний час.
: Оскільки повідомлення складається не з одного рядка, використовуються літерали.
: Приклад:
<pre>
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
</pre>
: Розширення <code> MULTIAPPEND </ code>, описане в RFC 3502, дозволяє однією командою додавати в поштову скриньку кілька повідомлень.
; CHECK: Встановлює контрольну точку в поштовій скриньці. Будь-які операції, такі, наприклад, як запис даних з пам'яті сервера на його жорсткий диск, повинні виконуватися при відповідному стані поштової скриньки. Саме для перевірки цілісності поштової скриньки після дискових та інших подібних їм операцій і застосовується команда <code> CHECK </ code>. Ця команда використовується без параметрів.
; EXPUNGE: Видаляє з поштової скриньки всі повідомлення, помічені прапором <code> \ DELETED </ code>, при цьому поштова скринька не закривається. Відповідь сервера на команду <code> EXPUNGE </ code> представляє собою звіт про новий стан поштової скриньки.
; SEARCH: Пошук повідомлень за критеріями в активному поштовій скриньці з подальшим відображенням результатів у вигляді номера повідомлення.
: Можливий пошук повідомлень, в тілі яких є певна текстовий рядок, або мають певний прапор, або отриманих до певної дати і т. д.
; FETCH: Отримати текст поштового повідомлення. Команда застосовується тільки для відображення повідомлень. На відміну від POP3, клієнт IMAP не зберігає копію повідомлення на клієнтському ПК.
; STORE: Змінює інформацію про повідомлення.
; COPY: Копіює повідомлення з однієї поштової скриньки в інший.
; UID: Використовується в зв'язці з командами <code> FETCH </ code>, <code> COPY </ code>, <code> STORE </ code> або <code> SEARCH </ code>. З її допомогою в цих командах можна використовувати реальні ідентифікаційні номери UID замість послідовності чисел з діапазону номерів повідомлень.
; CAPABILITY: Запит у сервера IMAP інформацію про його можливості.
; NOOP: Команда нічого не робить. Вона може застосовуватися для підтримки активності під час сеансу для того, щоб сеанс не припинився по таймеру інтервалу очікування. Відповідь сервера на команду <code> NOOP </ code> завжди повинен бути позитивним. Так як сервер часто у відповіді повертає стан виконання тієї чи іншої команди, то <code> NOOP </ code> цілком можна використовувати як тригер для періодичного запиту про стан сервера.
== '''Посилання''' ==
* RFC 3501 Internet Message Access Protocol v4rev1 {{ref-en}}
* [http://imap.org/ The IMAP Connection]{{ref-en}} ([[Вашингтонський університет]], [[штат Вашингтон]], [[США]])
| |||