Протокол imap-4

Протокол IMAP–4 (Internet Message Access Protocol) позволяет получать доступ к сообщениями электронной почты на сервере, но в отличии от протокола РОРЗ поддерживает работу с системой каталогов (или папок) удаленных сообщений так же, как если бы они располагались на локальном компьютере иными словами выполняет функции пользовательского агента. Структура каталогов в значительной степени зависит от типа почтовой системы, но поступающие пользователя сообщения помещаются в каталог inbox.

IMAP–4 работает поверх протокола TCP. Для приема соединений IMAP-сервер использует стандартный порт 143; IMAP–4 клиент может открывать соединение с любого порта. Принцип передачи данных IMAP–4 такой же как у вышеописанных протоколов.

1. Сначала клиент и сервер обмениваются приветствиями.

2. Клиент отправляет на сервер команды и данные. Каждая команда клиента начинается с уникального идентификатора команды, представляющего собой короткую строку, состоящую из букв и цифр, (например, А0001,А0002 и т. д.). При ответе сервер (или клиент используя следующие команды) может ссылаться на данную команду по ее идентификатору.

Сервер, обработав команду, передает клиенту ответы и данные. Строки данных, передаваемые с сервера в ответ на команду клиента, могут не содержать уникального идентификатора, а содержат символ "*", означающий, что передаются промежуточные строки потока данных ответа, а идентификатор их команды содержится в последней строке потока. В случае, если сервер обнаружить ошибку в команде, клиенту отправляется уведомление с идентификатором неправильной команды. В случае успешной обработки команды - уведомление ОК в противном случае уведомление NO с идентификатором невыполненной команды. Если команда состоит из нескольких строк или формирование ар­гументов команды требует промежуточного отклика от сервера, то после получения очередной строки команды сервер возвращает от­клик с префиксом из символа +, говорящим, что сервер готов к при­ему продолжения команды. Этот отклик может также содержать промежуточные данные, необходимые клиенту для завершения формирования команды.

Для обеспечения гибкости и многофункциональности работы, почтовые системы IMAP присваивают сообщению:

• определенный атрибут-флаг который может быть действителен для данного сообщения постоянно от сессии к сессии, или только в данной сессия. Наиболее употребительные из них:

"Seen" - данное сообщение было прочитано;

"Answered" - на сообщение был дан ответ ;

"Deleted" - сообщение помечено на удаление ;

"Draft" - формирование данного сообщения еще не завершено ;

"Recent" - сообщение "только что" поступило в почтовый ящик, т. е. данная сессия - первая, которая может прочитать это сообщение;

• уникальный идентификатор (UID) –32-битное число, которое идентифицирует сообщение в данной папке и по которому можно получить доступ к этому сообщению от сессии к сессии и используется, например, для синхронизации каталогов мобильных пользователей.

Кроме того, на сервере IMAP хранятся дата и время получения сообщения сервером.

3. После завершения обмена канал закрывается.

Пример IMAP4-сеанса

Протокол IMAP4 обслуживает более 20 различных команд клиента по управлению состоянием своей почты. Опишем несколько из них на примерах обработки взаимодействия клиента и сервера IMAP4.

1. В начале сеанса сервер выдает отклик приветствие:

S: * OK IMAP4rev1 Service Ready

2. Производится регистрация клиента с помощью команды LOGIN, передающей пароль и идентификатор пользователя по сети в открытом виде. Аргументом команды является строка с идентификатором и паролем клиента:

С: a00l login rita

S: a001 OK LOGIN completed

При необходимости защиты почтового ящика, возможно использование команды 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: а001 OK Kerberos V4 authentication successful

3. Для получения списка подкаталогов, находящихся в каталоге и доступных клиенту, используется команда LIST. Аргументами команды являются: имя каталога, список необходимых подкаталогов (пустая строка - "" означает текущий каталог) и маска имен подкаталогов. Например, список папок, находящихся в корне, можно получить так:

С: а002 LIST " " *

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

S: * OK LIST completed

4. Выбор каталога осуществляется командой SELECT. Аргументом команды является имя почтового каталога:

С а142 SELECT INBOX	Выбор папки входящие
S * 145 EXISTS	В папке входящие - 145 сообщения
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

5. При необходимости получения информации о состоянии какого-либо каталога, используют команду EXAMINE с именем каталога в качестве аргумента команды, например:

С: а932 EXAMINE bloop

S: * 17 EXISTS

Команда открывает заданный почтовый ящик исключительно на чтение.

6. При необходимости получения статуса папки, не меняя текущий каталог, используют команду STATUS. В качестве параметров данной команде передают: имя папки и тип запрашиваемой информации. В зависимости от указанного типа, команда может возвращать: количество сообщений в папке, количество новых сообщении количество непрочитанных сообщений, UID следующего сообщения, которое будет добавлено в данную папку, например:

С: а042 STATUS blob (MESSAGES UNSEEN)

S: * STATUS blob (MESSAGES 231 UNSEEN 12)

S: A042 OK STATUS completed

7. Другие команды, манипулирующие почтовыми сообщениями, включа­ют в себя CREATE, DELETE, RENAME, STATUS, APPEND. Команда CLOSE закрывает ящик, удаляя все сообщения с флагом Deleted.

8.Команду NOOP («нет операции») можно периодически подавать во время простоя сеанса, чтобы дать серверу возможность известить клиента о прибытии новых сообщений. Такое извещение может быть также включено сервером в отклик, следующий после любой команды.

С а008 NOOP

S *18 EXISTS

S * 2 RECENT

C а008 OK NOOP completed a009 logout

* BYE IMAP4revl server terminating connection

C a009 OK LOGOUT completed

Дополнительные методы защиты электронных сообщений [1]

Рассмотрим механизм аутентификации, использование которого возможно в любых протоколах –SASL (Simple Authentication and Security Layer):

1. Клиент подает команду аутентификации, содержащую указания на алгоритм аутенти­фикации.

2. Происходит обмен запросами и ответами между сервером и клиентом. Сервером осуществляется запрос, на основании которого клиентом вычисляется ответ и возвращается серверу. Запросы и ответы определяются механизмом аутентификации. Получив ответ от клиента, сервер отвечает одним из способов:

• Передачей следующего запроса, основанного на механизме аутентификации;

• объявлением об успешной аутентификации;

• объявлением о неуспешной аутентификации.

При получении запроса клиент может возвратить ответ или объявить об от­казе от аутентификации.

Рассмотрим пример реализации SASL в протоколе IMAP4, с используемым механизмом CRAM-MD5 (RFC-2104) [1].

*OK IMAP4 Server	Отклик сервера на приветствие
а0001 AUTHENTICATE CRAM-MD5	Выдача клиентом запроса на аутентификацию по алгоритму CRAM-MD5
+ TUyQHBvc3RvZmZpY2UucmVzdG9u	Запрос сервера на аутентификацию, начинающего с символа + и представляющий собой временной штамп 9158.989448259>, закодирован­ный с помощью Base64
AyYzdlZGE3YTQ5NWI0ZTZ1NzMzNGQzODkw	Отклик клиента, состоящий из имени пользователя, дайджеста пароля пользо­вателя с присланным временным штампом, закодированный по алгоритму Base64.
а001 OK CRAM authentication successful
CAPABILITY	Подача клиентом запроса о поддерживаемых сервером механизмах аутентификации
*CAPABILITY IMAP4revl AUTH=KERBER0S_V4 AUTH-CRAM-MD5	Сервер поддерживает механизм KERBER0S
OK CAPABILITY completed

Рассмотрим пример реализации SASL в протоколе POP-3,

