РД 45.134-2000 (rd_45.134-2000)

Посмотреть архив целиком


РД 45.134-2000






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
















Средства технические телематических служб



Общие технические требования
















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


Москва





Предисловие



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

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


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


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


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


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































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




Содержание



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

  2. Нормативные ссылки………………………………………………………………………...6

  3. Обозначения и сокращения………………………………………………………………….8

  4. Технические требования…………………………………………………………………....16

5. Требования к техническому обеспечению.............................................................................17

6. Требования к надежности и достоверности...........................................................................18

7. Требования к диагностике........................................................................................................19

8. Требования к электропитанию.................................................................................................20

9. Требования к электробезопасности и электромагнитной совместимости..........................21

10. Требования по устойчивости к климатическим факторам..................................................22

11.Требования к документации……………………………………………………………………………….23

12. Приложение 1………………………………………………………………………………...24

13. Приложение 2……………………………………………………………………………...…40

14. Приложение 3………………………………………………………………………………...53

15. Приложение 4……………………………………………………………………………...…89

16. Приложение 5……………………………………………………………………………….115

17. Приложение 6……………………………………………………………………………….153

18. Приложение 7……………………………………………………………………………….161






































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



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

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

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

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

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

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

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

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



























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



[1] Рекомендация Простой протокол передачи почты, 1982г.

IETF RFC 821 (Simple Mail Transfer Protocol)


[2] Рекомендация Стандарт для формата текстовых сообщений Интернета

IETF RFC 822 ARPA., 1982г.

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


[3] Рекомендация Протокол почтового офиса, 1996г.

IETF RFC 1939 (Post Office Protocol – Version 3)


[4] Рекомендация Команда AUTH протокола POP3, 1994г.

IETF RFC 1734 (POP3. AUTHentication command)


[5] Рекомендация Алгоритм цифрового сообщения MD5, 1992г.

IETF RFC 1321 (The MD5 Message-Digest Algorithm)


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

IETF RFC 1731 (IMAP4. Authentication Mechanisms)


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

IETF RFC 1733 (Distributed Electronic Mail Models in IMAP4)


[8] Рекомендация MIME (Многоцелевые расширения почты Интернета). Часть 1:

IETF RFC 2045 Формат тела сообщения Internet.,1996г.

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


[9] Рекомендация Выделение номера., 1994г.

IETF RFC 1700 (Assigned Number)


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

IETF RFC 1730 (Internet Message Access Protocol – version 4)


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

IETF RFC 2060 (Internet Message Access Protocol – version 4rev1)


[12] Рекомендация Доменные имена.Концепции и возможности., 1987г.

IETF RFC 1034 (Domain name – concepts and facilities)


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

IETF RFC 1035 (Domain name – implementation and specification)


[14] Рекомендация Протокол передачи гипертекста – HTTP/1.1, 1997г.

IETF RFC 2068 (Hypertext Transfer Protocol – HTTP/1.1)




[15] Рекомендация Процедура регистрации типа информации,1996г.

IETF RFC 2048 (Media Type Registration Procedure)



[16] ISO-8859 Международный стандарт по обработке информации – 8-ми

битные однобайтовые наборыкодов графических символов.

(International Standart - Information Processing - 8-bit Single Byte

Coded Graphic Character Sets.)


[17] Рекомендация MIME (Многоцелевые расширения почты Интернета). Часть 3:

IETF RFC 2047 Расширения заголовка для не 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] Рекомендация Стандарт для обмена USENET сообщениями., 1987г.

IETF RFC 1036 (Standart for interchange of USENET messages)


[20] Рекомендация Стандарт для обмена USENET сообщениями., 1983г.

IETF RFC 850 (Standart for interchange of USENET messages)


[21] Рекомендация Спецификация формата файла GZIP версии 4.3., 1996г.

IETF RFC 1952 (GZIP file format specification version 4.3)


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

IETF RFC 1766 (Tags for the identification of languages)


[23] ISO-639 Коды для представления названий языков.,1988г.

(Code for representation of names languages)


[24] ISO-3166 Коды стран.

(Country codes)


[25] Рекомендация Поле заголовка Content-MD5.,1995

IETF RFC 1864 (The Content-MD5 Header Field)


[26] Рекомендация Протокол передачи сетевых новостей, 1986г.

IETF RFC 977 (Network News Transfer Protokol)


[27] Рекомендация Протокол передачи файлов, 1985г.

IETF RFC 959 (File Transfer Protocol)


[28] Рекомендация Выделенные числа, 1985г.

