РД 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. НОРМАТИВНЫЕ ССЫЛКИ


[1] Рекомендация

IETF RFC 821

Простой протокол передачи почты, 1982г.

(Simple Mail Transfer Protocol)

[2] Рекомендация

IETF RFC 822

Стандарт для формата текстовых сообщений Интернета ARPA., 1982г.

(Standart for the Format of ARPA Internet Text Messages.)

[3] Рекомендация

IETF RFC 1939

Протокол почтового офиса, 1996г.

(Post Office Protocol Version 3)

[4] Рекомендация

IETF RFC 1734

Команда AUTH протокола POP3, 1994г.

(POP3. AUTHentication command)

[5] Рекомендация

IETF RFC 1321

Алгоритм цифрового сообщения MD5, 1992г.

(The MD5 Message-Digest Algorithm)

[6] Рекомендация

IETF RFC 1731

Механизм аудентификации протокола IMAP4, 1994г.

(IMAP4. Authentication Mechanisms)

[7] Рекомендация

IETF RFC 1733

Распределенные модели электронной почты в IMAP4, 1994г.

(Distributed Electronic Mail Models in IMAP4)

[8] Рекомендация

IETF RFC 2045

MIME (Многоцелевые расширения почты Интернета). Часть 1: Формат тела сообщения Internet.,1996 г.

(MIME (Multipurpose Internet Mail Extensions). Part One: Format of Internet Message Bodies)

[9] Рекомендация

IETF RFC 1700

Выделение номера., 1994г.

(Assigned Number)

[10] Рекомендация

IETF RFC 1730

Протокол доступа к сообщениям Интернет, 1996г.

(Internet Message Access Protocol version 4)

[11] Рекомендация

IETF RFC 2060

Протокол доступа к сообщениям Интернет, 1996г.

(Internet Message Access Protocol version 4rev1)

[12] Рекомендация

IETF RFC 1034

Доменные имена.Концепции и возможности., 1987г.

(Domain name concepts and facilities)

[13] Рекомендация

IETF RFC 1035

Доменные имена. Реализация и спецификация., 1987г.

(Domain name implementation and specification)

[14] Рекомендация

IETF RFC 2068

Протокол передачи гипертекста HTTP/1.1, 1997г.

(Hypertext Transfer Protocol HTTP/1.1)

[15] Рекомендация

IETF RFC 2048

Процедура регистрации типа информации,1996г.

(Media Type Registration Procedure)

[16] ISO-8859

Международный стандарт по обработке информации 8-ми битные однобайтовые наборыкодов графических символов.

(International Standart - Information Processing - 8-bit Single Byte Coded Graphic Character Sets.)

[17] Рекомендация

IETF RFC 2047

MIME (Многоцелевые расширения почты Интернета). Часть 3: Расширения заголовка для не ASCII-текста.,1996г.

(MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text)

[18] Рекомендация

IETF RFC 1123

Требования для узлов Интернета применение и поддержка, 1989г.

(Requirements for Internet hosts application and support.)

[19] Рекомендация

IETF RFC 1036

Стандарт для обмена USENET сообщениями., 1987г.

(Standart for interchange of USENET messages)

[20] Рекомендация

IETF RFC 850

Стандарт для обмена USENET сообщениями., 1983г.

(Standart for interchange of USENET messages)

[21] Рекомендация

IETF RFC 1952

Спецификация формата файла GZIP версии 4.3., 1996г.

(GZIP file format specification version 4.3)

[22] Рекомендация

IETF RFC 1766

Тэги для идентификации языков., 1995г.

(Tags for the identification of languages)

[23] ISO-639

Коды для представления названий языков.,1988г.

(Code for representation of names languages)

[24] ISO-3166

Коды стран.

(Country codes)

[25] Рекомендация

IETF RFC 1864

Поле заголовка Content-MD5.,1995

(The Content-MD5 Header Field)

[26] Рекомендация

IETF RFC 977

Протокол передачи сетевых новостей, 1986г.

(Network News Transfer Protokol)

[27] Рекомендация

IETF RFC 959

Протокол передачи файлов, 1985г.

(File Transfer Protocol)

[28] Рекомендация

IETF RFC 943

Выделенные числа, 1985г.

(Assigned Numbers)

[29] Рекомендация

IETF RFC 2138

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

(Remote Authentication Dial In User Service)

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


Команда

HELO <domain>

Аргументы

domain - имя узла передатчика SMTP

Описание

Используется для идентификации передатчика SMTP приемником SMTP.

Действия c буферами

Все таблицы состояний и буферы очищены.



Команда

MAIL FROM:<reverse-path>

Аргументы

