IMSP (Internet Message Support Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 11:05, 7 декабря 2017.
IMSP
Международный стандарт: Internet Message Support Protocol
Уровень (по модели OSI): Прикладной
Семейство: стек протоколов TCP/IP
Порт/ID: 406/TCP
Назначение протокола: Доступ к почтовым ящикам
Спецификация: IMSP
Основные реализации (клиенты): MUA (Outlook Express, Opera, Mozilla Thunderbird, The Bat!, Claws Mail, mutt)
Основные реализации (серверы): Horde,
Mulberry ,
SquirrelMail
Вступил в силу с: 1995

IMSP (англ. Internet Message Support Protocol) - это протокол поддержки интернет-сообщений. Этот протокол создан в 1995 и в основу его работы положено то, что:

  • Internet Message Support Protocol предназначен для поддержки работы электронной почты в средних и крупных масштабах вычислений.
  • Также протокол предназначен для использования в качестве компаньона для протокола IMAP4 и для предоставление услуг, которые находятся вне доступа к почте или которые относятся к средам (в которых работают более одного протокола IMAP4 в одном домене электронной почты).
  • Услуги протокола IMSP - это, прежде всего, расширенное управление почтовыми ящиками, параметрами конфигурации и адресными книгами.
  • Работы по стандартизации IMSP не были завершены, поскольку всё ещё не до конца развит ACAP протокол, который включает IMSP функциональность.[Источник 1]


Реализации

  • В IMSP-сервер доступен для загрузки с расширением файлов .CMU.
  • В Horde (программное обеспечение) платформы PHP и IMSP-приложений поддержки.
  • Mulberry (почтовый клиент) поддерживает IMSP-хранение почты, настроек и адресных книг.
  • Silkymail (прекращён) поддерживает IMSP-хранения почты, настроек и адресных книг. Адресные книги были общими с Mulberry.
  • Simeon (почтовый клиент) (прекращён) поддерживает хранение настроек и адресных книг.
  • В IMSP адресной книге плагин доступен в SquirrelMail

Преимущества

Не все IMAP клиенты предлагают поддержку offline режима, но протокол позволяет сделать это в полной мере. Для IMAP существует протокол-компаньон, предназначенный для управления настройками пользователей через IMSP, который позволяет независимый от расположения (многоплатформенный) доступ к персональным настройкам пользователя, например к адресной книге. Его потомок ACAP позволяет хранить также настройки для серверов, групп пользователей. ACAP специально оптимизирован для уменьшения количества пересылаемых по сети данных, имеет богатые возможности по поиску на стороне сервера, позволяет управлять правами доступа к данным.

Структура протокола

В IMSP, использующем порт 406, поток данных предоставляется через TCP, что является безопасным. После установления соединения с клиентским сервером сервер ожидает ответа.

Отметим отдельно, что протоколы POP3 и IMAP не занимаются непосредственно пересылкой почты. Эту процедуру выполняет стандартный протокол SMTP. Он прост и надежен, и с успехом выполняет возложенные на него задачи. Кроме того, при использовании IMAP его работу сопровождает протокол IMSP, который отвечает за конфигурацию работы IMAP.

Существует три типа ответов сервера:

OK (успех)

NO (отказ)

BAD (непризнанная команда или синтаксическая ошибка)

Типичный сценарий

           Client                          Server
           ------                          ------
                                       {Wait for Connection}
       {Open Connection}        -->
                                   <-- * OK IMSP Server Ready
                                       {Wait for command}
       A001 LOGIN Fred Secret   -->
                                   <-- A001 OK User Fred logged in
                                       {Wait for command}
       A002 LIST "" INBOX        -->
                                   <-- * LIST () (imap3.do.main) NIL INBOX
                                   <-- A0002 OK List complete
                                       {Wait for command}
       A003 SUBSCRIBE comp.mail.mime      -->
                                   <-- A003 OK Subscribe complete
                                       {Wait for command}
       A004 LOGOUT              -->
                                   <-- * BYE IMSP server quitting
                                   <-- A004 OK Logout complete
       {Close Connection}       --><-- {Close connection}
                                       {Go back to start}

Сервер отвечает непомеченным ответом «OK» или «PREAUTH» и ждет, пока клиент установит соединение. Вы можете отправлять команды ответа клиента с сервера, не дожидаясь ответа сервера на каждую команду. Сервер отправляет ответы вместе, если задано. Поскольку клиент отправляет команды, которые не ждут ответа от сервера, на команду, отправленную клиентом сервера, нельзя полагаться, если тег не отвечает на ярлык.

Сеанс IMSP включает в себя установление соединения клиент / сервер, мгновенный отклик с сервера и взаимодействие между сервером и клиентом. Эти взаимодействия между сервером и клиентом состоят из команды клиента, данных сервера и ответа терминатора сервера. Серверные и клиентские интерактивные сообщения находятся в последовательной структуре. Клиентский или серверный считыватель IMSP считывает октетные последовательности в известном числе, за которым следует либо последовательность, либо последовательность.

Правило отправителя клиента и правило приемника сервера

Каждая клиентская команда имеет префикс дескриптора, называемый «teg» (обычно это маленький буквенно-цифровой символ, такой как A0001, A0002). Клиент использует другой тег для каждой команды, а последовательная структура, отправленная клиентом, не определяет точную команду. Если сервер готов к команде, он отправляет запрос завершения команды в ответ. Этот ответ берет знак «+». Если сервер обнаруживает ошибку команды, клиент отправляет ответ «BAD» и соответствующий тег. Это отменит команду и позволит клиенту не отправлять продолжение команды. Сервер IMSP извлекает клиентский протокол из клиента и возвращает ответ сервера и серверный ответ завершения сервера, разделяя команды и их аргументы.

Автоматическое закрытие сеанса

Сервера неактивных сессий автоматически закрываются по истечении 30 минут. В этот промежуток времени любые команды от клиента отменяют таймер на получение автоматического выключения сеанса.

Правила отправки отправителем и получателем

  • Данные, отправленные клиенту сервером и ответы на состояние без дополнения команды, помечены как «*» в качестве префикса и называются непомеченными ответами.
  • Данные сервера могут быть отправлены в результате команды клиента или в одностороннем порядке сервером. Между двумя представлениями нет синтаксической разницы.
  • Сценарий сервера определяет ответ на результат дополнения как успех или неудачу и имеет ту же этику, что и клиентская команда, инициировавшая операцию. Из-за этого тег в ответе на сервер определяет команду, к которой применяется ответ. Возвращается один из трех типов дополнительных ответов сервера (OK, NO и BAD). Клиент IMSP считывает ответ с сервера, устанавливает ответ покупателя и отвечает в соответствии с префиксом ответа.
  • Клиент всегда должен быть готов принять серверные ответы, включая данные сервера, которые запрос не отправляет.
  • Данные сервера сохраняются и не должны отправлять запрос данных на клиентский сервер, а сохраненная копия может отображаться как ссылка.

Диаграмма состояния и потока

Сервер IMSP можно найти в трех разных ситуациях, и большинство команд действительны в определенных ситуациях. Команда, отправленная клиентом в неудовлетворительном состоянии, вызывает ошибку правила. В этом случае сервер будет возвращать «BAD» или «NO» в зависимости от серверного приложения. Не аутентифицированное состояние - это тот, где большинство разрешений для команд не существует. Он охватывает время, прошедшее между установлением соединения и аутентификацией. В случае аутентификации большинство команд разрешены. В другом случае это состояние выключения. В случае выхода из системы сеанс завершается, и сервер отключается. Это вводится либо по желанию клиента, либо по одностороннему решению сервера. IMSP использует команды и ответы в виде текста. Данные IMSP могут быть атомом, числом, символьной строкой, списком в скобках или NIL.

Отправлять ответ, когда нет команд

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

Обработка нескольких команд

Клиенту не нужно ждать команды ответа на завершение результата для отправки новой команды. Поток в основном потоке данных зависит от ограничений управления. Аналогичным образом серверу не нужно ждать, пока следующая команда будет обработана для отправки команды фиксации, за исключением неопределенности, вызванной командой, которая повлияет на результаты других команд. Если такая неоднозначность существует, сервер будет управлять командой commit в соответствии с порядком, в котором выдается команда клиента.

Задержка протокола IMAP4 (правило последнего разрешения IMAP4)

Если клиент маршрутизируется пользователем или создает экземпляр для связи с почтовым ящиком на данном хост-компьютере, он должен сначала попытаться обратиться к службе IMSP на этом хост-компьютере. В этом случае клиент должен использовать команды администрирования почтового ящика IMSP вместо команд администрирования электронной почты IMAP4. Если IMSP не может подключиться к серверу из-за нежелательного соединения, клиент должен использовать правило IMAP4.[Источник 2]

Основные команды и тэги

Базовая функциональность

NOOP

  • Команда NOOP

Возвращает OK клиенту. Сама по себе ничего не делает, есть побочные эффекты.

LOGIN

  • Команда LOGIN user password

Идентифицирует пользователя на сервере и переносит пароль, аутентифицирующий этого пользователя. Эта информация используется сервером для управления доступом к командам.

LOGOUT

  • Команда LOGOUT

Информирует сервер о том, что клиент вышел из сессии. Cервер будет ожидать ответа BYE, затем OK от клиента и закроет подключение.

Расположение сервера и новая информация о сообщении

LIST

  • Команда LIST reference mailbox

Принимает в качестве аргументов имя ссылки, за которым следует имя почтового ящика, включая возможные подстановочные знаки, которые указывают некоторое подмножество имен из полного набора всех имен, доступных для пользователя. Возвращает 0.

      EXAMPLE:  C: A002 LIST "~/Mail/" "%"
                S: * LIST (\Noselect) (imap1.do.main) "/" ~/Mail/foo
                S: * LIST () (imap1.do.main) "/" ~/Mail/meetings
                S: A002 OK LIST completed

LSUB

  • Команда LSUB reference mailbox

Принимает в качестве аргументов имя ссылки, за которым следует имя почтового ящика, включая возможные подстановочные знаки, которые указывают некоторое подмножество из набора имен, объявленных пользователем как «активный» или «подписанный». Нулевые или немаркированные LSUB ответы возвращаются.

      EXAMPLE:  C: A002 LSUB "#news." "comp.mail.*"
                S: * LSUB () (imap5.do.main) "." #news.comp.mail.mime
                S: * LSUB () (imap7.do.main) "." #news.comp.mail.misc
                S: A002 OK LSUB completed

UNSEEN

  • Команда UNSEEN reference mailbox

Принимает в качестве аргументов последующее ссылочное имя по имени почтового ящика, включая возможные подстановочные знаки, которые указывают некоторое подмножество из набора имен, объявленных пользователем как «активный» или «подписанный».

ADDRESSBOOK

  • Команда ADDRESSBOOK pattern

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

LAST

  • Команда LAST mailbox uid

Когда пользователь просматривает все сообщения в почтовом ящике и затем переключается между почтовыми ящиками или закрывает соединение, сервер IMAP уведомляет IMSP-сервер UID последнего сообщения, которое пользователь прочитал. Это также можно сделать с использованием расширения IMSP.

SEEN

  • Команда SEEN mailbox uid user

Когда пользователь просматривает почтовый ящик с прочитанными сообщениями, сервер IMSP может проверять атрибут последнего сообщения для пользователя против атрибута сообщения, добавленного к почтовому ящику.      

Управление подпиской

SUBSCRIBE

  • Команда SUBSCRIBE mailbox

Добавляет указанное имя почтового ящика в список «активных» или «подписанных» почтовых ящиков. Эта команда возвращает ответ OK, если подписка прошла успешно.

UNSUBSCRIBE

  • Команда UNSUBSCRIBE mailbox

Удаляет указанное имя почтового ящика из списка «активных» или «подписанных» почтовых ящиков, возвращенных LSUB. Эта команда возвращает ответ OK, если отказ от подписки прошёл успешно. Неподписанные имена должны сохраняться между сеансами.

Управление почтовыми ящиками

CREATE

  • Команда CREATE mailbox

Создает почтовый ящик с заданным именем. Эта команда возвращает ответ OK, если новый почтовый ящик с этим именем был создан. Любая ошибка в создании возвратит ответ NO. Ошибка произойдёт при попытке создать почтовый ящик с именем, которое ссылается на существующий почтовый ящик. .

      EXAMPLE:  A002 CREATE FOOBAR (imap2.do.main/a imap4.do.main)
                A002 OK Create completed

RENAME

  • Команда RENAME oldmailbox newmailbox

Изменяет имя почтового ящика. Эта команда возвращает ответ OK, если существует почтовый ящик со старым именем и был успешно переименован в новое имя. Ошибка произойдет при попытке переименовании имени старого почтового ящика, которое не существует или новое имя почтового ящика, которое уже существует.

DELETE

  • Команда DELETE mailbox

Удаляет почтовый ящик с заданным именем. Эта команда возвращает ответ OK, только если почтовый ящик с таким именем был удален. Ошибка произойдет при попытке удалить почтовый ящик имя которого не существует. Удаление INBOX запрещено.

Ссылки

Источники

  1. IMSP // Wikipedia. [2015-2017]. Дата обновления: 21.11.2015. URL: https://en.wikipedia.org/wiki/IMSP (дата обращения: 22.11.2017).
  2. IMSP // Журнал BIDB. [2015-2017]. Дата обновления: 02.03.2015. URL: http://tercih.itu.edu.tr/seyirdefteri/blog/2013/09/06/imsp-(internet-message-support-protocol) (дата обращения: 24.11.2017).