ЕЛЕКТРОННА ПОШТА. ФОРМАТ ПОВІДОМЛЕННЯ. ПРОТОКОЛ SMTP. ПРОТОКОЛ POP3. ПРОТОКОЛ IMAP

 

ЕЛЕКТРОННА ПОШТА. ФОРМАТ ПОВІДОМЛЕННЯ. ПРОТОКОЛ SMTP. ПРОТОКОЛ POP3. ПРОТОКОЛ IMAP

 

1. Електронна пошта

2 Формат повідомлення

3 Протокол SMTP

4 Протокол POP3

5. Протокол IMAP

 

1 Електронна пошта

 

Служба електронна пошта - призначена для обміну повідомленнями (листами).

Клієнт (MS Outlook, The bat ...) готує ("упаковує") і посилає серверу (поштове відділення) повідомлення, приймає і проглядає повідомлення.

Сервер електронної пошти (Sendmail, MS Exchange ...) обробляє повідомлення

(сортує) і відправляє локальному адресатові або віддаленому серверу (поштовому відділенню).

Електронна пошта багато в чому схожа на звичайну поштову службу.

 

 

Рис.1. Відправлення і отримання пошти

 

Основні протоколи:

•      SMTP (Simple Mail Transfer Protocol) - простий протокол передачі пошти,

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

•      POP3 (Post Office Protocol Version 3) -  протокол поштового відділення, (версія 3) використовується поштовим клієнтом для отримання повідомлень електронної пошти з сервера. Зазвичай використовується в парі з протоколом SMTP.

•        IMAP(Internet Message Access Protocol) - «протокол доступу до електронної пошти Інтернету») - протокол прикладного рівня для доступу до електронної пошти.

•      UUCP (Unix-Unix-CoPy) - використовується для відправки і прийому пошти, як клієнтом на сервер, так і сервером на інший сервер. Зараз майже не використовується, тому розглядати не будемо.

 

2. Формат повідомлення

 

Перший стандарт - RFC0724 (Proposed official standard for the format of ARPA Network messages D. Crocker, K.T. Pogran, J. Vittal, D.A. Henderson May-12-1977).

Остання версія -  RFC2822 (Internet Message Format P. Resnick, Ed. April 2001).

Текстова (ASCII) інформація може передаватися, як є.

Решта інформації повинна бути закодована, оскільки спочатку не передбачалося її передавати. При використанні розширення протоколу SMTP - ESMTP (Enhaced SMTP) можна кодувати в 8-бітовому вигляді. Це все виконує поштова програма.

Види кодування:

base64 - ко дує з набору 00-FF в ASCII, щоб можна було передавати по SMTP (кодують бінарні файли).

7bit - не кодує, указує, що код ASCII.

8bit - указує, що не тільки символи ASCII.

quoted-printable - використовується для кодування національних мов, символів другої частини таблиці ("А" - "=3D").

Повідомлення складається з:

•      конверта повідомлення (інформація для доставки і обробки повідомлення)

•        тіла повідомлення (дані відправника)

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

 

Приклади повідомлень:

 

From: <vasy@list.ua> // адреса відправника

To: <pety@kfti.knc.ua// адреса одержувача

Subject: З новим роком! // тема повідомлення

Mime-Version: 1.0      // ініціалізація Mime

X-Mailer: mPOP Web-Mail 2.19   // тип і версія поштової програми клієнта

Date: Fri, 19 Sep 2003 08:37:43 +0400  //  дата відправки повідомлення

Reply-To: <vasy@list.ru> // адреса для відповіді

Content-Type: text/plain; charset=koi8-r  // тип і підтип MIME

Content-Transfer-Encoding: 8bit  // ідентифікатор типу кодування

Message-Id: <E1A0D1b-000AnC-00.vasy-list-ru@f15.mail.ru> // унікальний ідентифікатор повідомлення

 

З новим роком, Петре!                               //Тіло повідомлення

 

Лістинг 1. Приклад простого повідомлення

 

2.1.Деякі поля заголовка:

 

From - адреси відправників.

Sender - адреса реального відправника.

Приклад: From: vasy@mail.ru pety@mail.ru

Sender: misha@mail.ru

To - адреса одержувача.

Cc - адреси одержувачів копій повідомлень.

Приклад:

To: vasy@mail.ru pety@mail.ru

Cc: misha@mail.ru, katy@mail.ru

Date - дата відправки повідомлення.

Subject - тема повідомлення.

MESSAGE-ID - унікальний ідентифікатор повідомлення.

Reply-To - адреса для відповіді.

Received - адреси і час обробки повідомлення проміжним сервером.

X-Mailer - тип і версія поштової програми клієнта.

Comments - коментарі.

Priority - пріоритетність.

Organization - назва організації відправника

MIME-Version - поле для ідентифікації стандарту MIME, означає лист використовує MIME.

Content-Type - тип і підтип MIME (text/html,audio/midi).

Content-Transfer-Encoding - ідентифікатор типу кодування (base64, quoted-printable, 7bit, 8bit, binary і так далі).

base64 - ко дує з набору 00-FF в ASCII, щоб можна було передавати по SMTP (кодують бінарні файли).

7bit - не кодує, указує що код ASCII.

8bit - указує, що не тільки символи ASCII.

quoted-printable - використовується для кодування національних мов, символів другої частини таблиці ("А" - "=3D").

 

3 Протокол SMTP

Перший стандарт - RFC0788 (Simple Mail Transfer Protocol J. Postel Nov-01- 1981).

Остання версія - RFC2821 (Simple Mail Transfer Protocol J. Klensin, Ed. April 2001).

Simple Mail Transfer Protocol - протокол високого рівня, використовується для відправки пошти, як клієнтом на сервер, так і сервером на інший сервер.

Порт за умовчанням - 25.

Основний недолік протоколу, це відсутність аутентифікації і "докачки" (як в FTP, HTTP) повідомлень, тобто якщо ви посилаєте великий лист (10Мбайт), то у разі розриву з'єднання ваше повідомлення доведеться передавати наново, і можливо так до безконечності. Тому великі листи необхідно різати на частини.

SMTP використовується для відправки пошти від користувачів до серверів і між серверами для подальшої пересилки до одержувача. Для прийому пошти поштовий клієнт повинен використовувати протоколи POP3 або IMAP.

Щоб доставити повідомлення до адресата, необхідно переслати його поштовому серверу домена, в якому знаходиться адресат. Для цього зазвичай використовується запис типу MX (англ. Mail exchange - обмін поштою) системи DNS. Якщо MX запис відсутній, то для тих  же цілей може бути використана запис типу A. Деякі сучасні реалізації SMTP-серверів (наприклад, Exim) для визначення сервера, обслуговуючого пошту до імені адресата, також можуть додавати SRV-запис (RFC 2782).

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

Sendmail був одним з перших (якщо не першим) агентом відправки повідомлень, який почав працювати з SMTP. В даний час протокол SMTP є стандартним для електронної пошти і його використовують всі клієнти і сервери.

Протокол був розроблений для передачі тільки тексту в кодуванні ASCII, крім того, перші специфікації вимагали обнулення старшого біта кожного передаваного байта. Це не дає можливості посилати текст на національних мовах (наприклад, кирилиці), а також відправляти двійкові файли (такі як зображення, відеофайли, програми або архіви). Для зняття цього обмеження був розроблений стандарт MIME, який описує спосіб перетворення двійкових файлів в текстові. В даний час більшість серверів підтримують 8BITMIME, що дозволяє відправляти двійкові файли так само просто, як текст.

ESMTP - розширений протокол, на відміну від SMTP. При встановленні з'єднання сервер оголошує про набір підтримуваних розширень (як відповідь на команду EHLO). Відповідні розширення можуть бути використані клієнтом при роботі. Необхідно пам'ятати, що якщо сесія починається з команди HELO (використовуваною в «класичному» SMTP, RFC 821), то список розширень виводитися не буде.

 

3.1 Модель протоколу

 

Події роботи SMTP протоколу:

•        Клієнт ініціює з'єднання з сервером

•        Клієнт посилає запити на обслуговування

•        Сервер відповідає на ці запити

 

Рис. 3.1. Модель протоколу SMTP

 

3.2 Послідовність команд SMTP

 

