Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача

Вид материала

Задача

Содержание 5. Команды клиента S: * capability imap 4.1 auth=kerberos_v4 S: * 22 expunge 5.2. Команды клиента – в состоянии без аутентификации C: a001 authenticate kerberos_v4

Подобный материал:

• Поурочне планування курсу "Основи Інтернет – технологій", 88.8kb.
• Работа nat введение, 150.17kb.
• 1. Сервіси Internet, 731.38kb.
• 1. Сервіси Internet, 347.99kb.
• Internet Information Services (iis). Понимание организации сетей, tcp/ip и Domain Name, 17.07kb.
• Что такое Internet? Ресурсы Internet*, 347.7kb.
• Лабораторна робота №19 ”Internet”, 103.46kb.
• Е. Е. Израилевич Практическая грамматика английского языка с упражнениями и ключами, 14711.83kb.
• Математическая логика сквозь школьные предметы, 133.29kb.
• Мифы и реальности Internet известные и скрытые возможности сети Что такое Internet, 306.75kb.

5. Команды клиента

Ниже описаны команды IMAP 4.1. Команды рассматриваются с учетом состояния, в котором они допустимы.

5.1. Команды клиента – любое состояние

Следующие команды могут использоваться в любом состоянии: CAPABILITY, NOOP и LOGOUT.

5.1.1. Команда CAPABILITY

Аргументы: отсутствуют.
Отклики: Необходим немаркированный отклик: CAPABILITY.
Результат: OK – успешное завершение команды;
BAD – команда неизвестна или неверный аргумент<./p>

Команда CAPABILITY запрашивает перечень возможностей, поддерживаемых сервером. Сервер должен послать один немаркированный отклик CAPABILITY с "IMAP 4.1" в списке возможностей, прежде чем отправлять маркированный отклик OK. Этот список не зависит от состояния соединения или пользователя. Следовательно, нет необходимости направлять команду CAPABILITY более одного раза на соединение. Название возможности, которая начинается с "AUTH=" указывает, что сервер поддерживает определенный механизм аутентификации. Все такие имена по определению являются частью данной спецификации. Например, аутентификационные возможности для экспериментального аутентификатора "blurdybloop" могут быть описаны как "AUTH=XBLURDYBLOOP", а не "XAUTH=BLURDYBLOOP" или "XAUTH=XBLURDYBLOOP".

Другие имена возможностей относятся к расширениям, новым версиям или коррекциям данной спецификации.

Пример: C: abcd CAPABILITY
S: * CAPABILITY IMAP 4.1 AUTH=KERBEROS_V4
S: abcd OK CAPABILITY completed

5.1.2. Команда NOOP

Аргументы: отсутствуют.
Отклики: никакого специального отклика на эту команду не требуется.
Результат: OK – команда успешно завершена;
BAD – команда неизвестна или неверен аргумент;
Команда NOOP ничего не делает и всегда успешно завершается.

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

Пример: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

5.1.3. Команда LOGOUT

Аргументы: отсутствуют.
Отклики: необходим немаркированный отклик BYE.
Результат: OK – прерывание сессии завершено;
BAD – неизвестная команда или неверный аргумент.

Команда LOGOUT информирует сервер о том, что клиент прерывает соединение. Сервер должен послать немаркированный отклик BYE, прежде чем отсылать маркированный отклик OK, после чего завершить разрыв соединения.

Пример: C: A023 LOGOUT
S: * BYE IMAP 4.1 Server logging out
S: A023 OK LOGOUT completed
(Сервер и клиент разорвали соединение)

5.2. Команды клиента – в состоянии без аутентификации

В состоянии без аутентификации, команды AUTHENTICATE или LOGIN организуют аутентификацию и переводят систему в состояние с аутентификацией. Об аутентификации в IMAP можно прочесть в документе RFC-1731. Команда AUTHENTICATE предоставляет общий механизм для целого ряда методов аутентификации, среди которых команда LOGIN используется для традиционного ввода имени и пароля в текстовом виде.

Различные реализации сервера могут позволять доступ без аутентификации к некоторым почтовым ящикам. По договоренности в этом случае команда LOGIN предполагает ввод имени "anonymous". Ввод пароля всегда обязателен. Требования на пароль определяются конкретной версией программной реализации.

По завершении аутентификации невозможно вернуться непосредственно в состояние “без аутентификации”. В дополнение к универсальным командам (CAPABILITY, NOOP и LOGOUT), в состоянии “без аутентификации” возможны команды: AUTHENTICATE и LOGIN.

5.2.1. Команда AUTHENTICATE

Аргументы: имя механизма аутентификации.
Отклики: может быть запрошена дополнительная информация.

Результат	OK	Аутентификация завершена, осуществлен переход в состояние "аутентификация выполнена";
NO	Ошибка аутентификации: неподдерживаемый механизм аутентификации, параметры аутентификации отвергнуты;
BAD	Неизвестная команда или неверный аргумент, механизм аутентификации прерван.

Команда AUTHENTICATE указывает серверу на механизм аутентификации, как это описано в [IMAP-AUTH]. Если сервер поддерживает запрошенный механизм аутентификации, он выполняет обмен согласно аутентификационному протоколу и идентифицирует клиента. Он может также согласовать опционный механизм защиты для последующих протоколов взаимодействия. Если запрошенный механизм аутентификации не поддерживается, сервер должен отвергнуть команду AUTHENTICATE путем посылки маркированного отклика NO.

Протокол аутентификационного обмена состоит из последовательности запросов сервера и соответствующих ответов клиента. Запрос сервера состоит из отклика-запроса продолжения с символом "+", за которым следует строка кодов BASE64. Ответ клиента состоит из строки, содержащей коды BASE64. Если клиент хочет аннулировать аутентификационный обмен, он выдает строку, содержащую только "*". Если сервер получает такой ответ, он должен отклонить команду AUTHENTICATE, послав маркированный отклик BAD.

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

Аутентификационные механизмы являются опционными. Механизмы защиты также опционны; аутентификационный механизм может реализоваться в отсутствии какого-либо механизма защиты. Если команда AUTHENTICATE не прошла и получен отклик NO, клиент может совершить повторную попытку, послав еще одну команду AUTHENTICATE, или может попытаться выполнить аутентификацию с помощью команды LOGIN. Другими словами, клиент может затребовать тип аутентификации в порядке понижения уровня предпочтения, команда LOGIN используется как последний вариант.

Пример: S: * OK KerberosV4 IMAP4rev1 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful