Література

1. Ральф Гильдебрандт, Патрик Кеттер. Postfix. Подробное руководство = The Book of Postfix: State-of-the-Art Message Transport. — СПб.: Символ-Плюс, 2008. — С. 512. — ISBN 978-5-93286-109-7

Тема 10. Протокол imap

Етапи еволюції поштових протоколів

На даний момент існує кілька протоколів прийому передачі пошти між багатокористувацькими системами. Дамо короткий опис кожного з них.

ПРОТОКОЛ SMTP

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

POP, POP2, POP3

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

POP3 має деяке число розширень зроблених на його базі, включаючи Xtnd Xmit, які дозволяють клієнту послати пошту використовуючи POP3 сесію, замість використання протоколу SMTP. Ще один "діалект": APOP підтримує шифрування пароля, (RSA MD5) який передається по мережі. Існує також варіант POP3 адаптований для доступу до дощок оголошень.

IMAP2, IMAP2BIS, IMAP3, IMAP4, IMAP4REV1

Ще одне сімейство досить простих протоколів, до всіх інших можливостям POP3 сімейства, IMAP дає можливість клієнту здійснювати пошук рядків у поштових повідомленнях, на самому сервері. IMAP здійснює зберігання пошти на сервері, у файлових директоріях (IMAP also allows mail on the server to be placed in server-resident folders.)

• IMAP2 – використовується в рідкісних випадках.

• IMAP3 – несумісне ні з чим рішення, більше не використовується.

• IMAP2bis – розширення IMAP2, яке до цих пір продовжує використовуватися, більше того IMAP2bis дозволяє серверам, розбиратися в MIME-структурі повідомлення.

• IMAP4 – перероблений і розширений IMAP2bis, який можливо використовувати де завгодно.

• IMAP4rev1 – деякі виправлення з невеликою кількістю проблем протоколу IMAP4.IMAP4rev1 розширює IMAP великим набором функцій включаючи частину тих, які використовуються в DMSP.

• ACAP – (Application Configuration Access Protocol), формально: IMSP (Interactive Mail Support Protocol) Протокол, розроблений для роботи з IMAP4, додавати можливість, пошукової підписки і передплати на дошки оголошень, поштові скриньки і для пошуку/знаходження адресних книг.

IMAP проти POP – можна знайти досить багато вузлів які підтримують POP і не дуже багато IMAP вузлів. Багато в чому це пояснюється, тим, що POP3 вже давно сформований Internet'овскій стандарт. Проте інтерес до IMAP4 проявило досить велике число компаній. IMAP4rev1 має багато зручностей заснованих на моделі, коли користувачі зберігають свою пошту на сервері, замість того, щоб зберігати її у себе на робочому комп'ютері. Величезна перевага цього протоколу, різко проявляється на персоналі, який "робить e-mail" з різних комп'ютерів і в різний час. Вони повинні мати один і той-же рівень якості послуг доступу до своєї пошти, де б вони не знаходилися.

DMSP, ESMTP ETRN, MIME

DMSP – Також відомий як PCMAIL. Робочі станції можуть використовувати цей протокол для прийому/посилки пошти. Система побудована навколо ідеї, що користувач може мати більш, ніж одну робочу станцію в своєму користуванні, однак це не означає реалізацію ідеї "public workstaion" у повному обсязі. Робоча станція містить статусну інформацію про пошту, директорію через яку відбувається обмін і коли комп'ютер підключається до сервера, ця директорія оновлюється до поточного стану на mail-сервері. DMSP не наслідує IMAP або POP, і я відчуваю що, скоро стане доступним і клієнтське програмне забезпечення до нього.

ESMTP ETRN – ETRN той, який описаний в RFC 1985, модифікована версія SMTP команди TURN, яка доступна в розширеній редакції SMTP протоколу (ESMTP). Він надає більш простий інтерфейс, ніж POP.

MIME – (Multipurpose Internet Mail Extensions) Стандарт для формату листів не ASCII змісту і мають кілька частин. Всякий клієнт може вивантажити/завантажити собі файли, які використовують MIME кодування. Деякі клієнти мають вбудовану систему кодування/декодування MIME повідомлень. Client-Server'ние протоколи зазвичай працюють тільки з цілими повідомленнями і можуть отримувати/посилати MIME повідомлення, правда, як частина іншого повідомлення, тому що MIME розроблений так, щоб бути прозорим для всіх існуючих mail систем. Однак IMAP4 має можливість працювати як з повними, так і з окремими частинами MIME повідомлення.

LAN E-MAIL, X.400, LDAP

LAN e-mail можна надавати використовуючи метод file sharing (файлове поділ/надання), наприклад, через NFS, що дозволяють Unix станціям розділяти однакову mail spool область, або використовувати Novell's SMF (Simple Message Format) на Novell'овском файловому сервері. І якщо програма коректно обробляє захоплення фалів, то посилати/приймати пошту можна незалежно від протоколів файлового обміну. Наприклад: Unix системи можуть використовувати який-небудь AFS або NFS. Pegasus це pc/mac client-пpогpамма використовує file service'и Novell'овского сервера.