Протокол SMTP обумовлює послідовність SMTP-команд

Розглянемо приклад:

Якийсь Vasy абонент сервера kstu.ru, посилає листи трьом абонентам сервера kazan.ru (Pety, Koly, Dima) один лист.

Розглянемо лістинг передачі сервера kstu.ru серверу kazan.ru:

R - сервер (receive)

S - клієнт (send)

 

R 220 lviv.ua Simple Mail Transfer Service Ready // код відповіді 220 (з’єднання встановлено), сервер kstu.ru, протокол SMTP

S HELO kstu.ru  // Зєднання встановлено, "Я kstu.ru", ідентифікація здійснюється по kstu.ru

R 250 lviv.ua  // команда прийнята й оброблнна, ідентифікація пройшла

S MAIL FROM: <Vasy@kstu.ru> // Початок поштової транзакції, обратный адрес

Vasy@kstu.ru.

R 250 OK  // Сервер згідний прийняти листа від Vasy@kstu.ru

S RCPT TO:<Petro@lviv.ua > // Кому відправити листа, Petro@lviv.ua

R 250 OK  //  Сервер згідний прийняти лист для Petro@lviv.ua

S RCPT TO:<Koly@kazan.ru> // Ще кому відіслати лист, Koly@kazan.ru

R 550 No such user here  // Сервер видає помилку 550, повідомляє, що такого користувача немає

S DATA   //  Запит на передачу даних

R 354 Start mail input; end with <CRLF>.<CRLF> // Дозволяє передачу даних, останній рядок повинен містити "крапку"

S From: <vasy@list.ru>      //Текст повідомлення (включаючи заголовок)...

S To: <pety@kfti.knc.ru>

S Subject: С новим роком!

S Mime-Version: 1.0

S X-Mailer: mPOP Web-Mail 2.19

S Date: Fri, 19 Sep 2003 08:37:43 +0400

S Reply-To: <vasy@list.ru>

S Content-Type: text/plain; charset=koi8-r

S Content-Transfer-Encoding: 8bit

S Message-Id: <E1A0D1b-000AnC-00.vasy-list-ru@f15.mail.ru> S

S С новым роком Петя!

S .                     // Кінець повідомлення, клієнт відправив крапку

R 250 OK  // Сервер отримав дані

S QUIT  // Клієнт посилає запит на завершення з’єднання

R 221 kazan.ru Service closing transmission channel // Сервер завершує з’єднання

 

Лістинг 6. Передача сервера kstu.ru серверу kazan.ru

 

3.3 Деякі команди SMTP

 

Обов'язкові команди (команди які повинні бути присутніми завжди)

HELO - Відкриття сеансу зв'язку (hello).

MAIL - Починає поштову транзакцію, яка завершується передачею даних в один або декілька поштових скриньок (mail).

RCPT - Ідентифікує одержувача поштового повідомлення (recipient).

Необов’язкові команди

DATA - Рядки, наступні за цією командою, розглядаються одержувачем як дані поштового повідомлення. У разі SMTP, поштове повідомлення закінчується комбінацією символів: CRLF-крапка-CRLF.

RSET - Перериває поточну поштову транзакцію (reset).

NOOP - Вимагає від одержувача не робити ніяких дій, а тільки видати відповідь ОК. Використовується головним чином для тестування.(No operation).

QUIT - Закриття сеансу зв'язку.

VRFY - Вимагає від приймача підтвердити, що її аргумент є дійсним ім'ям користувача.

SEND - Починає поштову транзакцію, що доставляє дані на один або декілька терміналів (не в поштову скриньку).

SOML - Починає транзакцію MAIL або SEND, що доставляє дані на один або декілька терміналів або в поштові скриньки.

SAML - Починає транзакцію MAIL і SEND, що доставляють дані на один або декілька терміналів і в поштові скриньки.

EXPN - Команда SMTP-серверу підтвердити, чи дійсно аргумент є адресою поштової розсилки і якщо так, повернути адресу одержувача повідомлення (expand).

HELP - Команда SMTP-серверу повернути повідомлення-довідку про його команди.