reverce-path обратный путь. Состоит из списка узлов и почтового ящика отправителя.

Описание

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

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

Действия c буферами

Очищаются буферы обратного пути, буферы прямого пути, буфер данных почты.

В буфер обратного пути помещается данные аргумента команды.



Команда

RCPT TO:<forward-path>

Аргументы

forward-path - прямой путь. Состоит из списка узлов и почтового ящика адресата

Описание

Идентифицирует индивидуального получателя данных почты. Несколько получателей определяются использованием множества команд RCPT.

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

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

Действия c буферами

Аргумент прямого пути добавляется в буфер прямого пути



Команда

DATA

Аргументы

-

Описание

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

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

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

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

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

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

Все извещения о недоставке должны посылаться с помощью команды MAIL.

Действия c буферами

Буферы обратного пути, прямого пути и буфер данных сбрасываются.



Команда

SEND FROM:<reverse-path>

Аргументы

reverse-path - обратный путь

Описание

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

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

Действия c буферами

Буферы обратного пути, прямого пути и буфер данных сбрасываются.

Информация из аргумента обратного пути вставляется в буфер обратного пути.



Команда

SOML FROM:<reverse-path>

Аргументы

reverse-path - обратный путь

Описание

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

Назначение аргумента аналогично команде SEND.

Действия c буферами

Буферы обратного пути, прямого пути и буфер данных сбрасываются.

Информация из аргумента обратного пути вставляется в буфер обратного пути.



Команда

SAML FROM:<reverse-path>

Аргументы

Reverse-path - обратный путь

Описание

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

Назначение аргумента аналогично команде SEND.

Действия c буферами

Буферы обратного пути, прямого пути и буфер данных сбрасываются.

Информация из аргумента обратного пути вставляется в буфер обратного пути.



Команда

RSET

Аргументы

-

Описание

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

Приемник должен ответить OK.

Действия c буферами

Все сохраненные данные уничтожаются, все буферы сбрасываются.



Команда

VRFY <string>

Аргументы

string предполагаемое имя клиента

Описание

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

Действия c буферами

-



Команда

EXPN <string>

Аргументы

string предполагаемый идентификатор списка рассылки

Описание

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

Действия c буферами

-



Команда

HELP [<string>]

Аргументы

string - имя команды

Описание

По данной команде приемник должен выдать ответ с полезной для передатчика информацией.

Действия c буферами

-



Команда

NOOP

Аргументы

-

Описание

Нет операции. Приемник должен выдать ответ OK.

Действия c буферами

-



Команда

QUIT

Аргументы

-

Описание

Приемник должен выдать ответ OK и закрыть соединение.

Действия c буферами

Сброс всех данных и буферов.



Команда

TURN

Аргументы

-

Описание

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

Если обмен ролями произошел, процесс, ставший приемником высылает ответ приветствия 220.

Действия c буферами

Сброс всех данных и буферов.


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 состоит из трехзначного кода ответа (передаваемого как три символа), за которым следует текст.

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

первая цифра

1

Положительный предварительный ответ

2

Положительный окончательный ответ

3

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

4

Временный отрицательный окончательный ответ

5

Постоянный отрицательный окончательный ответ

вторая цифра

0

Ошибки синтаксиса

1

Запрос информации

2

О состоянии соединения

3

не определен

4

не определен

5

О состоянии почтовой системы

третья цифра

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

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

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

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

символа <SP>,

текста,

символа <CRLF> .

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

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

символа "-"

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

символа <CRLF>

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

символа "-"

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

символа <CRLF>

.....

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

символа <SP>,

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

символа <CRLF> .


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

Таблица 2

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


Код

Текст

211

Системный статус или ответ системной помощи

214

Ответ помощи

220

<домен> Служба готова

221

<домен> Служба закрывает соединение

250

Запрошенное действие выполнено успешно

251

Клиент не локальный, направлено в <прямой путь>

354

Начинаю получение почтовых данных. Конец при <CRLF>.<CRLF>

421

<домен> Служба не доступна, закрываю соединение

450

Запрошенное действие не принято. Почтовый ящик недоступен (например, занят)

451

Запрошенное действие прервано. Локальная ошибка выполнения.

452

Запрошенное действие не принято. Недостаточно памяти.

500

Синтаксическая ошибка, команда не распознана

501

Синтаксическая ошибка в параметре или аргументах

502

Команда не реализована

503

Неправильная последовательность команд.

504

Аргумент команды не реализован

550

Запрошенное действие не принято. Почтовый ящик не доступен (например, не найден)

551

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

552

Запрошенное действие прервано. Превышен лимит памяти.

553