X.400 – транспортний протокол, визначений для зв'язку двох вузлів доступу, розроблений консорціумом ISO. Він жорстко прив'язаний на TCP/IP SMTP протоколі із заголовком, описаним в документі RFC822. Консорціум X.400 фірм (XAPIA) розробив API для X.400 сумісних програм званий CMC.

LDAP – (the Lightweight Directory Access Protocol) почав використовуватися на деяких клієнтах, як Інтернет-шлях отримання E-mail адреси від сервера, тобто ви отримуєте можливість, набрати будь-яке ім'я отримувати його e-mail адресу від server-based каталогу. LDAP, звичайно має і інші застосування. Є плани в додавання LDAP клієнта в IMAP і POP клієнтів. LDAP легко може бути інтегрований з системами, заснованими на протоколі X.500 він легко Гутіра в обидві сторони. Обидва методи надають методи для пошуку, і отримання полів каталогу, але не визначають імена полів або того що повинно міститися в цих полях.

ПОШТОВІ API - MAPI (MICROSOFT), VIM (LOTUS), AOCE (APPLE)

Ще один із способів це використання API-яких фірм виробників. Це дозволяє змішувати RPC механізми з якимись додатковими послугами доступними через набори API. Наприклад, виробник визначає API, і він може бути використаний через IPX або TCP/IP, в обох випадках підтримується стеки RPC механізмів. Зараз досить багато таких рішень "пропихується" великими фірмами:

MAPI (Microsoft); VIM (Lotus); AOCE (Apple). Такі API використовуються у своїй основі програмами здатними приймати/надсилати пошту в тому чи іншому вигляді, просто користуючись функціями API, які в свою чергу взаємодіють з сервером підтримуючим аналогічний API. Специфікації для взаємодій типу client-server, залежить як від починаючи з протокольного стека аж до RPC, так і самого API.

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

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

Реалізація IMAP сервера із використанням ОС FreeBSD

На основі прикладу з попередньої теми виконаємо покрокові дії:

1. Встановимо dovecot:

# cd /usr/ports/mail/dovecot

# make install clean

2. Відредагуємо /etc/rc.conf додавши в кінці:

dovecot_enable="YES"

3. Відредагуємо основний конфігураційний файл /usr/local/etc/dovecot.conf, до таких параметрів. Це виконується шляхом пошуку відповідних стрічок і заміні їхніх параметрах на ті що вказані нижче, не треба повністю замінювати весь файл.

protocols = imap pop3 disable_plaintext_auth = no ssl = no mail_location = mbox:~/mail/:INBOX=/var/mail/%u mail_privileged_group = mail verbose_proctitle = yes first_valid_gid = 0 protocol imap { imap_client_workarounds = delay-newmail outlook-idle netscape-eoh tb-extra-mailbox-sep } protocol pop3 { pop3_uidl_format = %08Xu%08Xv pop3_client_workarounds = outlook-no-nuls oe-ns-eoh } protocol lda { postmaster_address = postmaster@example.com sendmail_path = /usr/sbin/sendmail } auth default { mechanisms = plain passdb pam { } userdb passwd { } user = root } dict { #quota = mysql:/usr/local/etc/dovecot-dict-quota.conf } plugin { }

4. Збережіть файл і запустіть dovecot:

/usr/local/etc/rc.d/dovecot start

5. Налаштуємо первинний сервер DNS, для цього приведемо файл /etc/resolv.conf до такого стану:

# Generated by resolvconf

nameserver 127.0.0.1

Також в FreeBSD існує досить не поганий сервер IMAP/POP3 Courier-IMAP, але Dovecot вважається більш потужнішим. Для перевірки IMAP сервера можна використати поштовий клієнт Microsoft Outlook 2010.

контрольні питання

Які можливості для роботи з поштовими скриньками і повідомленнями надає протокол IMAP?

У чому полягають переваги і недоліки протоколу IMAP в порівнянні з протоколом POP3? На підставі яких критеріїв слід вибирати один з цих протоколів?

На які стану ділиться сеанс IMAP? Як відбуваються переходи з одного стану в інший? Які дії характерні для кожного стану сеансу?

Чому на сервері IMAP використовуються різні простори імен? Як вони розрізняються?

Що таке ярлики команд? Для чого вони використовуються? Чим відрізняються помічені і непомеченние відповіді сервера?

Що таке літерали? Як і в яких випадках вони використовуються?

Які способи аутентифікації використовуються протоколом IMAP? Чи відрізняються вони від використовуваних протоколами SMTP і POP3?

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

Як організується взаємодія клієнта з розподіленою системою серверів IMAP, в якій ящики, доступні клієнту, розташовуються на різних серверах?