TURN - Команда SMTP-серверу або сказати ОК і помінятися ролями, тобто стати STMP- передавачем, або послати повідомлення-відмову і залишитися в ролі SMTP-сервера.

 

3.4 Синтаксис деяких команд SMTP

 

Команди, MAIL, SEND, SOML і SAML, мають однаковий синтаксис: MAIL <пропуск> FROM:<reverse-path> <carriage-return line-feed>

де:

<reverse path> (зворотна адреса) вказує серверу, кому у разі помилки відіслати повідомлення.

<carriage-return line-feed> (CRLF) повернення каретки.

Примітка: Команди SEND, SOML і SAML додаткові і використовуються досить рідко.

 

Синтаксис RCPT схожий на синтаксис команди MAIL: RCPT <пропуск> TO:<forward-path> <CRLF>

Проте, на відміну від MAIL, аргумент RCPT починається із слова <ТЕ:>.

 

3.5 Деякі коди відповідей SMTP

Сервер SMTP - це кінцевий автомат з внутрішнім станом. Клієнт передає на сервер рядок команда<пробіл>параметри<перехід рядка>. Сервер відповідає на кожну команду рядком, що містить код відповіді і текстове повідомлення, відокремлене пропуском. Кожна цифра в коді відповіді має певний сенс. Код відповіді - число від 100 до 999, представлене у вигляді рядка, що трактується таким чином:

2хх - команда успішно виконана

3xx - очікуються додаткові дані від клієнта

4хх  -  тимчасова помилка, клієнт повинен провести наступну спробу через деякий час

5хх - неусувна помилка

Текстова частина відповіді носить довідковий характер і призначена для людини, а не програми.

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

211 Відповідь про стан системи або допомога

214 Повідомлення-підказка (допомога)

220 <ім’я_домена> служба готова до роботи

221 <ім’я_домена> служба закриває канал зв'язку

250 Оголошена дія поштової транзакції успішно завершилася

251 Даний адресат не є місцевим; повідомлення буде передано по маршруту <forward- path>

354 Починай передачу повідомлення. Повідомлення закінчується комбінацією CRLF-крапка-CRLF

421 <ім’я_домена> служба недоступна; з'єднання закривається

450 Оголошена команда поштової транзакції не виконана, оскільки поштова скринька недоступна

451 Оголошену команду не виконано; відбулася локальна помилка при обробці повідомлення

452 Оголошена команда не виконана; системі не вистачило ресурсів

500 Синтаксична помилка в тексті команди; команда не розпізнана

501 Синтаксична помилка в аргументах або параметрах команди

502 Дана команда не реалізована

503 Невірна послідовність команд

504 У даної команди не може бути аргументів

550 Оголошена команда не виконана, оскільки поштова скринька недоступна

551 Даний адресат не є місцевим; спробуйте передати повідомлення по маршруту <forward-path>

552 Оголошена команда поштової транзакції перервана; дисковий простір, доступний системі, переповнився

553 Оголошена команда не виконана; вказано неприпустиме ім'я поштової скриньки

554 Транзакція не виконана

 

3.6 Ретрансляція повідомлень

Можна використовувати проміжні сервера для доставки пошти одержувачу.

Приклад: передамо повідомлення від Vasyl@knu.ua через хости @knu.ua, @mail.ua одержувачеві Mykola@lviv.ua

Механізм ретрансляції:

 

•        повідомлення передається хосту @knu.ua

S MAIL FROM:<Vasyl@knu.ua>

S RCPT TO:<@knu.ua, @mail.ua, Mykola@lviv.ua>

•        повідомлення передається хосту @mail.ua

S MAIL FROM:<@knu.ua>

S RCPT TO:<@mail.ua, Mykola@lviv.ua>

•        повідомлення передається хосту lviv.ua

S MAIL FROM:<@mail.ua>

S RCPT TO:<Mykola@lviv.ua>

При цьому параметри To, From і Cc залишаються без змін.

 

3.7 Резервні поштові сервери (relay)

 

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

 

Рис. 3.2. Схема роботи резервних поштових серверів

 

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

 

4 Протокол POP3

 

Post Office Protocol (POP) - протокол доставки пошти користувачеві з його поштової скриньки поштового сервера РОР. Коли пошта прийшла на сервер (по SMTP), вона розкладається по поштових скриньках. Щоб забрати пошту із скриньки потрібний POP.

