РД 45.134-2000, часть 3
2 . Функциональные требования к взаимодействию клиента POP3 и сервера POP3.
2 .1. Соединения
2 .1.1. Протокол нижнего уровня
Для организации соединения клиента и сервера должен использоваться протокол TCP. На стороне сервера должен использоваться порт 110.
2 .1.2. Общая структура протокола
Сессия протокола POP3 состоит из установления соединения клиент/сервер, начального приветствия от сервера и взаимодействия клиент/сервер. В ходе сессии сервер и клиент обмениваются сообщениями. Сообщения разделяются на команды клиента и ответы сервера. В ответы сервера включаются данные, передаваемые сервером клиенту и результаты выполнения команд. Все сообщения передаются клиентом и сервером в форме строк, заканчивающимися символом <CRLF>.
2.2. Взаимодействие
2.2.1. Состояния сервера
В сервере должны быть реализованы следующие состояния:
AUTHORIZATION
TRANSACTION
UPDATE
Типичная последовательность переходов состояний сервера показана на рис. 1.
2.2.1.1. Сервер должен находиться в состоянии AUTHORIZATION после установления соединения TCP и выдачи им ответа приветствия.
Если процесс идентификации прошел успешно (т. е. клиент может получить доступ к соответствующему почтовому ящику), сервер открывает почтовый ящик и переходит в состояние TRANSACTION. При этом все метки удаления почтовых сообщений сброшены.
Если происходит ошибка при открытии почтового ящика, сервер отвечает отрицательным сообщением. После отрицательного ответа сервер может закрыть соединение. В случае, если соединение не закрыто, в сервере должны быть реализованы повторная идентификация и команда QUIT.
После того, как сервер открыл почтовый ящик, для каждого почтового сообщения должен быть выделен номер, начиная с 1. Номера должны последовательно возрастать на 1. В командах и ответах номера почтовых сообщений должны быть представлены в десятичном формате.
В состоянии AUTHORIZATION должны быть реализованы команды как минимум одного из механизмов идентификации, приведенных в п. 3.3.2., и команда QUIT.
Рис. 1 Типичная последовательность состояния сервера
2.2.1.2. Состояние TRANSACTION
Сервер переходит в состояние TRANSACTION в случае успешной идентификации клиента и успешного открытия почтового ящика.
Если сервер получает команду QUIT, он должен перейти в состояние UPDATE.
В состоянии TRANSACTION должны быть реализованы следующие команды: STAT, LIST, RETR, DELE, NOOP, RSET, QUIT.
2.2.1.3. Состояние UPDATE
Сервер переходит в состояние UPDATE в случае получения команды QUIT в состоянии TRANSACTION. В состоянии UPDATE (и только в этом состоянии) сервер удаляет из почтового ящика сообщения, помеченные как удаленные.
2.2.2. Механизмы идентификации клиента
В сервере могут быть реализованы следующие механизмы идентификации клиента:
с помощью команд USER и PASS
с помощью команды APOP
с помощью команды AUTH ( дополнительный механизм идентификации)
2.2.2.1. На сервере должен быть реализован механизм идентификации с помощью команд USER и PASS. Команда PASS должна следовать непосредственно за командой USER. Формат команд USER и PASS описан в п. 4.1. настоящего Руководящего Документа.
2.2.2.2. Механизм идентификации с помощью команды APOP позволяет избежать посылки пароля по сети. Сервер, в котором реализована команда APOP, должен в сообщение приветствия включить метку времени. Должна обеспечиваться уникальность метки времени для каждого сообщения приветствия, выдаваемого сервером.
Клиент должен запомнить последнюю присланную ему метку времени и использовать ее в команде APOP.
Формат команды APOP: APOP < name> < digest>
Более подробно формат команды описан в п. 4.1. настоящего Руководящего Документа.
Значение параметра name такое же, как в команде NAME. Параметр digest должен вычисляться согласно алгоритму MD5 в соответствии с RFC 1321[5] , применяемому к метке времени и следующей за ней строке пароля. Параметр digest должен иметь формат 16-октетного числа в 16-ричном формате, представленного в ASCII - коде, используя строчные буквы.
Получая команду APOP, сервер должен проверить соответствие параметра digest. В случае соответствия выдается положительный ответ, и сервер переходит в состояние TRANSACTION. В случае несоответствия сервер выдает отрицательный ответ и остается в состоянии AUTHORIZATION.
2.2.2.3. Механизм идентификации с помощью команды AUTH.
Механизмы идентификации и защиты, используемые командой AUTH в протоколе POP3 должны быть аналогичны используемым в протоколе IMAP4 и соответствовать RFC 1731[6], 1734[4] .
Формат команды AUTH описан в п. 4.1. настоящего Руководящего Документа.
Команда передает серверу параметр с указанием, какой механизм идентификации должен быть использован. Если в сервере поддерживается запрошенный механизм, сервер производит обмен сообщениями с клиентом для идентификации пользователя. Также может быть выполнено согласование механизма защиты для последующих сессий.
В случае, если команда AUTH не поддерживается, сервер должен послать отрицательный ответ.
Обмен сообщениями протокола идентификации состоит из серий вызовов, исходящих от сервера, и ответов клиента, являющихся специфичными для каждого механизма идентификации. В качестве вызова сервера используется ответ "готов". Вызов сервера должен иметь формат строки в коде BASE64 с первым символом "+". Ответ клиента должен иметь формат строки в коде BASE64. Ответ клиента "*" вызывает прерывание процедуры идентификации и последующий отрицательный ответ сервера.
Если установлен механизм защиты, он применяется ко всем последующим пересылкам данных по соединению. Механизм защиты должен активизироваться сразу после получения символа <CRLF> положительного ответа сервера после обмена сообщениями протокола идентификации. При активном механизме защиты потоки символов команд и ответов преобразуются в зашифрованные буферы. Каждый буфер передается как поток октетов, которому предшествует 4-х октетное поле длины последующих данных. Максимальная длина шифрованного буфера определяется механизмом защиты.
2.2.3. В сервере может быть реализован таймер разъединения по отсутствию активности. Установленное время таймера разъединения по отсутствию активности должно быть как минимум 10 минут. Получение любой команды должно сбрасывать таймер. При закрытии сессии по отсутствию активности сервер:
- не должен входить в состояние UPDATE,
- не должен удалять сообщения,
- не должен посылать ответ клиенту.
3 . Перечень и структура сообщений
Все сообщения протокола POP3 должны быть стандартными текстовыми сообщениями в соответствии с RFC822 [2] .
3.1. Команды
Сообщения, посылаемые от клиента серверу, называются командами.
3.1.1. Структура команд
Команды состоят из печатных символов кода ASCII. Структура команды:
ключевое слово
один или более аргументов (могут отсутствовать)
символ <CRL F>
Ключевое слово и аргументы, а также аргументы между собой разделяются одним символом <SP> (пробел).
Максимальная длина аргумента составляет 40 символов.
Длина ключевого слова составляет 3 или 4 символа.
3.1.2. Перечень команд
Перечень команд приведен в табл. 1.
Таблица 1
Перечень команд
|
Команда |
STAT |
|
Аргументы |
- |
|
Описание |
Информация о статусе почтового ящика. |
|
Возможные ответы |
+OK < статус> |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
LIST [< msg> ] |
|
Аргументы |
msg - номер сообщения. Не должен ссылаться на удаленное сообщение. |
|
Описание |
Если указан аргумент, сервер высылает положительный однострочный ответ с информацией о данном сообщении. Если нет сообщения с таким номером, выдается отрицательный ответ. Если аргумент не указан, сервер высылает положительный многострочный ответ с информацией обо всех сообщениях в почтовом ящике. В случае, если почтовый ящик пуст, выдается положительный ответ, состоящий только из ". CRLF". |
|
Возможные ответы |
+OK < скан-список> -ERR |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
RETR < msg> |
|
Аргументы |
msg - номер сообщения |
|
Описание |
Сервер высылает положительный многострочный ответ с сообщением, соответствующим указанному номеру. |
|
Возможные ответы |
+OK < верх сообщения> -ERR |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
DELE < msg> |
|
Аргументы |
msg - номер сообщения |
|
Описание |
Сервер помечает сообщение как удаленное. Команда с аргументом, указывающим на несуществующее сообщение, либо на уже удаленное сообщение, вызывает отрицательный ответ. |
|
Возможные ответы |
+OK -ERR |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
NOOP |
|
Аргументы |
- |
|
Описание |
Нет операции |
|
Возможные ответы |
+OK |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
RSET |
|
Аргументы |
- |
|
Описание |
Сбрасываются все метки удаленных сообщений |
|
Возможные ответы |
+OK |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
QUIT |
|
Аргументы |
- |
|
Описание |
Удаление всех сообщений, отмеченных как удаленные из почтового ящика, закрытие почтового ящика и разрыв соединения TCP. Если при удалении сообщений возникает ошибка, выдается сообщение об ошибке. |
|
Возможные ответы |
+OK -ERR |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
QUIT |
|
Аргументы |
- |
|
Описание |
Разрыв соединения TCP. |
|
Возможные ответы |
+OK
|
|
Разрешенные состояния |
AUTHORIZATION |
|
Команда |
TOP < msg> < n> |
|
Аргументы |
msg - номер сообщения n - число строк (положительное чмсло либо равное 0) |
|
Описание |
Сервер выдает положительный многострочный ответ, включающий: заголовок сообщения, пустую строку, указанное число строк сообщения. |
|
Возможные ответы |
+OK < ответ> -ERR |
|
Разрешенные состояния |
AUTHORIZATION |
|
Команда |
UIDL [< msg> ] |
|
Аргументы |
msg - номер сообщения |
|
Описание |
В случае, если аргумент задан, сервер выдает однострочный положительный ответ "unique-id listening" для почтового сообщения с указанным номером. Если аргумент не задан, сервер выдает многострочный положительный ответ, состоящий из - первой строки +OK, - строк "unique-id listening" для каждого сообщения в почтовом ящике. Отрицательный ответ выдается в случае отсутствия сообщения с указанным номером. |
|
Возможные ответы |
+OK < список uid> -ERR |
|
Разрешенные состояния |
TRANSACTION |
|
Команда |
USER < name> |
|
Аргументы |
name - идентификатор почтового ящика |
|
Описание |
Идентификатор почтового ящика. Используется в механизме идентификации по комбинации команд USER PASS. Положительный ответ выдается, если существует почтовый ящик с указанным именем, отрицательный - если такой почтовый ящик отсутствует. |
|
Возможные ответы |
+OK -ERR |
|
Разрешенные состояния |
AUTHORIZATION |
|
|
|
|
Команда |
PASS < string> |
|
Аргументы |
string - пароль почтового ящика |
|
Описание |
Пароль почтового ящика Используется в механизме идентификации по комбинации команд USER PASS. Положительный ответ выдается, если клиенту позволен доступ к соответствующему почтовому ящику, и отрицательный - в противном случае. |
|
Возможные ответы |
+OK -ERR |
|
Разрешенные состояния |
AUTHORIZATION, после выполнения команды USER |
|
Команда |
APOP < name> < digest> |
|
Аргументы |
name - идентификатор почтового ящика digest - строка MD5 |
|
Описание |
Пароль почтового ящика Используется в механизме идентификации по методу " разделяемого секрета" . Положительный ответ выдается, если клиенту позволен доступ к соответствующему почтовому ящику, и отрицательный - в противном случае. |
|
Возможные ответы |
+OK -ERR |
|
Разрешенные состояния |
AUTHORIZATION |
|
Команда |
AUTH < str> |
|
Аргументы |
str - идентификатор идентификационного механизма в соответствии с RFC 1731[6] |
|
Описание |
Команда начала процедуры идентификации по механизму IMAP4 |
|
Возможные ответы |
+OK -ERR |
|
Разрешенные состояния |
AUTHORIZATION |
3 .1.3. Обязательными для реализации являются команды: QUIT, STAT, LIST, RETR, DELE, NOOP, RSET, USER, PASS.
3.2. Ответы
Сообщения, посылаемые от сервера клиенту называются ответами.
3.2.1. Формат ответа
Ответы состоят из отображаемых символов кода ASCII. Каждый ответ заканчивается символом <CRLF>. Максимальная длина ответа, включая символы <CRLF>, составляет 512 символов.
Ответ состоит из индикатора статуса и последующего текста ответа.
Индикатор статуса может принимать значения либо "+OK" либо "-ERR". Буквы в индикаторе статуса должны быть заглавными. Ответы с индикатором статуса "+OK" называются положительными, ответы с индикатором статуса "-ERR" называются отрицательными.
Содержание текста ответа зависит от типа ответа. Для ответов некоторых типов структура текста ответа является существенной. Данные типы ответов приведены в табл. 2. Структура и тексты ответов, не перечисленных в табл. 2 несущественны. Смысловое содержание текста ответа должно соответствовать логическому значению ответа.
Исключением является ответ "готов" сервера при идентификации клиента по команде AUTH.
Ответы могут быть однострочными и многострочными. В многострочных ответах строки отделяются символами <CRLF>. Последняя строка многострочного ответа состоит из заключительного октета (с десятичным кодом 46 (".")) и символов <CRLF>. Если строка многострочного ответа начинается с символа " ," , в начало этой строки добавляется еще один символ ".". Таким образом критерием конца многострочного ответа является последовательность "CRLF.CRLF". Оконечная последовательность ".CLRF" не считается частью многострочного ответа.
На нереализованные или нераспознанные команды сервер должен отвечать отрицательным ответом. На команды, неразрешенные в данном состоянии, сервер должен отвечать отрицательным ответом.
3.2.2. Список ответов с фиксированной структурой текста ответа.
Список ответов с фиксированной структурой текста ответа приведен в табл. 2
Таблица 2
Список ответов с фиксированной структурой текста ответа
|
Ответ: |
Приветствие |
|
Структура |
+OK +OK < timestamp> |
|
Описание |
Сообщение приветствия. Метка времени timestamp должна соответствовать RFC822[2] и должна в ключаться в сообщение, когда реализована команда APOP. |
|
Ответ: |
Статус |
|
Структура |
+OK < nn> <mm> nn - количество сообщений в почтовом ящике mm - размер почтового ящика в октетах |
|
Описание |
Статус почтового ящика |
|
Ответ: |
скан-список |
|
Структура |
+OK < n> < m> ; для однострочного ответа
n - номер сообщения m - точный размер сообщения ________________________________________________________________
+OK ; для многострочного ответа < n> < m> ... < n> < m> .
n - номер сообщения m – точный размер сообщения |
|
Описание |
Данные о сообщении. Точный размер сообщения должен соответствовать размеру передаваемого сообщения, который может отличаться от размера хранимого сообщения. |
|
Ответ: |
Сообщение |
|
Структура |
+OK < line1> ... < linen> .
line1 .. linen - строки почтового сообщения, передаваемые в соответствии с правилами составления многострочного сообщения. |
|
Описание |
Почтовое сообщение. |
|
Ответ: |
верх сообщения |
|
Структура |
+OK < header1> ... < headern >
< line1> ... < linem> .
header1 .. headern - строки заголовка почтового сообщения; line1 .. linem - начальные m строк тела почтового сообщения. При передаче строк заголовка и тела почтового сообщения должны использоваться правила составления многострочного сообщения. |
|
Описание |
Верхняя часть почтового сообщения |
|
Ответ: |
список uid |
|
Структура |
+OK <n> < uidm> ; для однострочного ответа
n - номер сообщения uidm - уникальный идентификатор сообщения ________________________________________________________________
+OK ; для многострочного ответа < n1> < uidm1> ... < nn> <uidmn> .
n - номер сообщения uidm – уникальный идентификатор сообщения
|
|
Описание |
Уникальный идентификатор почтового сообщения. |
|
Ответ: |
" готов" |
|
Структура |
+< строка BASE64 >
|
|
Описание |
Вызов сервера после подачи пользователем команды AUTH |
4. Синтаксис команд и ответов
В приведенном ниже определении синтаксиса команд и ответов сервера POP3 используется расширенная форма Наура-Бекуса, приведенная в рекомендации RFC 822[2] .
Замечание: в качестве разделителя в конструкции "#" используется один пробел и не используются запятые. В случае противоречия в приведенных определениях должно использоваться правило, указанное выше по списку. Различие между строчными и прописными символами алфавита является несущественным.
; Команда
<command> ::= "STAT" <CRLF>
| "LIST" [ <SP> <msg> ] <CLRF>
| "RETR" <SP> <msg> <CLRF>
| "DELE" <SP> <msg> <CLRF>
| "NOOP" <CLRF>
| "RSET" <CLRF>
| "QUIT" <CLRF>
| "TOP" <SP> <msg> <SP> <number> <CLRF>
| "UIDL" [ <SP> <msg> ] <CLRF>
| "USER" <SP> <name> <CLRF>
| "PASS" <SP> <string> <CLRF>
| "APOP" <SP> <name> <SP> <digest>
| "AUTH" <SP> <str>
; Примечание 1 : регистр символов в ключевых словах "STAT", "LIST", …,
; "AUTH" не имеет значения
; Ответ
<answer> ::= <single_line> ; Однострочный ответ
| <multi_line> ; Многострочный ответ
<single_line> ::= <greeting> ; Приветствие
| <status> ; Статус
| <simple_scan_list> ; Однострочный ответ
; "скан-список"
| <simple_uid_list> ; Однострочный ответ
; " список идентификаторов"
| <simple_OK> ; Простой положительный ответ
| <simple_ERR> ; Простой отрицательный ответ
| <ready> ; Ответ сервера на команду AUTH
<multi_line> ::= <scan_list> ; Многострочный скан-список
| <message> ; Сообщение
| <message_top> ; Верхняя часть сообщения
| <uid_list> ; Список идентификаторов сообщений
; Примечание 2: длина строк ответа должна составлять не более 512
; символов включая <CRLF>
<greeting> ::= "+OK" [ <timestamp> ]
<status> ::= "+OK" <SP> <number> ; Количество сообщений
; в почтовом ящике
<SP> <number> ; Размер почтового ящика
<CLRF>
<simple_scan_list> ::= "+OK" <SP> <number> ; Номер сообщения
<SP> <number> ; Размер сообщения
<CLRF>
<simple_uid_list> ::= "+OK" <SP> <number> ; Номер сообщения
<SP> <number> ; Идентификатор сообщения
<CLRF>
<simple_OK> ::= "+OK" <text> <CLRF> ; произвольный текст
<simple_ERR> ::= "-ERR" <text> <CLRF> ; произвольный текст
<ready> ::= "+" <SP> < строка BASE64> ; произвольный текст
<scan_list> ::= "+OK" <CRLF>
1* ( <number> ; Номер сообщения
<SP> <number> ; Размер сообщения
<CRLF>)
"." <CRLF>
<message> ::= "+OK" <CRLF>
1* (<line> <CRLF>) ; Строки почтового сообщения
”." <CRLF>
<message_top> ::= "+OK> <CRLF>
1* (<line> <CRLF>) ; Строки заголовка
<CRLF>
1* (<line> <CRLF>) ; Начальные с троки сообщения
"." <CRLF>
<uid_list> ::= "+OK" <CRLF>
1* ( <number> ; Номер сообщения
<SP> <number> ; Идентификатор сообщения
<CRLF> )
"." <CRLF>
<timestamp> ::= < метка времени в соответствии с RFC 822[2]>
<msg> ::= <number>
<name> ::= <string>
<line> ::= 2*( PRINT_ASCII | <SP> )
| (EXCEPT_POINT_ASCII | <SP>)
<text> ::= *( PRINT_ASCII | <SP> )
<string> ::= 1*40 <PRINT_ASCII>
<number> ::= 1*40 <DIGIT>
<CRLF> ::= <CR> <LF>
<CR> ::= символ возврата каретки (код ASCII 13)
<LF> ::= символ следующей строки (код ASCII 10)
<SP> ::= символ пробела (код ASCII - 32)
< DIGIT> ::= <любая цифра ASCII "0".."9">
<PRINT_ASCII> ::= < печатный символ ASCII>
<EXCEPT_POINT> ::= < печатный символ ASCII, кроме символа ".">
<str> : : = < идентификатор в соответствии 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 состоит из установления соединения клиент/сервер, начального приветствия от сервера и взаимодействия клиент/сервер. В ходе сессии сервер и клиент обмениваются сообщениями. Сообщения разделяются на команды клиента, и ответы сервера. В ответы сервера включаются данные, передаваемые сервером клиенту, и результаты выполнения команд. Все сообщения передаются клиентом и сервером в форме строк, заканчивающихся символами <CRLF>.
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) при отсутствии выполняемых в данное время команд. При реализации подобной возможности в сервере должны быть предусмотрены меры контроля трафика. Должна быть реализована либо проверка, что размер данных не превышает доступный размер окна транспортного протокола нижнего уровня, либо должны использоваться неблокирующие записи.
2.3.5. Таймер автоотсоединения
Если в сервере реализован таймер автоотсоединения, установленное время таймера автоотсоединения должно быть как минимум 30 минут. Получение любой команды от клиента должно сбрасывать таймер автоотсоединения.
2.3.6. Выполнение нескольких команд
От клиента не требуется ждать ответа о результатах выполнения команды перед тем, как отправить следующую команду. Точно так же сервер может не ждать завершения выполнения текущей команды для начала выполнения следующей, кроме тех случаев, когда при одновременном выполнении команд могут возникнуть неоднозначности. В этом случае сервер должен выполнять команды в той последовательности, в которой они получены.
Однако, все ответы на запросы продолжения команды и продолжения команды должны быть согласованы перед инициализацией следующей команды.
2.3.7. Идентификация
Команды AUTHENTICATE и LOGIN запускают процесс идентификации в состоянии Non-authenticated. В сервере может быть реализован неидентифицированный доступ к определенным почтовым ящикам. Для этого должна использоваться команда LOGIN с идентификатором пользователя "anonimus". Наличие пароля является необходимым.
2.3.8. Атрибуты почтового ящика
Должны быть реализованы следующие атрибуты почтового ящика:
\Noinferiors - порожденные уровни не существуют и не могут быть созданы;
\Noselect - невозможно использовать данное имя в качестве выбираемого почтового ящика;
\Marked - почтовый ящик отмечен сервером, как почтовый ящик, в который были добавлены новые сообщения;
\Unmarked - после того, как почтовый ящик был выбран последний раз, в него не были добавлены новые сообщения.
3 . Перечень и структура сообщений протокола IMAP4
3.1. Форматы данных, используемые в сообщениях
Протокол IMAP4 использует текстовые команды и ответы. Данные могут быть представлены в одной из 5 форм:
атом;
число;
строка;
список в скобках;
NIL.
Формальное определение форматов данных приведено в Приложении 5.2.
3.1.1. Строки.
Должны быть реализованы два вида строки: литерал и строка в кавычках.
3 .1.2. Восьмибитные и бинарные строки.
Восьмибитная текстовая и бинарная почта поддерживается с помощью кодирования MIME-IMB (RFC 2045 [8] ). Возможно использование литералов для передачи восьитбитовых или многооктетных символов, но только тогда, когда определен набор символов CHARSET (RFC 1700 [9] ).
Несмотря на существование кодирования BINARY для тела сообщения, некодированные бинарные строки запрещены.