РД 45.134-2000

Минсвязи России

Руководящий документ отрасли

СРЕДСТВА ТЕХНИЧЕСКИЕ ТЕЛЕМАТИЧЕСКИХ СЛУЖБ

ОБЩИЕ ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

РД 45.134-2000

Предисловие

1 РАЗРАБОТАН Ассоциацией Документальной Электросвязи (АДЭ), испытательным центром документальной электросвязи (ИЦ ДЭС), Центральным научно-исследовательским институтом связи, испытательным центром “ЦНИИС”.

ВНЕСЕН Департаментом электросвязи Министерства РФ по связи и информатизации

2 УТВЕРЖДЕН Министерством Российской Федерации по связи и информатизации

3 ВВЕДЕН В ДЕЙСТВИЕ информационным письмом

от 14 июля 2000 г.№ 4316 с 1 августа 2000г.

4 ВВЕДЕН ВПЕРВЫЕ

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящие общие технические требования предназначен для руководства при проведении сертификационных испытаний и инспекционного контроля в системе “Электросвязь” технических средств телематических служб.

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

Настоящие общие технические требования распространяются на технические средства следующих телематических служб:

службы обмена электронными сообщениями в части службы электронной почты (по протоколам SMTP, POP3, IMAP4);

информационные службы в части службы доменных имен (по протоколу DNS), службы доступа к информационным ресурсам (по протоколам HTTP, NNTP, FTP).

Технические требования к техническим средствам факсимильной службы в части службы телефакс определены в РД 45.121-2000.

Технические требования к техническим средствам службы голосовой связи в части службы голосовых сообщений определены в “Общих технических требованиях на оборудование электронных речевых серверов”, утвержденных Госкомсвязи России 24.06.98г.

Технические требования к техническим средствам службы голосовой связи в части службы передачи речевых сообщений определены в РД 45.46-99.

2. НОРМАТИВНЫЕ ССЫЛКИ

3. ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

ASCII - набор символов, определенный в ARPA-Internet Protocol Handbook. В FTP определена нижняя часть восьмибитного кода (старший бит равен нулю)

ccTLD - национальный домен верхнего уровня (Country Code Top Level Domain)

CR - символ возврата каретки

CRLF - символы перехода в начало следующей строки, соответствующие <CR> и <LF>

DAP - протокол доступа к справочнику (Directory Access Protocol)

DNS (Domain Name System) - система доменных имен

DTP (data transfer process) - процесс передачи данных. Устанавливает и управляет соединением данных. Может быть активным и пассивным.

EOF - символ конца файла, определяющий конец передаваемого файла.

EOL - последовательность символов <CR> и <LF>, разделяющая линии, выводимые на печать.

EOR - символ конца записи, определяющий конец передаваемой записи.

FTP - протокол передачи файлов (File Transport Protocol)

HTTP - протокол передачи гипертекста (Hyper Text Transfer Protocol)

IETF - Рабочая группа по инженерным проблемам сети Интернет (Internet Engineering Task Force)

IP - межсетевой протокол (Internet Protocol)

LF - символ перехода на следующую строку

MIME-IMB - формат сообщения, описанный в рекомендации RFC 2045 [8]

Mode (режим передачи данных) - определяет формат данных при передаче, включая EOR и EOF.

NNTP – Network News Transfer Protocol (протокол передачи сетевых новостей)

NUL – специальный атом, представляющий отсутствие отдельного элемента данных, представленного как строка, либо список в скобках, в отличие от пустой строки "" или пустого списка в скобках ().

NULL - строка – строка, состоящая только из символов <CRLF>

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

NVT - виртуальный терминал сети, согласно определению, данному в описании протокола Telnet.

Page (cтраница) - структурная единица файла.

Pathname - символьная строка, идентифицирующая файл в файловой системе. Конкретный вид зависит от файловой системы.

PI - интерпретатор протокола. Стороны клиента и сервера реализуют PI клиента и PI сервера.

POP3 - протокол обмена почтовой информацией (Post Office Protocol)

RADIUS - протокол аутентификации пользователей в соответствии с RFC 2138 [29] [(Remote Authentication Dial In User Service)

Record (запись) - структурная единица последовательного файла. Структура записей поддерживается FTP, но файл не должен состоять из структуры записей.

RFC - обозначение документа IETF (Request For Comments)

RR (Resource Records) - набор информации о ресурсе, связанный с отдельным доменным именем

SMTP - простой протокол передачи почты (Simple Mail Transport Protocol)

SNMP - протокол управления сетью на базе TCP/IP (Simple Network Management Protocol)

SP - символ пробела

TCP - транспортный протокол (Transport Control Protocol)

TCP/IP - стек протоколов межсетевого взаимодействия (Transmission Control Protocol/Internet Protocol)

Type (тип представления данных). Тип определяет преобразования при хранении данных и передаче данных.

UDP (User Datagramm Protocol) - протокол пользовательских датаграмм

UID - уникальный идентификатор почтового сообщения

URI - Universal Resource Identifier (универсальный идентификатор ресурса)

URL - Uniform Resource Locators (унифицированный указатель ресурсов)

АВ-терминал - аудио-видео терминал

Авторитетные данные - данные, полученные от авторитетного сервера

Авторитетный сервер - сервер, хранящий полную информацию о зоне

Агент клиентский - клиент, инициирующий запрос (броузер, редактор, робот или другое средство)

Адресат - клиент, которому предназначается почтовое сообщение

АП - агент пользователя

АПС - агент передачи сообщений

Атом - структура данных, состоящая из одного или более символов, не являющихся специальными.

Валидатор - элемент протокола, используемый для определения, является ли данная позиция кэша эквивалентной копией сущности.

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

Возраст - время, прошедшее с момента отправки или успешной проверки актуальности ответа.

Группа новостей - имя, идентифицирующее группу клиентов, которым будет доставлена данная статья

Группа распространения - имя, идентифицирующее группу клиентов, которым будет доставлена данная статья в дополнение к клиентам группы новостей

Данные электронной почты - последовательность произвольной длины, состоящая из символов кода ASCII, удовлетворяющая формату почтового сообщения в соответствии с RFC 822[2].

Домен - иерархически структурированный глобальный адрес компьютера узла сети в виде строки символов

Заголовок сообщения HTTP - 1. набор строк между первой строкой сообщения (start-line) и пустой строкой, отделяющей заголовок от тела сообщения. 2. - строка (несколько строк), содержащая выражение, задающее значение для отдельного поля заголовка сообщения.

Идентификатор валидности - уникальное значение, выделяемое для каждого почтового ящика. При удалении почтового ящика и создании почтового ящика с таким же именем, идентификатор валидности нового почтового ящика должен быть отличным от предыдущего.

Идентификатор уникальный почтового сообщения (UID сообщения) - 32-х битовый номер, выделяемый для каждого почтового сообщения и используемый совместно с уникальным идентификатором валидности. UID и идентификатор валидности вместе занимают 64 бита. Значение итогового составного идентификатора является гарантированно уникальным для каждого почтового сообщения в данном почтовом ящике.

ИС - информационная служба

ИСО - Международная организация по стандартизации (International Organization for Standartization)

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

"Клеевые" записи - записи, содержащие ссылку на авторитетый сервер подзоны

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

Команда - сообщение NNTP, направляемое от клиента к серверу

Конверт сообщения – заголовок почтового сообщения.

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

"Лист" - элемент иерархического графа, дерева, не имеющего выходящих дуг

Литерал – основная форма строки. Представляет последовательность из 0 или более октетов (включая символы <CR> и <LF>), которой предшествует счетчик октетов. Формат счетчика октетов: открывающаяся фигурная скобка “{“, число октетов, закрывающаяся фигурная скобка “}”, <CRLF>. В случае, когда литерал посылается от клиента серверу, клиент должен ждать получения запроса продолжения команды перед отправлением данных (и остатка команды). Даже если счетчик октетов равен 0, клиент, передающий буквенную строку, должен ждать получения команды запроса продолжения.

МПС - служба межперсональных сообщений

МСЭ - Международный союз электросвязи

МСЭ-Т - Сектор стандартизации электросвязи МСЭ

Новости электронные (news) - вид информации, периодически распространяемой в виде электронных сообщений большому количеству клиентов по сети передачи данных.

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

Остаток (имени, команды) - последний элемент (группа элементов) структуры

Ответ - сообщение NNTP, направляемое от сервера клиенту

Ответ актуальный - ответ, который не устарел, не утратил актуальности

Ответ отрицательный - ответ со значением индикатора статуса "-ERR"

Ответ первичный - ответ, который пришел от сервера-источника. Ответ также является первичным, если его актуальность была проверена непосредственно сервером-источником.

Ответ положительный - ответ со значением индикатора статуса "+OK"

Ответ устаревший - ответ, у которого истек срок его актуальности

Отправитель - клиент, инициировавший отправку почтового сообщения

Передатчик SMTP - процесс, осуществляющий передачу электронной почты.

Передатчик SMTP инициирует соединение транспортного уровня.

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

Приемник SMTP - процесс, осуществляющий прием электронной почты.

Прокси - программа-посредник, выполняющая функции сервера и клиента с целью выполнения запросов от имени других клиентов.

Процесс сервера FTP (сервер) - процесс, выполняющий функции передачи файлов совместно с процессом клиента FTP и, возможно, другим сервером. Функционально процесс сервера можно разделить на процесс интерпретатора протокола (PI) и процесс передачи данных (DTP).

"Разрез" - точка разделения иерархисеского графа (дерева) на два составляющих иерархических графа (поддерева)

РД - руководящий документ

Режим стойких соединений - режим работы сервера, при котором он обрабатывает несколько запросов клиента, не разрывая соединения TCP с данным клиентом.

Ресурс - объект сетевых данных или служба, которая может быть идентифицирована посредством URI.

САК - служба аудиоконференций

СВК - служба видеоконференций

СГС - служба голосовых сообщений

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

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

Сессия - набор процедур обмена, происходящих по открытому соединению транспортного уровня

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

СКА - сервер контроля и авторизации

Слово - последовательность печатных символов

Согласование содержимого - механизм для выбора соответствующего представления при обслуживании запроса.

Соединение данных - полнодуплексное соединение, по которому в определенном режиме (mode) передаются данные определенного типа (type).

Сообщение - информация, состоящая из структурированной последовательности октетов, удовлетворяющая синтаксису сообщения HTTP и передаваемая по соединению

Сообщение NNTP - сообщение, передаваемое по каналу передачи протокола нижнего уровня, используемого протоколом NNTP.

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

Список рассылки (mailing list) - способ организации доставки электронных новостей, а также набор аппаратно-программного обеспечения, реализующего данный способ. При данном способе доставки электронные новости доставляются клиенту средствами электронной почты в моменты времени, определяемые серверной стороной списка рассылки.

СПРИ - служба передачи речевой информации

СПС - система передачи сообщений

Срок актуальности - промежуток времени между генерацией ответа и окончанием срока истечения

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

Срок истечения эвристический - срок истечения точный, устанавливаемый кэшем.

Статья - сообщение электронных новостей

СТК - служба телеконференций

Строка бинарная – это любая строка с символами NUL.

Строка в кавычках – форма строки, представляющая собой последовательность из 0 или более семибитных символов, кроме символов <CR> и <LF>, с символом двойной кавычки <"> с каждой стороны.

Сущность - информация, передаваемая в виде полезной нагрузки запроса или ответа. Сущность состоит из метаинформации в форме полей заголовка сущности и содержимого в форме тела сущности.

СХИ - система хранения информации

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

ТМ службы - телематические службы

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

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

ТС - сеанс телеконференцсвязи

ТфОП - телефонная (сеть) общего пользования

Узел сети (узел) - компьютер, подключенный к сети, на котором запущен процесс SMTP, либо присутствуют почтовые ящики

Указатель конца данных почты - специальная последовательность символов, указывающая на конец данных электронной почты. Состоит из последовательности символов: CR, LF, символа точка ("."), CR, LF.

УПОР - устройство пакетной обработки речи

Управляющее соединение - соединение между PI клиента и PI сервера для обмена командами и ответами.

УТС DNS - узел телематических служб, реализующий функции сервера DNS.

УТС FTP - узел телематических служб, реализующий функции сервера FTP.

УФС - узел факсимильной связи

ХС - хранилище сообщений

Шлюз - сервер, который работает как промежуточный для некоторых других

ЭП - электронная почта

Ящик электронной почты (почтовый ящик) - набор символов, идентифицирующий клиента, которому отправляется почта. Обычно состоит из спецификации клиента и узла. Дополнительно, под данным термином понимают абстрактный "контейнер", в котором хранятся сообщения электронной почты.

4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

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

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

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

Технические требования к техническим средствам информационных служб в части службы доменных имен по протоколу DNS приведены в Приложении 4.

Технические требования к техническим средствам службы доступа к информационным ресурсам по протоколу HTTP приведены в Приложении 5.

Технические требования к техническим средствам службы доступа к информационным ресурсам по протоколу NNTP приведены в Приложении 6.

Технические требования к техническим средствам службы доступа к информационным ресурсам по протоколу FTP приведены в Приложении 7

5. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ.

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

6. ТРЕБОВАНИЯ К НАДЕЖНОСТИ И ДОСТОВЕРНОСТИ.

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

Надежность хранения информации в системе должна обеспечиваться применением аппаратно-программных методов организации данных с применением стандартных носителей.

7. ТРЕБОВАНИЯ К ДИАГНОСТИКЕ.

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

Средства диагностики сервера (узла) телематических служб не должны нарушать целостность и корректность данных.

8. ТРЕБОВАНИЯ К ЭЛЕКТРОПИТАНИЮ.

Система должна быть работоспособной при электропитании оборудования системы от источников бесперебойного электропитания, обеспечивающих на выходе напряжение 220 В с частотой 50 Гц и допустимыми отклонениями напряжения от минус 15% до +10% и частоты ± 5 Гц.

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

9. ТРЕБОВАНИЯ К ЭЛЕКТРОБЕЗОПАСНОСТИ И ЭЛЕКТРОМАГНИТНОЙ СОВМЕСТИМОСТИ.

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

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

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

10. ТРЕБОВАНИЯ ПО УСТОЙЧИВОСТИ К КЛИМАТИЧЕСКИМ ФАКТОРАМ.

ТС телематических служб должен оставаться работоспособным при температуре окружающего воздуха от 5 до 40 град. С и относительной влажности от 20 до 80 % (без конденсата).

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

1 1. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ.

В состав документации на ТС телематических служб должны входить следующие обязательные документы:

Технические условия;

Комплект эксплуатационной документации.

Технические условия на ТС телематических служб должны быть выполнены на русском языке и соответствовать требованиям настоящих ОТТ.

Комплект эксплуатационной документации должен быть выполнен на русском языке и должен содержать:

- общее описание, включая контрольный пример;

- руководства администратора и оператора.

ПРИЛОЖЕНИЕ 1

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ ЭЛЕКТРОННОЙ ПОЧТЫ ПО ПРОТОКОЛУ SMTP

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы ЭП по протоколу SMTP в соответствии с RFC 821 [1].

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

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

2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К SMTP

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

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

При использовании TCP для организации соединения клиента и сервера должен использоваться порт 25. При кодировании сообщений SMTP должно учитываться, что соединение TCP поддерживает длину байта 8 бит. Семибитные символы сообщений SMTP должны быть выровнены вправо, а старший бит октета установлен в 0.

2.1.2. Установление соединений.

В результате запроса клиента передатчик SMTP устанавливает дуплексное соединение с приемником SMTP.

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

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

2.2. Взаимодействие

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

После установления соединения транспортного уровня приемник должен выдать ответ приветствия 220.

Первой командой в сессии должна быть команда HELO.

Последней командой сессии должна быть команда QUIT.

Элементы взаимодействия по протоколу SMTP приведены в п.8.

3. СООБЩЕНИЯ

Сообщения SMTP, посылаемые передатчиком SMTP приемнику SMTP, называются командами. Сообщения SMTP, посылаемые приемником SMTP передатчику SMTP, называются ответами.

Команды и ответы состоят из символов кода ASCII.

3.1. Команды

Командами являются символьные строки, заканчивающиеся <CRLF>. Команды состоят из кода команды и последующего поля аргументов. Коды команды и аргументы должны быть разделены одним или более пробелами. Регистр символов кода команды и названий параметров, таких как "to:" или "from:", не является существенным. Регистр аргументов прямого и обратного пути является существенным. Поле аргумента состоит из строки символов переменной длины, заканчивающееся <CRLF>.

3.1.1. Перечень команд

Перечень команд SMTP приведен в табл. 1

Таблица 1

Перечень команд SMTP

3.1.2. Синтаксис команд определен в п.5.

3.1.3. Команды: HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT должны быть реализованы обязательно.

3.1.4. Обеспечение прозрачности передачи данных в команде DATA

При посылке передатчиком данных почты каждую последовательность "<CRLF>." (0x0D 0x0A 0x2E) передатчик должен заменять на "<CRLF>.."(0x0D 0x0A 0x2E 0x2E). Приемник должен выполнять обратное преобразование. Указатель конца почтовых данных этому преобразованию не подвергается.

3.2. Ответы

3.2.1. Код ответа

Ответ SMTP состоит из трехзначного кода ответа (передаваемого как три символа), за которым следует текст.

Значения номера ответа:

первая цифра

вторая цифра

третья цифра

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

Ответ сервера может состоять из одной или нескольких строк.

Однострочный ответ состоит из:

трехзначного номера ответа, передаваемого как три символа,

символа <SP>,

текста,

символа <CRLF> .

Многострочный ответ состоит из:

трехзначного номера ответа, передаваемого как три символа,

символа "-"

текста первой строки

символа <CRLF>

трехзначного номера ответа, передаваемого как три символа,

символа "-"

текста второй строки

символа <CRLF>

.....

трехзначного номера ответа, передаваемого как три символа,

символа <SP>,

текста последней строки,

символа <CRLF> .

Список кодов ответов приведен в табл. 2. Для всех ответов, кроме 110, текст ответа не обязательно должен соответствовать приведенному в табл. 2.

Таблица 2

Список кодов ответов

3.3. Порядок команд и ответов

Первой командой в сессии должна быть команда HELO. Если аргумент команды HELO является неприемлемым, должен быть выдан ответ 501 и приемник SMTP должен остаться в прежнем состоянии.

Команды NOOP, HELP, EXPN, VRFY могут использоваться в любое время в течении сессии.

Команды MAIL, SEND, SOML, SAML начинают транзакцию. Если аргумент команды начала транзакции является неприемлемым, приемник должен выдать ответ 501 и остаться в прежнем состоянии. Во время транзакции должны использоваться команды в следующей последовательности: одна или несколько команд RСPT, одна команда DATA. Транзакция может быть прервана командой RSET. В течение сессии может быть 0, 1 или более транзакций. Если во время транзакции команды выдаются с нарушением указанного порядка, приемник должен выдать ответ 503 и остаться в прежнем состоянии.

Последней командой сессии должна быть команда QUIT. Команда QUIT может быть выдана в любое время в течение сессии.

На каждую команду должен выдаваться точно один ответ.

В п.6 и п.7 определяются допустимые последовательности команд и ответов.

3.4. Ограничения на размер элементов сообщений SMTP

Ограничения на размер элементов сообщений SMTP приведены в табл. 3

Таблица 3

Ограничения на размер элементов сообщений SMTP.

4. ОПИСАНИЕ СИНТАКСИСА КОМАНД И ОТВЕТОВ

<HELO> ::= "HELO" 1*<SP> <domain> <CRLF>

<MAIL> ::= "MAIL" 1*<SP> "FROM:" <reverse-path> <CRLF>

<RCPT> ::= "RCPT" 1*<SP> "TO:" <forward-path> <CRLF>

<DATE> ::= "DATA" <CRLF>

<RSET> ::= "RSET" <CRLF>

<SEND> ::= "SEND" 1*<SP> "FROM:" <reverse-path> <CRLF>

<SOML> ::= "SOML" 1*<SP> "FROM:" <reverse-path> <CRLF>

<SAML> ::= "SAML" 1*<SP> "FROM:" <reverse-path> <CRLF>

<VRFY> ::= "VRFY" 1*<SP> <string> <CRLF>

<EXPN> ::= "EXPN" 1*<SP> <string> <CRLF>

<HELP> ::= "HELP" [1*<SP> <string>] <CRLF>

<NOOP> ::= "NOOP" <CRLF>

<QUIT> ::= "QUIT" <CRLF>

<TURN> ::= "TURN" <CRLF>

<reverse-path> ::= <path>

<forward-path> ::= <path>

<path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"

<a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>

<at-domain> ::= "@" <domain>

<domain> ::= <element> | <element> "." <domain>

<element> ::= <name> | "#" <number> | "[" <dotnum> "]"

<mailbox> ::= <local-part> "@" <domain>

<local-part> ::= <dot-string> | <quoted-string>

<name> ::= <a> <ldh-str> <let-dig>

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig> ::= <a> | <d>

<let-dig-hyp> ::= <a> | <d> | "-"

<dot-string> ::= <string> | <string> "." <dot-string>

<string> ::= <char> | <char> <string>

<quoted-string> ::= """ <qtext> """

<qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>

<char> ::= <c> | "\" <x>

<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>

<number> ::= <d> | <d> <number>

<CRLF> ::= <CR> <LF>

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

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

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

<snum> ::= одна, две или три десятичные цифры, представляющие десятичное число в диапазоне от 0 до 255

<a> ::= любой из 52 алфавитных строчных и прописных символа от A до Z и от a до z

<c> ::= любой из 128 символов ASCII кроме <special> or <SP>

<d> ::= любая из 10 цифр от 0 до 9

<q> ::= любой из 128 символов ASCII кроме <CR>, <LF>, кавычек ("), или (\)

<x> ::= любой из 128 символов ASCII

<special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." | "," | ";" | ":" | "@" """ | управляющие символы (коды ASCII от 0 до 31 включительно, а так же 127)

Примечание 1: символ "\" указывает на то, что следующий за ним специальный символ интерпретируется "буквально", а не в соответствии с обычной интерпретацией.

Примечание 2: для именования узлов используются две дополнительные числовые формы. Первая форма состоит из символа "#", за которым следует целое десятичное число, являющееся адресом узла. Вторая форма состоит из 4-х целых десятичных чисел, разделенных точками и заключенных в квадратные скобки. Вторая форма соответствует адресу IP.

<return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>

<time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>

<stamp> ::= <from-domain> <by-domain> <opt-info> ";" <daytime>

<from-domain> ::= "FROM" <SP> <domain> <SP>

<by-domain> ::= "BY" <SP> <domain> <SP>

<opt-info> ::= [<via>] [<with>] [<id>] [<for>]

<via> ::= "VIA" <SP> <link> <SP>

<with> ::= "WITH" <SP> <protocol> <SP>

<id> ::= "ID" <SP> <string> <SP>

<for> ::= "FOR" <SP> <path> <SP>

<link> ::= Стандартные имена соединений (links), зарегистрированные в организации Network Information Center

<protocol> ::= Стандартные имена протоколов, зарегистрированные в организации Network Information Center

<daytime> ::= <SP> <date> <SP> <time>

<date> ::= <dd> <SP> <mon> <SP> <yy>

<time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>

<dd> ::= однозначное или двузначное десятичное число, обозначающее день в диапазоне от 1 до 31

<mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"

<yy> ::= двузначное десятичное число, обозначающее год столетия в диапазоне от 00 до 99

<hh> ::= двузначное десятичное число, обозначающее часы дня в диапазоне от 00 до 23

<mm> ::= двузначное десятичное число, обозначающее минуты часа в диапазоне от 00 до 59

<ss> ::= двузначное десятичное число, обозначающее секунды минуты в диапазоне от 00 до 59

<zone> ::= "UT" для Универсального Времени (по умолчанию) или другого часового пояса в соответствии с RFC 822[2]

5. ПОСЛЕДОВАТЕЛЬНОСТЬ КОМАНД И ОТВЕТОВ

Используются следующие сокращения:

I - промежуточный положительный ответ

S - успешное выполнение

F - неудача

E - ошибка

Установление соединения

S: 220

F: 421

HELO

S: 250

E: 500, 501, 504, 421

MAIL

S: 250

F: 552, 451, 452

E: 500, 501, 421

RCPT

S: 250, 251

F: 550, 551, 552, 553, 450, 451, 452

E: 500, 501, 503, 421

DATA

I: 354 -> data -> S: 250

F: 552, 554, 451, 452

F: 451, 554

E: 500, 501, 503, 421

RSET

S: 250

E: 500, 501, 504, 421

SEND

S: 250

F: 552, 451, 452

E: 500, 501, 502, 421

SOML

S: 250

F: 552, 451, 452

E: 500, 501, 502, 421

SAML

S: 250

F: 552, 451, 452

E: 500, 501, 502, 421

VRFY

S: 250, 251

F: 550, 551, 553

E: 500, 501, 502, 504, 421

EXPN

S: 250

F: 550

E: 500, 501, 502, 504, 421

HELP

S: 211, 214

E: 500, 501, 502, 504, 421

NOOP

S: 250

E: 500, 421

QUIT

S: 221

E: 500

TURN

S: 250

F: 502

E: 500, 503

6. ДИАГРАММЫ СОСТОЯНИЙ СЕРВЕРА SMTP

Диаграмма состояний сервера SMTP для команд HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, NOOP, QUIT, TURN приведены на рис.1. Диаграмма состояний сервера SMTP для команды DATA приведена на рис.2.

Используемые сокращения на рис.1 и рис.2:

B - Начало

S - Успешное выполнение

F - Неудача

E - Ошибка

W - Ожидание ответа

data - серия линий с данными почты, посылаемых от передатчика приемнику.

M - Среднее состояние

Цифрами обозначены возможные номера ответов, что соответствует первой цифре трехзначного кода ответа, как это описано в пункте 4.2.1.

Рис. 1 Диаграмма состояний сервера SMTP для команд HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, NOOP, QUIT, TURN.

Рис. 2 Диаграмма состояний сервера SMTP для команды DATA.

7. ОПИСАНИЕ ПРОЦЕДУР SMTP

На рис. 3. показана схема соединений при взаимодействии SMTP.

Рис. 3. Схема соединений при взаимодействии SMTP.

Рассматривают следующие процедуры SMTP во время взаимодействия SMTP:

транзакция,

направление,

верификация,

доставка в почтовый ящик

доставка на терминал клиента,

открытие и закрытие соединения

7.1. Открытие и закрытие соединения

Для открытия соединения используется команда HELO. Этой командой идентифицируется узел передатчика SMTP.

HELO <домен>

Для закрытия соединения используется команда: QUIT

Во время соединения приемник и передатчик могут поменяться ролями. Для этого используется команда TURN. Инициатором обмена ролями должен быть передатчик. Для отказа обмена используется ответ 502. Данная команда не должна использоваться в случае, если в качестве протокола транспортного уровня используется TCP.

7.2. Транзакция.

В результате запроса клиента передатчик SMTP устанавливает дуплексное соединение с получателем SMTP. Приемником SMTP может быть либо адресат, либо промежуточный пункт.

Сразу после установления соединения передатчик SMTP посылает команду MAIL, указывающую отправителя почты. Если приемник SMTP может принять почту, он отвечает OK. После этого передатчик SMTP посылает команду RCPT, указывающую получателя почты. Если приемник SMTP может принять почту для данного получателя, он отвечает OK. Если нет, он высылает ответ, отклоняющий данного получателя (но не всю транзакцию). Передатчик SMTP и приемник SMTP могут согласовать нескольких получателей. После завершения согласования получателей, передатчик SMTP отправляет данные почты, заканчивающиеся определенной последовательностью. Если приемник SMTP успешно обработал полученные данные, он отвечает OK.

Таким образом транзакция состоит из трех шагов, что отображено на табл. 4.

Таблица 4

Шаги транзакции

Пример процедуры Транзакция:

S: MAIL FROM:<Smith@Alpha.ARPA>

R: 250 OK

S: RCPT TO:<Jones@Beta.ARPA>

R: 250 OK

S: RCPT TO:<Green@Beta.ARPA>

R: 550 No such user here

S: RCPT TO:<Brown@Beta.ARPA>

R: 250 OK

S: DATA

R: 354 Start mail input; end with <CRLF>.<CRLF>

S: Blah blah blah...

S: ...etc. etc. etc.

S: <CRLF>.<CRLF>

R: 250 OK

7.3. Направление

В случаях, когда информация аргумента <прямой путь> команды RCPT оказывается некорректной, но приемник SMTP знает адресат, должны использоваться следующие ответы:

251 Клиент не локальный. Сообщение переслано в <прямой путь>

551 Клиент не локальный. Попробуйте <прямой путь>

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

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

7.4. Верификация

Для предоставления возможностей верификации пользователей и списка рассылки существуют команды VRFY и EXPN.

По команде VRFY приемник по введенному имени клиента выдает полное имя клиента и имя его почтового ящика.

По команде EXPN приемник по идентификатору списка рассылки выдает многострочный ответ, содержащий полные имена клиентов и имена их почтовых ящиков, включенных в данный список рассылки.

7.5. Доставка в почтовый ящик и доставка на терминал клиента

Доставка почты на терминал клиента осуществляется командой

SEND from:<обратный путь>

Если адресат неактивен или не принимает почтовое сообщение, отправитель получит ответ 450.

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

Команда SAML позволяет доставить почту на терминал клиента (если он активен) и поместить ее в почтовый ящик.

7.6. Пересылка

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

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

ПРИЛОЖЕНИЕ 2

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ ЭЛЕКТРОННОЙ ПОЧТЫ ПО ПРОТОКОЛУ POP3

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Настоящее приложение описывает технические требования к ТС службы ЭП по протоколу POP3 в соответствии с RFC 1939 [3] и RFC 1734[4].

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

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

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.

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 (дополнительный механизм идентификации)

Рис. 1 Типичная последовательность состояния сервера

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. Структура команды:

ключевое слово

один или более аргументов (могут отсутствовать)

символ <CRLF>

Ключевое слово и аргументы, а также аргументы между собой разделяются одним символом <SP> (пробел).

Максимальная длина аргумента составляет 40 символов.

Длина ключевого слова составляет 3 или 4 символа.

3.1.2. Перечень команд

Перечень команд приведен в табл. 1.

Таблица 1

Перечень команд

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

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

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 для тела сообщения, некодированные бинарные строки запрещены.

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

3.2. Атрибуты почтовых сообщений

3.2.1. Уникальный номер почтового сообщения (UID), порядковый номер почтового сообщения и идентификатор валидности

Длина уникального идентификатора должна составлять 32 бита.

Длина идентификатора валидности должна составлять 32 бита.

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

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

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

3.2.2. Флаги почтового сообщения

Должны быть реализованы флаги:

\Seen

\Answered

\Flagged

\Deleted

\Draft

\Recent

Могут быть реализованы дополнительные флаги.

3.3. Команды

Сообщения, направляемые от клиента серверу, называются командами.

Формат команд приведен в п.5.

Список команд с описанием назначения приведен в табл.1.

Таблица 1

Список команд.