rd_45.134-2000 (524304), страница 5
Текст из файла (страница 5)
Примечание 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
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: .... .... RCPT to: | На данном шаге идентифицируется один или больше адресатов. Каждая команда 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 .
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
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 состоит из установления соединения клиент/сервер, начального приветствия от сервера и взаимодействия клиент/сервер. В ходе сессии сервер и клиент обмениваются сообщениями. Сообщения разделяются на команды клиента и ответы сервера. В ответы сервера включаются данные, передаваемые сервером клиенту и результаты выполнения команд. Все сообщения передаются клиентом и сервером в форме строк, заканчивающимися символом .
2.2. Взаимодействие
2.2.1. Состояния сервера
В сервере должны быть реализованы следующие состояния:
AUTHORIZATION
TRANSACTION
UPDATE
Типичная последовательность переходов состояний сервера показана на рис. 1.
2.2.1.1. Сервер должен находиться в состоянии AUTHORIZATION после установления соединения TCP и выдачи им ответа приветствия.
Если процесс идентификации прошел успешно (т.е. клиент может получить доступ к соответствующему почтовому ящику), сервер открывает почтовый ящик и переходит в состояние TRANSACTION. При этом все метки удаления почтовых сообщений сброшены.
Если происходит ошибка при открытии почтового ящика, сервер отвечает отрицательным сообщением. После отрицательного ответа сервер может закрыть соединение. В случае, если соединение не закрыто, в сервере должны быть реализованы повторная идентификация и команда QUIT.
После того, как сервер открыл почтовый ящик, для каждого почтового сообщения должен быть выделен номер, начиная с 1. Номера должны последовательно возрастать на 1. В командах и ответах номера почтовых сообщений должны быть представлены в десятичном формате.
В состоянии AUTHORIZATION должны быть реализованы команды как минимум одного из механизмов идентификации, приведенных в п. 3.3.2., и команда QUIT.
Рис. 1 Типичная последовательность состояния сервера
2.2.1.2. Состояние TRANSACTION