Перший стандарт РОРЗ визначений в RFC 1225 (Post Office Protocol-Version 3, J. Myers, M. Rose November 1994).

Остання версія  RFC1939 (J. Myers, M. Rose May 1996 )

Порт за замовчанням - 110.

Користувач може дістати доступ до РОР-серверу з будь-якої точки доступу до Інтернет.

 



4.1 Модель протоколу POP3

Рис. 4.1. Модель протоколу POP

 

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

У протоколі РОР3 обумовлено три стадії процесу отримання пошти:

•        авторизація

•        транзакція

•        оновлення (завершення транзакції)

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

Відповідь сервера може мати два значення:

+OK - позитивна відповідь

-ERR – негативний результат

Якщо сервер містить декілька рядків, то останній  рядок повинен  містити

"крапку".

Позначення: "C" - клієнт "S" - сервер

 

4.2.1 Авторизація користувача

 

Команди авторизації:

USER - ім'я користувача, воно є і ідентифікатором поштової скриньки.

PASS - пароль користувача

APOP - авторизація цифровим підписом (використовується рідко).

 

Приклад авторизації:

 

C: USER Pety // Користувач повідомляє своє ім’я, воно є ідентифікатором поштової скриньки

S: +ОК  // Сервер повідомляє, що все в порядку

C: PASS Petypasw // Користувач повідомляє свій пароль

S: +ОК Pety's maildrop has 2 messages (320 octets) // Сервер повідомляє, в поштовому ящику Pety є 2 листи

 

Приклад невдалої авторизації:

 

C: USER Pety

S: -ERR sorry, no mailbox for Pety here

 

Приклад авторизації з цифровим підписом:

 

C: APOP Pety K3u7yG4TfR7gE55DD4ry6G4F // Ім’я та шифрований пароль

S: +ОК Pety's maildrop has 2 messages (320 octets)

 

4.2.2 Транзакції РОРЗ

 

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

 

Команда STAT (переглядання скриньки) повертає кількість повідомлень і загальну кількість байтів в повідомленнях:

 

C: STAT

S: +ОК 2 320 // 2 повідомлення, загальний розмір 320 байт

 

Команда LIST (без параметра) повертає список повідомлень в поштовій скриньці і їх розміри:

 

C: LIST

S: +ОК 2 messages (320 octets)

S: 1 120   // 1 лист, розмір 120 байт

S: 2 200  // 2 лист, роммір 200 байтS: .

 

Команда LIST з параметром (номер повідомлення) повертає інформацію про задане повідомлення:

 

C: LIST 2

S: +ОК 2 200 ...

C: LIST 3 // запит неіснуючого повідомлення

S: -ERR no such message, only 2 messages in maildrop // лист 3 відсутній

 

Команда TOP повертає заголовок, порожній рядок і перші n рядків тіла повідомлення:

 

C: TOP 1 10

S: +ОК

S: С новым годом

S:

S: <Десять рядків листа>

S: .

 

Команда NOOP - перевірка з'єднання:

 

C: NOOP

S: +ОК

 

Команда RETR витягує повідомлення з вказаним номером і поміщає його в буфер:

 

C: RETR 1

S: +OK 120 octets

S: <the POPS server sends the entire message here> // РОРЗ-сервер висилає лист повністю

S: .  // "крапка" – кінець повідомлення

 

Команда DELE відзначає повідомлення, яке потрібно видалити:

 

C: DELE 1

S: +OK message 1 deleted // повідомлення 1 видалене

C: DELE 2

S: -ERR message 2 already deleted // повідомлення 2 вже видалене

 

Команда RSET знімає мітки видалення зі всіх відмічених раніше повідомлень:

 

C: RSET

S: +OK maildrop has 2 messages (320 octets)  // в поточній скринці 2 повідомлення були відзначені на видалення.

 

Команда QUIT - перехід в режим оновлення (UPDATE):

 

C: QUIT

S: +OK dewey POP3 server signing off

 

