IMAP | |
---|---|
Название | Internet Message Access Protocol |
Уровень (по модели OSI) | Прикладной |
Семейство | TCP/IP, E-Mail |
Создан в | 1986 |
Порт/ID | 143/TCP, 993/TCP (IMAP over SSL) |
Назначение протокола | Доступ к почтовым ящикам |
Спецификация | RFC 3501 |
Основные реализации (клиенты) | MUA (Outlook Express, Opera, Mozilla Thunderbird, The Bat!, Claws Mail, mutt и др.) |
Основные реализации (серверы) | UW IMAP, Courier, Cyrus, Dovecot |
IMAP (англ. Internet Message Access Protocol) — протокол прикладного уровня для доступа к электронной почте.
Базируется на транспортном протоколе TCP и использует порт 143.
IMAP предоставляет пользователю обширные возможности для работы с почтовыми ящиками, находящимися на центральном сервере. Почтовая программа, использующая этот протокол, получает доступ к хранилищу корреспонденции на сервере так, как будто эта корреспонденция расположена на компьютере получателя. Электронными письмами можно манипулировать с компьютера пользователя (клиента) без постоянной пересылки с сервера и обратно файлов с полным содержанием писем.
Для отправки писем используется обычно протокол SMTP, так как собственная команда отправки протокола IMAP, называемая APPEND, считается «неудачной» и «небезопасной»[источник не указан 190 дней].
Протокол IMAP представляет собой, в основном, альтернативу POP3 с зачаточными способностями по отправке.
POP3 имеет ряд недостатков, и наиболее серьёзный из них — отсутствие возможностей по управлению перемещением и хранением сообщений на сервере. Сообщения, как правило, загружаются с почтового сервера все сразу, после чего они с сервера удаляются, то есть отсутствует возможность выбирать сообщения для получения.
Для решения проблем, связанных с этой особенностью POP3, в Вашингтонском университете был разработан новый протокол, предполагающий возможность получения пользователями электронной почты из одного почтового ящика из различных мест, при этом сообщения не распределяются между точками получения. Пользователю предоставляется возможность управлять сообщениями в его почтовом ящике и дополнительными функциями по обслуживанию почтовых ящиков на сервере.
При использовании POP3 клиент подключается к серверу только на промежуток времени, необходимый для загрузки новых сообщений. При использовании IMAP соединение не разрывается, пока пользовательский интерфейс активен, а сообщения загружаются только по требованию клиента. Это позволяет уменьшить время отклика для пользователей, в чьих ящиках имеется много сообщений большого объёма.
Протокол POP требует, чтобы текущий клиент был единственным подключенным к ящику. IMAP позволяет одновременный доступ нескольких клиентов к ящику и предоставляет клиенту возможность отслеживать изменения, вносимые другими клиентами, подключенными одновременно с ним.
Благодаря системе флагов, определенной в IMAP4, клиент может отслеживать состояние сообщения (прочитано, отправлен ответ, удалено и т. д.); данные о флагах хранятся на сервере.
Клиенты IMAP4 могут создавать, переименовывать и удалять ящики и перемещать сообщения между ящиками. Кроме того, можно использовать расширение IMAP4 Access Control List (ACL) Extension (RFC 4314) для управления правами доступа к ящикам.
Поиск сообщений происходит на стороне сервера.
IMAP4 имеет явный механизм расширения.
IMAP работает только с сообщениями и не требует каких-либо пакетов со специальными заголовками.
Каждое сообщение имеет несколько связанных с ним атрибутов. Эти атрибуты могут быть определены индивидуально или совместно с другими атрибутами.
Каждому сообщению ставится в соответствие 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 4.1 находится в одном из четырёх состояний.
Большинство команд можно использовать только в определенных состояниях.
В состоянии без аутентификации клиент должен предоставить имя и пароль, прежде чем ему станет доступно большинство команд. Переход в это состояние производится при установлении соединения без предварительной аутентификации.
В состоянии аутентификации клиент идентифицирован и должен выбрать почтовый ящик, после чего ему станут доступны команды для работы с сообщениями. Переход в это состояние происходит при установлении соединение с предварительной аутентификацией, когда выданы все необходимые идентификационные данные или при ошибочном выборе почтового ящика.
В состояние выбора система попадает, когда успешно осуществлен выбор почтового ящика.
В состояние выхода система попадает при прерывании соединения в результате запроса клиента или вследствие независимого решения сервера.
LOGIN
или AUTHENTICATE
SELECT
или EXAMINE
CLOSE
или неудачная команда SELECT
или EXAMINE
LOGOUT
, закрытие сервера, или прерывание соединенияAUTHENTICATE
, сервер отвечает на неё строкой вызова в кодировке base64. Далее клиент должен отправить ответ на вызов сервера о проверке подлинности, также закодированный base64. Если на сервере не поддерживается метод проверки подлинности, предложенный клиентом, он включает в свой ответ слово NO
. После этого клиент должен продолжить переговоры по согласованию метода проверки подлинности. Если все попытки определить метод проверки подлинности потерпели неудачу, то клиент предпринимает попытку зарегистрироваться на сервере посредством команды LOGIN
.\DELETED
, удаляются из него. Не имеет параметров.LIST
используется для получения списка ящиков, активизированных командой SUBSCRIBE
. Параметры — такие же, как у LIST
.STATUS
может использоваться для получения информации о состоянии почтового ящика без его открытия с помощью команд SELECT
или EXAMINE
.MESSAGES
— общее число сообщений в почтовом ящикеRECENT
— число сообщений с флагом \recent
UIDNEXT
— идентификатор UID, который будет назначен новому сообщениюUIDVALIDITY
— уникальный идентификатор почтового ящикаUNSEEN
— число сообщений без флага \seen
\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
. Эта команда используется без параметров.\DELETED
, при этом почтовый ящик не закрывается. Ответ сервера на команду EXPUNGE
представляет собой отчёт о новом состоянии почтового ящика.FETCH
, COPY
, STORE
или SEARCH
. С её помощью в этих командах можно использовать реальные идентификационные номера UID вместо последовательности чисел из диапазона номеров сообщений.NOOP
всегда должен быть положительным. Так как сервер часто в ответе возвращает состояние выполнения той или иной команды, то NOOP
вполне можно использовать как триггер для периодического запроса о состоянии сервера.Эту статью следует викифицировать. |
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .