Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

3.2.1. Формат ответа

Ответы состоят из отображаемых символов кода ASCII. Каждый ответ заканчивается символом . Максимальная длина ответа, включая символы , составляет 512 символов.

Ответ состоит из индикатора статуса и последующего текста ответа.

Индикатор статуса может принимать значения либо "+OK" либо "-ERR". Буквы в индикаторе статуса должны быть заглавными. Ответы с индикатором статуса "+OK" называются положительными, ответы с индикатором статуса "-ERR" называются отрицательными.

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

Исключением является ответ "готов" сервера при идентификации клиента по команде AUTH.

Ответы могут быть однострочными и многострочными. В многострочных ответах строки отделяются символами . Последняя строка многострочного ответа состоит из заключительного октета (с десятичным кодом 46 (".")) и символов . Если строка многострочного ответа начинается с символа "," , в начало этой строки добавляется еще один символ ".". Таким образом критерием конца многострочного ответа является последовательность "CRLF.CRLF". Оконечная последовательность ".CLRF" не считается частью многострочного ответа.

На нереализованные или нераспознанные команды сервер должен отвечать отрицательным ответом. На команды, неразрешенные в данном состоянии, сервер должен отвечать отрицательным ответом.

3.2.2. Список ответов с фиксированной структурой текста ответа.

Список ответов с фиксированной структурой текста ответа приведен в табл. 2

Таблица 2

Список ответов с фиксированной структурой текста ответа

4. Синтаксис команд и ответов

В приведенном ниже определении синтаксиса команд и ответов сервера POP3 используется расширенная форма Наура-Бекуса, приведенная в рекомендации RFC 822[2].

Замечание: в качестве разделителя в конструкции "#" используется один пробел и не используются запятые. В случае противоречия в приведенных определениях должно использоваться правило, указанное выше по списку. Различие между строчными и прописными символами алфавита является несущественным.

; Команда

::= "STAT"

| "LIST" [ ]

| "RETR"

| "DELE"

| "NOOP"

| "RSET"

| "QUIT"

| "TOP"

| "UIDL" [ ]

| "USER"

| "PASS"

| "APOP"

| "AUTH"

; Примечание 1: регистр символов в ключевых словах "STAT", "LIST", …,

; "AUTH" не имеет значения

; Ответ

::= ; Однострочный ответ

| ; Многострочный ответ

::= ; Приветствие

| ; Статус

| ; Однострочный ответ

; "скан-список"

| ; Однострочный ответ

; "список идентификаторов"

| ; Простой положительный ответ

| ; Простой отрицательный ответ

| ; Ответ сервера на команду AUTH

::= ; Многострочный скан-список

| ; Сообщение

| ; Верхняя часть сообщения

| ; Список идентификаторов сообщений

; Примечание 2: длина строк ответа должна составлять не более 512

; символов включая

::= "+OK" [ ]

::= "+OK" ; Количество сообщений

; в почтовом ящике

; Размер почтового ящика

::= "+OK" ; Номер сообщения

; Размер сообщения

::= "+OK" ; Номер сообщения

; Идентификатор сообщения

::= "+OK" ; произвольный текст

::= "-ERR" ; произвольный текст

::= "+" <строка BASE64> ; произвольный текст

::= "+OK"

1* ( ; Номер сообщения

; Размер сообщения

)

"."

::= "+OK"

1* ( ) ; Строки почтового сообщения

”."

::= "+OK>

1* ( ) ; Строки заголовка

1* ( ) ; Начальные строки сообщения

"."

::= "+OK"

1* ( ; Номер сообщения

; Идентификатор сообщения

)

"."

::= <метка времени в соответствии с RFC 822[2]>

::=

::=

::= 2*( PRINT_ASCII | )

| (EXCEPT_POINT_ASCII | )

::= *( PRINT_ASCII | )

::= 1*40

::= 1*40

::=

::= символ возврата каретки (код ASCII 13)

::= символ следующей строки (код ASCII 10)

::= символ пробела (код ASCII - 32)

::=

::= <печатный символ ASCII>

::= <печатный символ ASCII, кроме символа ".">

: : = <идентификатор в соответствии RFC1731[6]>

5. Требования к реализации сервера

5.1. Механизм ограничения объема хранящихся сообщений

В сервере может быть реализован механизм ограничения объема хранящихся сообщений.

5.2. Механизм удаления сообщений, хранящихся дольше установленного срока

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

Приложение 3

Технические требования к техническим средствам службы электронной почты по протоколу imap4

1. Область применения

Настоящее приложение описывает технические требования к ТС службы ЭП по протоколу IMAP4 в соответствии с RFC 822 [2], RFC 1733[7] и RFC 2045 [8].

В приложении приведены операции создания, удаления и переименования почтовых ящиков, проверки на наличие новых сообщений, удаления сообщений после прочтения, установки и снятия флагов, разбора сообщений в соответствии со стандартами RFC 822 [2] и RFC 2045 [8], поиска, избирательной выдачи атрибутов и текста сообщений, а также их частей. Доступ к сообщениям организован с использованием либо последовательных номеров сообщений (относительная позиция сообщения в почтовом ящике), либо уникальных идентификаторов (постоянных, последовательно увеличивающихся значений, выделяемых для каждого сообщения).

Не все функции, содержащиеся в данном приложении, обязательны для ТС служб ЭП по протоколу IMAP4, но если они выполняются, то их реализация должна соответствовать настоящему приложению.

2. ФункциОнальные требования к взаимодействию клиента IMAP4 и сервера IMAP4

2.1. Соединения

2.1.1. Протокол нижнего уровня

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

2.1.2. Общая структура протокола

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

2.1.3. Соответствие команд и ответов

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

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

В ответах без тега вместо тега должен следовать символ "*" или символ "+".

2.2. Состояния

Сервер может находиться в одном из 4-х состояний:

Non-Authenticated ("не идентифицирован”);

Authenticated ("идентифицирован");

Selected ("выбран");

Logout ("разъединение").

Для каждого состояния существует свой набор разрешенных команд. На запрещенную команду сервер должен выдавать ответ результата выполнения команды BAD или NO. Диаграмма типовых переходов состояний приведена на рис. 1.

Рисунок 1. Диаграмма типовых переходов состояний

На рис. 1 цифрами обозначены:

1 - соединение без преидентификации (приветствие ОК),

2 - соединение с преидентификацией (приветствие PREAUTH),

3 - отвергнутое соединение (приветствие BYE),

4 - успешное выполнение команды LOGIN или AUTHENTICATE,

5 - успешное выполнение команды SELECT или EXAMINE,

6 - команда CLOSE или неудачное выполнение команд SELECT или EXAMINE,

7 - команда LOGOUT, сервер закрыт или соединение закрыто.

2.2.1. Состояние "не идентифицирован"

Сервер входит в состояние "не идентифицирован" после установления соединения, если только соединение не является преидентифицированным.

2.2.2. Состояние "идентифицирован"

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

2.2.3. Состояние "выбран"

Сервер входит в это состояние после того, как почтовый ящик успешно выбран.

2.2.4. Состояние "отсоединено"

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

2.3. Элементы функционирования сервера

2.3.1. Наименование почтовых ящиков

Имя почтового ящика INBOX является специальным именем, зарезервированным для "первичного почтового ящика данного пользователя на данном сервере".

2.3.2. Иерархическое именование почтовых ящиков

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

2.3.3. Размер почтового ящика и обновления статуса сообщений.

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

2.3.4. Ответы при отсутствии выполняемых в данное время команд.

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

Характеристики

Список файлов стандарта