Слід звернути увагу на те, що відмічені для видалення повідомлення насправді не видаляються до тих пір, поки не введена команда QUIT і не почалася стадія оновлення. У будь-який момент протягом сеансу клієнт має можливість видати команду RSET, і всі відмічені для видалення повідомлення будуть відновлені.

 

4.2.3 Оновлення (UPDATE)

Відбувається завершення транзакції. І видалення все помічених повідомлень.

 

5. Протокол IMAP

 

Протокол IMAP4 (Internet Message Access Protocol) дозволяє клієнтам діставати доступ і маніпулювати повідомленнями електронної пошти на сервері. Був розроблений для заміни POP3.

Порт за замовчанням - 143.

У відмінності від POP3 - дозволяє клієнтові маніпулювати повідомленнями на сервері.

Перший запропонований стандарт - RFC1730 (J. Myers December 1994)

Останній  запропонований стандарт  -  RFC3501  (VERSION  4rev1  M.  Crispin March 2003)

IMAP, як стандарт, поки не прийнятий, він залишається "запропонованим стандартом"!

На сьогоднішній день цей протокол дуже інтенсивно використовується.

 

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

 

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

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

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

•   Можливе створення загальних папок, до яких можуть мати доступ декілька користувачів.

•   Інформація про стан листів зберігається на сервері і доступна всім клієнтам. Листи можуть бути помічені як прочитані, важливі і тому подібне.

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

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

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

 

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

 

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

 

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

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

Взаємодія клієнта з сервером не будується за принципом "запит-відповідь".

Клієнт може відправити нову команду сервера не чекаючи відповіді на попередню.

 

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

 

UID - унікальний ідентифікатор, привласнюється кожному повідомленню (не може мінятися), 32 біти.

UIDVALIDITY - унікальний тимчасовий ідентифікатор в даній сесії

Порядковий номер - має кожне повідомлення (може мінятися).

Прапорці:

"\Seen" - означає, що дане повідомлення було прочитане

"\Answered" - на повідомлення було дано відповідь

"\Deleted" - повідомлення помічене на видалення

"\Draft" - формування даного повідомлення ще не завершене

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

 

5.3 Деякі команди IMAP

 

LOGIN

Аргументом команди є рядок з ідентифікатором (ім'ям) і паролем клієнта:

 

S: * OK IMAP4 revl Service Ready

С: a001 login Vasy pasword // відправка логіну та паролю

S: a001OK LOGIN completed  // ідентифікація пройшла успішно

 

AUTHENTICATE

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

 

S: * OK KerberosV4 IMAP4revl Server

С: А001 AUTHENTICATE KERBEROS_V4

S: + AmFYig==

C: BAcAQrJ5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT

+nZIiriJjnTNHJUtxAA+oOKPKfHEcAFs9a3CL50ebe/ydHJUwYFd

WwuQlMWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKilQh

S: + or//EoAADZI=

C: DiAF5MgA+oOIALuBkAAmw==

S: A001 OK Kerberos V4 authentication successful

 

SELECT

Після реєстрації в системі клієнт повинен вибрати каталог повідомлень, з яким він працюватиме. Вибір каталога здійснюється командою SELECT. Аргументом команди є ім'я поштового каталога:

 

С: А142 SELECT INBOX // відкриття каталогу INBOX

S: * 172 EXISTS // В каталозі "INBOX" - 172 повідомлення

S: * 1 RECENT  // З них одне тільки що прийшло

S: * OK [UNSEEN 12) Message 12 is first unseen // В директорії є непрочитані листи, мінімальний порядковий номер непрочитанного листа - 12

S: * OK [UIDVALIDITY 3857529045] UIDs valid // Унікальний тимчасовий ідентифікатор папки INBOX в даній сесії - 3857529045

S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) // Повідомлень в даній папці можить мати флаги, вказані в рядку FLAGS

S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited  // Клієнт може меняти у повідомлень флаги "\Deleted" та "\Seen"

S: A142 OK [READ-WRITE] SELECT completed  // Клієнт має права на запис и читання повідомлень із INBOX

 

EXAMINE

Якщо користувачеві необхідно отримати інформацію про стан якого-небудь каталогу, досить скористатися командою EXAMINE з ім'ям каталогу як аргумент команди, наприклад:

 

