Протокол IMAP4
Протокол IMAP4
O В этой главе
O Достоинства протокола IMAP4
O Основные команды
O Чтение сообщений
Протокол IMAP4 (Internet Mail Access Protocol) сильно уступает в популярности POP3, но значительно превосходит его функциональности. Однако никакого противоречия здесь нет. В отличие от POP3, IMAP4 предполагает хранение и обработку сообщений на сервере, откуда вытекает необходимость наличия постоянного канала связи. Большинство пользователей не могут позволить себе подобную роскошь, и потому IMAP4 в основном используется в локальных корпоративных сетях, где постоянная связь с сервером - не проблема.
Большинство получателей, не имеющих постоянного соединения с Internet, предпочитают не хранить почту на сервере, а забирать ее на свой локальный ящик и обрабатывать сообщения собственными клиентскими средствами.
Совсем иная ситуация складываться в локальных корпоративных сетях, где постоянная и стабильная связь с сервером - не проблема. Корреспонденция, хранящаяся на сервере, доступна всем клиентам, обладающими соответственными правами доступа, и надежно защищена (равно как и сам сервер), в то время как гарантировать целостность информации на множестве локальных машин затруднительно.
С другой стороны, в POP3-ящиках почта храниться незначительные промежутки времени, и это затрудняет ее похищение злоумышленником. Напротив же, идеология IMAP4 диктует постоянное хранение всей почты на одном сервере. И если этот сервер окажется взломан, злоумышленник получит доступ сразу ко всей корреспонденции.
Под обработкой сообщений понимается возможность растасовать корреспонденцию по множеству папок и наличие развитых функций поиска необходимого письма. Все это реализовано практически в любой почтовой программе (например, Outlook Express, The Bat), однако, при использовании протокола IMAP4 эти операции выполняются сервером, а не клиентом.
Такой подход приводит к интенсивному взаимодействию с сервером и может легко вызвать его перегрузку. Поэтому, в протоколе появились новшества, заметно оптимизирующие скорость обмена. В отличие от POP3, взаимодействие клиента с IMAP4 сервером стоится не по принципу «запрос-ответ», а происходит асинхронно. То есть можно посылать следующую команду не дожидаясь ответа на предыдущую. Порядок обработки запросов определяется сервером из соображений оптимизации скорости работы, и часто случается так, что команды обрабатываются в обратном порядке.
Что бы иметь возможность определить к какому именно запросу относится ответ сервера, в протокол были введены теги. Тег предваряет каждый запрос клиента и ответ сервера.
Обмен при этом выглядит приблизительно так:
· тег1 команда 1
· тег2 команда 2
· тег2 ответ на команду 2
· тег3 команда3
· тег1 ответ на команду 1
· тег3 ответ на команду 3
Тег представляет собой короткую символьно-цифровую строку, идентифицирующую каждую команду клиента. Ответы сервера (или очередные запросы клиента, в том случае, когда они связаны друг с другом) должны ссылаются на команду по ее тегу.
Однако чаще всего взаимодействие происходит по старому - доброму принципу «запрос-ответ». В самом деле, прежде чем посылать очередную команду, недурно бы получить ответ на предыдущий запрос. Например, читать корреспонденцию не получится до тех пор, пока сервер не выдаст список всех сообщений в почтовом ящике. Поэтому, в приведенных ниже примерах будет всегда использоваться один и тот же тег, что вполне допустимо, - как только приходит ответ сервера, использованный ранее тег, вновь становиться «свободным».
Большинство поставщиков бесплатных сетевых услуг не поддерживают протокола IMAP4. Поэтому, найти такой сервер, для многих окажется не легкой задачей. Неплохой идеей будет набрать в строке запроса поисковой системы (такой, как «Апорт») нечто вроде «IMAP4+free»
Неплохо себя зарекомендовала бесплатная служба “Mailru.com”, предоставляющая быстрый и бессбойный доступ к почтовому ящику по протоколам POP3, STMP, IMAP4.
Семьдесят три страницы убористого технического текста RFC-1730 документируют более двадцати различных команд протокола. Подробное описание IMAP4 превратило бы популярную книгу во множество скучных томов справочного руководства. В беглом обзоре этой главы будут рассмотрены лишь простейшие операции с почтовым ящиком, но вполне достаточные для чтения корреспонденции.
Для начала работы необходимо установить TCP-соединение через сто сорок третий порт.
Подключение к mail.softclub.net
Через секунду после установления соединения, на экране telnet-клиента появится приглашение следующего вида:
· OK joshua.softclub.net IMAP4rev1 v12.250 server ready
Сразу же после его выдачи сервер переходит в состояние аутентификации. Передать свое имя и пароль клиент может двумя способами: либо воспользоваться командой “login” и послать их по сети в открытом виде (как чаще всего и происходит), либо выбрать защищенный режим, воспользовавшись командой “authenticate”, которая передает шифрованный пароль. Здесь не приводится анализ уязвимости тех или иных алгоритмов шифрования паролей и их реализаций. В общем случае все они достаточно надежны, а ошибки конкретных реализаций всегда можно найти на любом сайте, посвященном сетевой безопасности.
В приведенном ниже примере для входа на сервер используется команда “login”, следом за которой идут имя и пароль пользователя, разделенные пробелом:
· kpnc login kpnc MyPassword
· kpnc OK LOGIN completed
Ответ сервера состоит из трех частей: возращенного тега “kpnc” [196], ключевого слова “OK”, подтверждающего успешное завершение операции (в противном случае было бы “BAD”), и осмысленной текстовой строки (“LOGIN completed”).
С момента подтверждения пароля доступ к почтовому ящику открыт. Но прежде, чем приступить к чтению поступившей корреспонденции, необходимо понять, как она храниться на сервере. Конечно же, в папках, ибо в современной компьютерной терминологии папкой называется все, способное вмещать в себя что-то еще [197] Название и содержимое папок определяется самим пользователем, но в любой системе обязательно присутствует папка “INBOX”, в которую помещается поступающая корреспонденция.
Для выбора папки предусмотрена команда “SELECT”, использование которой продемонстрировано в следующем примере:
· kpnc SELECT INBOX
· * FLAGS (Answered Flagged Draft Deleted Seen)
· * OK [PERMANENTFLAGS(AnsweredFlaggedDraftDeletedSeen *)]
· * 1 EXISTS
· * 1 RECENT
· * OK [UNSEEN 1]
· * OK [UIDVALIDITY 954332839]
· kpnc OK [READ-WRITE] Completed
Значок звездочки указывает на неразрывность информационного потока. До тех пор, пока в начале строки не встретится возращенный тег, никто не должен вклиниваться в процесс передачи.
За ключевым словом “FLAGS” (порядок которого в ответе произволен) перечисляются все доступные флаги для сообщений данной папки. Назначение их такого:
· Answered: на сообщение был отправлен ответ
· Flagged: сообщение имеет флаг (отмечено «галочкой»)
· Draft: незавершенное сообщение (черновик)
· Deleted: сообщение помечено как удаленное, но еще физически не удалено
· Seen: сообщение уже было прочитано
· Recent: только что полученное сообщение [198]
Следующее ключевое слово “PERMANENTFLAGS” показывает, какие флаги сообщений может менять пользователь, где знак «*» (джокер) обозначает «все флаги».
Две строки, расположенные ниже, говорят о том, что в ящике содержится всего одно письмо, которое было только что получено. «Только что» следует трактовать как «в промежутке между двумя последними сессиями».
Сообщение “UNSEEN 1” входит в перечень необязательных для реализации и подсчитывает количество непрочитанных писем. В приведенном примере имеется только одно такое письмо.
Уникальный временной идентификатор папки, следующий за “UIDVALIDITY”, может использоваться взамен ее имени и варьируется от сессии к сессии.
Последняя строка сообщает права клиента на эту папку. В данном случае доступно чтение и запись сообщений.
Следующий эксперимент демонстрирует технику чтения сообщений. В отличие от POP3, такую, казалось бы, простую операцию выполнить весьма затруднительно. Тогда как POP3 допускает лишь одну возможность - получение всего сообщения целиком, протокол IMAP4 помимо номера выбранного сообщения требует указание критерия запроса!
Полное описание синтаксиса запроса содержится в RFC-1730, с котором настоятельно рекомендуется ознакомиться, но здесь привести даже в общих чертах не представляется возможным.
Сообщение может быть прочитано различными способами, один из которых продемонстрирован ниже. Он заключается в вызове команды “FETCH” с параметрами, обсуждение которых выходит за рамки данной книги, но может быть почерпнуто из RFC-1730.
В простейшем случае для получения заголовка сообщения необходимо перейти в папку, в которой хранится это сообщение (для этого используется команда “SELECT”) и отправить серверу следующий запрос “FETCH msg BODY[HEADER]”, где “msg” порядковый номер требуемого сообщения.
Например, это может выглядеть так:
· kpnc SELECT INBOX
· kpnc FETCH 1 BODY[HEADER]
· 1 FETCH (FLAGS (Recent Seen) BODY[HEADER] {1032}
· Return-Path: «kpnc@aport.ru»
· Received: from msk2.mail.ru (mx2.mail.ru [194.67.23.33])
· by mx1.mailru.com (8.10.0/8.10.0.Beta10) with ESMTP id e2TCbfd35173
· for «kpnc@mailru.com»; Wed, 29 Mar 2000 16:37:41 +0400 (MSD)
· Received: from camel.int ([10.0.0.98] helo=camel.mail.ru)
· by msk2.mail.ru with esmtp (Exim 3.02 #116)
· id 12aHjy-0000Dk-00
· for kpnc@mailru.com; Wed, 29 Mar 2000 16:38:30 +0400
· Received: from ppp-02.krintel.ru ([195.161.41.226] helo=KPNC)
· by camel.mail.ru with smtp (Exim 3.02 #107)
· id 12aHje-0002OB-00
· for kpnc@mailru.com; Wed, 29 Mar 2000 16:38:12 +0400
· Message-ID: «006801bf997a$e6e39e80$f429a1c3@KRINTEL.RU»
· From: =?koi8-r?B?69LJ0yDrwdPQxdLTy8k=?= «kpnc@aport.ru»
· To: «kpnc@mailru.com»
· Subject: Test
· Date: Wed, 29 Mar 2000 16:31:32 +0400
· MIME-Version: 1.0
· Content-Type: text/plain;
· charset="koi8-r"
· Content-Transfer-Encoding: 7bit
· X-Priority: 3
· X-MSMail-Priority: Normal
· X-Mailer: Microsoft Outlook Express 5.00.2417.2000
· X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
·)
· kpnc OK Completed
А текст письма можно получить, воспользовавшись запросом “FETCH msg BODY[TEXT]”.
Например:
· kpnc FETCH 1 BODY[TEXT]
· 1 FETCH (BODY[TEXT] {16}
· Hello, KPNC!
·
·)
· kpnc OK Completed
Остальные команды протокола IMAP4 здесь рассматриваться не будут, но могут быть найдены в технической документации RFC-1730, RFC-2060 и RFC-2062.
Дополнение. Почтовый сервер изнутри
O В этой главе:
O Краткая история возникновения почтальона SendMail
O Архитектура SendMail
O Компоненты SendMail - User Agent, Transfer Agent, Delivery Agent
O Иерархия и взаимодействие компонентов SendMail
O Устройство и назначение Агента Пользователя
O Устройство и назначение Агента Пересылки
O Устройство и назначение Агента Доставки
O Устройство почтового ящика
O Механизм отправки писем локальным получателям
O Механизм отправки писем удаленным получателям
O Прием входящих сообщений, модель Sender - Receiver
O Аутентификация отправителя
O SMTP-соединение
O SMTP-транзакции
O Использование SMTP сервера для приема входящей почты
O Очередь отправки сообщений
O Relay-серверы
O Команды терминальной посылки, организация конференции реального времени
O Форвардинг почты
O Устройство агента POP3