IETF RFC 943 (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 - последовательность символов R> и <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.


NNTPNetwork 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 или более октетов (включая символы и ), которой предшествует счетчик октетов. Формат счетчика октетов: открывающаяся фигурная скобка “{“, число октетов, закрывающаяся фигурная скобка “}”, . В случае, когда литерал посылается от клиента серверу, клиент должен ждать получения запроса продолжения команды перед отправлением данных (и остатка команды). Даже если счетчик октетов равен 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 % (без конденсата).

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












































11. Требования к документации.


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

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

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

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

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

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

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






































Приложение 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. Команды


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

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

Аргументы

-

Описание

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

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

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

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

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

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

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

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

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






Команда

SEND FROM:

Аргументы

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

Описание

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

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

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

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

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


Команда

SOML FROM:

Аргументы

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

Описание

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

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

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

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

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


Команда

SAML FROM:

Аргументы

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

Описание

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

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

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

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

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


Команда

RSET

Аргументы

-

Описание

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

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

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

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


Команда

VRFY

Аргументы

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

Описание

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

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

-


Команда

EXPN

Аргументы

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

Описание

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

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

-


Команда

HELP []

Аргументы

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


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


3.2. Ответы

3.2.1. Код ответа


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


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


первая цифра

1

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

2

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

3

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

4

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

5

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


вторая цифра

0

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

1

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

2

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

3

не определен

4

не определен

5

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


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


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

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

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

символа ,

текста,

символа .

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

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

символа "-"

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

символа


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

символа "-"

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

символа


.....

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

символа ,

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

символа .




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


Таблица 2

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


Код

Текст

211

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

214

Ответ помощи

220

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

221

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

250

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

251

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

354

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

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

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

512 символов

reply line

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

512 символов

text line

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

1000 символов

Recipient buffer

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

100 адресатов



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



::= "HELO" 1*


::= "MAIL" 1* "FROM:"


::= "RCPT" 1* "TO:"


::= "DATA"


::= "RSET"


::= "SEND" 1* "FROM:"


::= "SOML" 1* "FROM:"


::= "SAML" 1* "FROM:"


::= "VRFY" 1*


::= "EXPN" 1*


::= "HELP" [1* ]


::= "NOOP"


::= "QUIT"


::= "TURN"


::=


::=


::= "<" [ ":" ] ">"


::= | ","


::= "@"


::= | "."


::= | "#" | "[" "]"


::= "@"


::= |


::=


::= |


::= |


::= | | "-"


::= | "."


::= |


::= """ """


::= "\" | "\" | |


::= | "\"


::= "." "." "."


::= |


::=


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


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


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


::= одна, две или три десятичные цифры, представляющие

десятичное число в диапазоне от 0 до 255


::= любой из 52 алфавитных строчных и прописных

символа от A до Z и от a до z


::= любой из 128 символов ASCII кроме

or


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


::= любой из 128 символов ASCII кроме ,

, кавычек ("), или (\)


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


::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."

| "," | ";" | ":" | "@" """ | управляющие

символы (коды ASCII от 0 до 31 включительно, а так же

127)


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

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

Примечание 2: для именования узлов используются две дополнительные

числовые формы. Первая форма состоит из символа "#", за которым следует

целое десятичное число, являющееся адресом узла. Вторая форма состоит из 4-х

целых десятичных чисел, разделенных точками и заключенных в квадратные

скобки. Вторая форма соответствует адресу IP.

::= "Return-Path:"

::= "Received:"


::= ";"


::= "FROM"


::= "BY"


::= [] [] [] []


::= "VIA"


::= "WITH"


::= "ID"


::= "FOR"


::= Стандартные имена соединений (links),

зарегистрированные в организации Network

Information Center


::= Стандартные имена протоколов, зарегистрированные

в организации Network Information Center


::=


::=



::= однозначное или двузначное десятичное число,

обозначающее день в диапазоне от 1 до 31


::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |

"JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"


::= двузначное десятичное число, обозначающее год столетия

в диапазоне от 00 до 99


::= двузначное десятичное число, обозначающее часы дня в

диапазоне от 00 до 23


::= двузначное десятичное число, обозначающее минуты часа в

диапазоне от 00 до 59


::= двузначное десятичное число, обозначающее секунды

минуты в диапазоне от 00 до 59


::= "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:

R: 250 OK


S: RCPT TO:

R: 250 OK


S: RCPT TO:

R: 550 No such user here


S: RCPT TO:

R: 250 OK


S: DATA

R: 354 Start mail input; end with .


Случайные файлы

Файл
30-35,38-41.doc
MS DOS.doc
1.doc
166864.rtf
задача 89.doc