• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Набір команд і формат повідомлень протоколу ІМАР

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

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

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

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

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

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

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

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

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

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

Розглянемо можливі стани сервера (див. рисунок 10.1):

(1) З'єднання без попередньої аутентифікації;

Рисунок 10.1 – Стани сервера IMAP

(2) З'єднання з попередньою аутентифікацією;

(3) З'єднання відкинуто;

(4) Успішне завершення команди LOGIN або AUTHENTICATE;

(5) Успішне завершення команди SELECT або EXAMINE;

(6) Виконання команди CLOSE або невдала команда SELECT або EXAMINE;

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

Читайте також:

1. III.4 Форматування тексту.
2. Автотрансформатори
3. Автотрансформатори
4. Адміністративно-командна система, її ознаки та механізм функціонування.
5. АРХІВОЗНАВЧІ АСПЕКТИ ІНФОРМАТИЗАЦІЇ
6. Безрозмірною характеристикою гідротрансформатора називається залежність коефіцієнтів пропорційності моментів насосного і турбінного коліс від його передаточного відношення.
7. Будова трансформаторів
8. Введення команд
9. Введення, редагування і форматування даних
10. Вербування, набір, найом, прийом
11. Вертикальний формат балансу
12. Вибір кількості і потужності цехових трансформаторів з врахуванням компенсації реактивної потужності.

Переглядів: 1414