Запрошенное действие не принято. Неправильное имя почтового ящика.

554

Ошибка транзакции.

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.


Обозначение элемента

Элемент

Максимальный размер

User

имя клиента

64 символов

Domain

имя домена

64 символов

Path

обратный путь или прямой путь

256 символов

Command line

Строка команды включая символы <CRLF>

512 символов

reply line

Строка ответа включая код ответа и символы <CRLF>

512 символов

text line

Строка данных почты, включая символы <CRLF>, но не считая символы точки, добавленные для обеспечения прозрачности

1000 символов

Recipient buffer

Емкость буфера адресатов

100 адресатов

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

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


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

Команда

Описание шага транзакции

1.

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

На данном шаге происходит идентификация отправителя, сброс всех таблиц состояния и буферов. Устанавливается обратный путь, используемый для передачи сообщений об ошибках. Если приемник SMTP принимает данную команду, от выдает ответ 250 OK.

2.

RCPT to: <прямой путь 1>

....

....

RCPT to: <прямой путь N>

На данном шаге идентифицируется один или больше адресатов.

Каждая команда RCPT идентифицирует одного адресата. Если приемник SMTP принимает команду RCPT, он выдает ответ 250 OK. Если адресат неизвестен, приемник SMTP выдает ответ 550 Failure. Описанный шаг повторяется для каждого адресата.

3.

DATA

Если приемник SMTP принимает данную команду, он выдает ответ 354 Intermediate. Следующие за командой DATA строки приемник SMTP воспринимает как текст почтового сообщения. После того, как все строки приняты и запомнены, приемник SMTP выдает ответ 250 OK.

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

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

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


Команда

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

Реализации должны кодировать бинарные данные в текстовую форму, такую как 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

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


Команда

CAPABILITY

Аргументы

-

Описание

Запрашивает список возможностей, поддерживаемых сервером. Сервер должен ответить единственным ответом CAPABILITY без тега с указанием "IMAP4rev1", в качестве одной из возможностей в списке, а затем ответом OK с тегом. Выдаваемый список не должен зависеть от состояния или клиента.

Возможные ответы без тега

Обязательный ответ без тега: CAPABILITY

Возможные ответы с тегом

OK - команда выполнена

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Любое состояние


Команда

NOOP

Аргументы

-

Описание

Нет операции.

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Любое состояние



Команда

LOGOUT

Аргументы

-

Описание

Команда информирует сервер, что клиент хочет закрыть соединение.

Возможные ответы без тега

Обязательный ответ без тега: BYE

Возможные ответы с тегом

OK - команда выполнена

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Любое состояние



Команда

AUTHENTICATE <am>

Аргументы

am - название механизма идентификации

Описание

По этой команде сервер начинает процесс идентификации в соответствии с указанным механизмом по RFC 1731 [6]. Сервер может также согласовать механизм дополнительной защиты для последующих взаимодействий протокола. Если механизм идентификации не поддерживается, сервер должен ответить NO и отклонить команду. При успешной идентификации выдается сообщение OK, и сервер переходит в состояние Authenticated.

Возможные ответы без тега

Могут быть запрошены данные продолжения

Возможные ответы с тегом

OK - идентификация выполнена

NO - идентификация не выполнена, механизм идентификации не поддерживается

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Not-Authenticated



Команда

LOGIN <user> <pass>

Аргументы

user - идентификатор клиента

pass пароль

Описание

Идентификация клиента и пересылка серверу незакодированного текстового пароля.

Возможные ответы без тега


Возможные ответы с тегом

OK - идентификация выполнена, состояние authenticated

NO - идентификация не выполнена

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Not-Authenticated

Команда

SELECT <mn>

Аргументы

mn - имя почтового ящика

Описание

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

Если клиенту разрешено модифицировать почтовый ящик, сервер может в ответе с тегом OK перед текстом указать код ответа "[READ-WRITE]"

Если клиенту не разрешено модифицировать почтовый ящик, сервер должен в ответе с тегом OK перед текстом указать код ответа "[READ-ONLY]"

Возможные ответы без тега

Обязательные ответы без тега: FLAGS, EXISTS, RECENT

Необязательные ответы ОК без тега: UNSEEN, PERMANENTFLAGS

Возможные ответы с тегом

OK - выбор выполнен, состояние selected

NO - ошибка выбора, состояние authenticated

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

EXAMINE <mn>

Аргументы

mn - имя почтового ящика

Описание

Команда EXAMINE является идентичной команде SELECT. Выбранный почтовый ящик всегда открывается без разрешения модификации (READ-ONLY).

Возможные ответы без тега

Обязательные: FLAGS, EXISTS, RECENT

Необязательные ответы OK: UNSEEN, PERMANENTFLAGS

Возможные ответы с тегом

OK - команда выполнена, состояние selected

NO - ошибка выбора, состояние authenticated

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

CREATE <mn>

Аргументы

mn - имя почтового ящика

Описание

Создание почтового ящика с заданным именем.

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

Если символ отделения уровня иерархии появляется внутри имени почтового ящика, сервер может создавать почтовые ящики (несколько почтовых ящиков) таким образом, чтобы их структура соответствовала заданному имени. Например, при попытке создать ящик "foo/bar/zap" (символ “/" является отделителем иерархии) сервер создает иерархические ящики foo/, foo/bar и foo/bar/zap.

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

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка создания

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

DELETE <mn>

Аргументы

mn - имя почтового ящика

Описание

Удаление почтового ящика.

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

(Удаление foo не должно удалить foo/bar).

Является ошибкой попытка удаления ящика высших иерархических имен, клиентом почтового ящика имеющего низшие иерархические имена и атрибут /Noselect.

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

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка удаления

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

RENAME <exmn> <newmn>

Аргументы

exmn существующее имя с почтового ящика

newmn - новое имя почтового ящика

Описание

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

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

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка удаления

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

SUBSCRIBE <mb>

Аргументы

mb - почтовый ящик

Описание

Добавляет заданное имя почтового ящика к набору активных (подписанных) почтовых ящиков.

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

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка выполнения команды

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

UNSUBSCRIBE <mb>

Аргументы

mb - почтовый ящик

Описание

Удаляет заданное имя почтового ящика из списка активных (подписанных) почтовых ящиков.

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка выполнения команды

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

LIST <rn> <mn>

Аргументы

rn - ссылочное имя

mn - шаблон имени почтового ящика

Описание

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

Почтового ящика.

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

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

Возможные ответы без тега

LIST

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка выполнения команды

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

LSUB <rn> <mn>

Аргументы

rn - ссылочное имя

mn - шаблон имени почтового ящика

Описание

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

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

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

Возможные ответы без тега

LSUB

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка выполнения команды

BAD неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

STATUS <mn> <data>

Аргументы

mn - имя почтового ящика

data - имена пунктов данных статуса

Описание

Команда статуса запрашивает статус указанного почтового ящика. Она не должна влиять на состояние сообщений в указанном ящике (в частности, не должна сбрасывать флаг \Recent).

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

Имена пунктов данных статуса могут быть:

MESSAGES количество сообщений в почтовом ящике

RECENT количество сообщений с выставленным флагом \Recent

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

UIDVALIDITY значение валидности уникального идентификатора для почтового ящика.

UNSEEN - количество сообщений, в которых не установлен флаг \Seen .

Возможные ответы без тега

STATUS

Возможные ответы с тегом

OK команда выполнена

NO ошибка выполнения команды

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

APPEND <mn> [<flags>] [<date>/<time>] <ml>

Аргументы

mn - имя почтового ящика

flags - список в скобках флагов

date - строка дата/время

ml - литерал сообщения

Описание

Команда добавляет аргумент ml в качестве нового сообщения в конец обозначенного почтового ящика. Аргумент ml должен иметь формат, согласно RFC 822 [2]. В сообщении разрешены восьмибитные символы. Если сервер не может правильно сохранить восьмибитные символы, то в сервере должно быть осуществлено преобразование восьмибитных символов в семибитный код, соответствующий MIME-IMB, а также выполнено и обратное преобразование.

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

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

Частичное добавление в случае возникновения ошибки запрещено.

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

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

NO - ошибка выполнения команды

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Authenticated, Selected



Команда

CHECK

Аргументы

-

Описание

Команда запрашивает контрольную точку текущего почтового ящика.

Если команда не реализована, она должна выполняться подобно NOOP.

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Selected

Команда

CLOSE

Аргументы

-

Описание

Команда удаляет из текущего выбранного почтового ящика все сообщения, имеющие флаг \Deleted, и переводит сервер в состояние authenticated.

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

Возможные ответы без тега

-

Возможные ответы с тегом

OK - команда выполнена, состояние authenticated

NO - ошибка закрытия

BAD - неизвестная команда или ошибка в аргументах

Разрешенные состояния

Selected



Команда

EXPUNGE

Аргументы

-

Описание

Команда удаляет из текущего выбранного почтового ящика все сообщения, имеющие флаг \Deleted.

Перед выдачей ответа OK для каждого удаленного сообщения высылается ответ EXPUNGE.

Возможные ответы без тега

EXPUNGE

Возможные ответы с тегом