+0К POP server ready	Отклик сервера на приветствие
AUTH CRAM-MD5	Выдача клиентом запроса на аутентификацию по алгоритму CRAM-MD5
+ 40TYuNjk3MTcv/DTUyQHBvc3RvZmZpY2	Запрос сервера на аутентификацию, начинающего с символа + и представляющий собой временной штамп 9158.989448259>, закодирован­ный с помощью Base64
GltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZ	Отклик клиента, состоящий из имени пользователя, дайджеста пароля пользо­вателя с присланным временным штампом, закодированный по алгоритму Base64.
+0K CRAM authentication successful
САРА	Подача клиентом запроса о поддерживаемых сервером механизмах аутентификации
SASL CRAM-MD5 KERBER0S_V4	Сервер поддерживает механизм KERBER0S

Реализация SASL в протоколе SMTP также представле­на командой AUTH:

S: 220 rr.ru ESMTP server ready	Сервер готов и поддерживает дополнительные команды (ESMTP)
C: EHLO el.com	Клиент готов поддерживать дополнительные команды (EHLO)
S: 250 AUTH CRAM-MD5 DIGEST-MD5	Отклик сервера с указанием о поддержке механизма аутентификации по алгоритму CRAM-MD5
С: AUTH CRAM-MD5	Выдача клиентом запроса на аутентификацию по алгоритму CRAM-MD5
334PDE40TYuNjk3MTcwOTUyQH	Запрос сервера на аутентификацию
GltIGI5MTNhNjAyYzdlZGE3YTQ5	Отклик клиента
235 Authentication successful

Наличие в выводе команды EHLO дополнительной функции AUTH, говорит, что сервер поддерживает команду AUTH с указанными меха­низмами.

Кроме того, в команду MAIL FROM вводится дополнительный пара­метр AUTH, в котором указывается адрес отправителя, если сообще­ние было получено от аутентифицировавшегося клиента:

MAIL FROM:<ivanov@exmpl.ru> AUTH=ivanov@exrapl.ru

250 Sender OK

Наличие этого параметра позволяет передавать информацию об аутентифицированном отправителе письма при пересылке письма по цепочке транспортных агентов (конечно, все они должны под­держивать функцию AUTH).

Наи­более распространенными являются механизмы, основанные на MD5: DIGEST-MD5 и CRAM-MD5:

• CRAM-MD5 (RFC 2195) [17]. Сервер в приглашении или первом оклике посылает сроку, состоящую из случайного числа, временной отметки и доменного имени сервера. Ответ должен содержать идентификатор клиента, пробел и HMAC-MD5 оклика. В качестве ключа в HMAC-MD5 используется разделяемый секрет. Аутентификации сервера нет. Подвержен атаке со стороны фальшивого сервера (chosen plaintext attack).

• DIGEST-MD5 (RFC 2831). Начальная аутентификация: сервер посылает оклик, состоящий из имени/пароля, случайной строки, уровня обеспечиваемой защиты (аутентификация, аутентификация и защита целостности, и т д), максимального размера буфера шифрования, наличие поддержки utf-8 для имени и пароля, алгоритма аутентификации, алгоритма шифрования (3des, des, rc4-40, rc4, rc4-56). Клиент отвечает строкой, содержащей ответ на запрос сервера. Сервер проверяет ответ на оклик и посылает ответ в похожем формате для аутентификации. Целостность обеспечивается добавлением к каждому сообщению типа сообщения и его номера. При криптографическом закрытии сообщение шифруется принятым алгоритмом шифрования и дополняется частично шифрованным заголовком, обеспечивающим целостность.

• PLAIN (RFC 2595). Применяется в сочетании с TLS, обеспечивающим шифрованное соединение и аутентификацию сервера. Клиент посылает идентификатор авторизации, идентификатор аутентификации и пароль в открытом виде. Сервер проверяет идентификатор аутентификации и пароль на соответствие своей базе и наличие у данного идентификатора аутентификации права на идентификатор авторизации.

• OTP (RFC 2444; One-Time-Password). Генератор одноразовых паролей использующий оклик сервера и секрет клиента для получения пароля на один сеанс. Последовательность паролей для одного и того же отклика получается с помощью многократного применения MD5, SHA1 или MD4. От сервера требуется хранение БД последних использованных паролей для каждого пользователя. Аутентификации сервера нет.

Однако не следует забывать, что аутентификация не спасает от

• перехвата ТСР-соединения когда нарушитель ретранслирует команды аутентификации между клиентом и сервером, и после успешной аутентификации, блокирует клиента, передавая команды от его имени;

• атаки со стороны фальшивого сервера.

Вопросы безопасности [1]

Табл.

	Атака	Реализация	Противодействие
	недобросовестное использование электронной почты	атака на компьютер пользователя посредством рассылки почтовых вирусов	Установка запрета на автоматическое открытия вложений; При необходимости открытия подозрительного письма сохранение его на отдельной дискете, с последующей проверкой антивирусными программами; Своевременное обновление антивирусных программ и проверка файлов системы.
		отправка поддельных писем от имени любого пользователя возможна путем изменения настройки своего пользовательского агента или непосредственно открыв SMTP-сеанс с транспортным агентом.	определение адреса нарушителя исследованием заголовков Received; идентификация пользователя с помощью протокола RFC-1413. Сервер посылает клиенту на порт 113 запрос с номерами портов открытого клиентом SMTP-соединения. Если соответствующая программа запущена, то серверу возвращается имя пользователя, что позволяет произвести идентификацию клиента; аутентификация SMTP-сеанса; криптографическое закрытия текста сообщения, в том числе и ЭЦП
		чтение чужих писем нарушителем, при прослушивании сети на пути почтового сообщения или «нечестным» администратором почтового сервера	Криптографическое закрытия текста сообщения, в том числе и ЭЦП
	атака на почтовый сервер (для проникновения в ОС DOS-атаки)	Атака с помощью агента доставки Узким звеном в обеспечении безопасности почтового сервера являются агенты доставки, так как получение сообщения с локальным адресом вызывает запуск некоторой про­граммы, на вход которой подается почтовое сообщение неизвестного содержания, которое может быть использовано для про­никновения в ОС сервера или осуществления DOS-атаки.	использование стандартных агентов доставки (т.к. обнаруженные ошибки быстро публикуются и исправляются) тестирование агентов доставки на наличие ошибок; разрешение пользователям использования для работы с почтой только проверенные, одобренные программы
		Атака почтовой бомбой Атакуемая система переполняется письмами до тех пор, пока она не выйдет из строя из-за: переполнения диска или квоты пользователя, последующие письма не принимаются. переполнения входной очереди сообщениями, которые нужно обработать и передать дальше установки максимального числа сообщений которые пользователь может принять за один раз. Последующие сообщения отвергаются или уничтожаются. большой размера почтового ящика создающего трудности для получение системных предупреждений и сообщений об ошибках
	использование почтового сервера в качестве ретранслятора спама, вирусов	Открытые ретрансляторы (транспортные агенты, используемые в качестве «перевалочного пункта» почтовых сообщений) могут использоваться нарушителями для рассылки спама и вирусов. Для этого осуществляется SMTP-сеанс с открытым ретранслятором, которому указывается произвольный список получателей и необходимое сооб­щение. Транспортный агент ретранслятора разошлет сообщение по всем указанным адресам.	конфигурация транспортного агента таким образом, чтобы решение о возможности обработки сообщения принималось на основании IP-адреса SMTP-клиента, почтовых адресов отправи­теля и получателя; конфигурация транспортного агента на отказ приема сообщений из доменов или с адресов, зарекомендовавших себя как распространители спама (на основе базы RBL); использование SMTP-аутентификации пользователей;
	перехват паролей	перехват паролей в POP- и IMAP-сеансах, для получение и удаление почты без ведома пользователя	Аутентификация на основе протокола АРОР или SASL (Simple Authentication and Security Layer).
		перехват паролей в SMTP-сеансах, для отправки по­чты через данный сервер
		перехват TCP-соединения после успешной аутентификации клиента