С: А932 EXAMINE bloop

S: * 17 EXISTS

 

Команда EXAMINE повертає ті ж параметри, що і команда SELECT, а відрізняється від команди SELECT тільки тим, що відкриває задану поштову скриньку виключно на читання.

 

STATUS

Якщо необхідно запитати статус якої-небудь папки, не міняючи поточнийкаталог, можна скористатися командою STATUS. Як параметри даній команді додаються: ім'я теки і тип запрошуваної інформації. Залежно від вказаного типу, команда може повертати: кількість повідомлень в теці, кількість нових повідомленні кількість непрочитаних повідомлень, UIDVALIDITY каталогу, UID наступного повідомлення, яке буде додано в дану теку, наприклад:

 

С: A042 STATUS blob (MESSAGES UNSEEN)

S: * STATUS blob (MESSAGES 231 UNSEEN 12)

S: A042 OK STATUS completed

 

LIST

Щоб отримати список підкаталогів, що знаходяться в певній теці доступних клієнтові, можна скористатися командою LIST. Аргументами команди є: ім'я каталогу, список підкаталогів який хочемо отримати (порожній рядок - "" означає поточний каталог) і маска імен підкаталогів. Імена каталогів і маски імен підкаталогів можуть інтерпретуватися по-різному, залежно від реалізації поштової системи і структури опису ієрархії тек. Наприклад, список тек, що знаходяться в корені, можна отримати так

 

С: А004 LIST "/" *

S: * LIST (\Noinferiors ) "/" INBOX

S: * LIST (\Noinferiors ) "/" WasteBox

S: A004 OK LIST completed

 

Відповідь сервера містить список каталогів відповідно до їх положення в ієрархії, прапори даних каталогів (прапор "\Noinferiors" означає, що усередині даної папки немає, і не може бути побудована ієрархія).

 

FETCH

Після отримання інформації про каталог, користувач може прочитати будь-яке повідомлення або певну групу повідомлень, частина повідомлення або певні атрибути повідомлення. Для цього використовується команда FETCH.

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

 

STORE

Після переглядання повідомлення, користувач може зберегти його з іншими прапорами, додати або видалити прапори повідомлення ( помітити дане повідомлення на видалення). Для цього використовується команда STORE. Аргументами команди є: номери повідомлень, ідентифікатор операції і перелік прапорів. Наприклад, операція додавання прапора видалення ("\Dеleted") трьом повідомленням виглядає таким чином:

 

С: АОО3 SТОRЕ 2:4 +FLAGS (\DELETED)

S: * 2 FETCH FLAGS (\Deleted \ Seen)

S: * 3 FETCH FLAGS (\Deleted )

S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) S: A003 OK STORE completed

 

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

 

SEARCH

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

Для цього використовується команда SEARCH. Наприклад, пошук всіх непрочитаних повідомлень, що поступили від "smith" з 1-03-96 виглядатиме так:

 

C: A282 SEARCH UNSEEN FROM 'Smith" SINCE 1-Mar-1996

S: * SEARCH 2 84 882

S: A282 OK SEARCH completed

 

Результатом пошуку будуть повідомлення з послідовними номерами 2, 84 і 882.

 

APPEND

IMAP4 дозволяє не тільки шукати і читати повідомлення в каталогах, цей протокол дозволяє додавати, копіювати і переміщати повідомлення в каталоги. Додавання повідомлення в теку можна здійснити командою APPEND:

 

C: A003 APPENDSAVED-MESSAGES (\Seen) {310} C: Date: Mon, 7 Feb 1997 21:52:25 - 0800 {PST}

C: From: Fred Foobar

C: Subject: aftenoon meeteng

C: TO: mooch@owatagu.siam.edu

C: Message-Id:

C: Mime-Version: 1.0

C: Content-Type: Text/PLAIN; CHARSET=US-ASCII C:

C: Hello Joe, do you think we can meet at 3:30 tomorrow?

C:

S: A003 OK APPEND completed

 

COPY

Команда COPY копіює повідомлення із заданими порядковими номерами у вказаний каталог, наприклад:

 

C: A003 COPY 2:4 MEETENG

S: A003 OK COPY completed