26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский




Название26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский
страница5/19
Дата конвертации25.02.2016
Размер3.35 Mb.
ТипДокументы
1   2   3   4   5   6   7   8   9   ...   19

...                                                           



                                                        

...                                                           

                                                       

.                                                             

header1 .. headern - строки заголовка почтового сообщения;    

line1 .. linem - начальные m строк тела почтового сообщения.  

При передаче строк заголовка и тела почтового сообщения должны

использоваться правила составления многострочного сообщения   

Описание Верхняя часть почтового сообщения                             


Ответ:   список uid                                                    

Структура +OK ; для однострочного ответа                      

n - номер сообщения                                           

uidm - уникальный идентификатор сообщения                     

+OK; для многострочного ответа                                

                                                  

...                                                           

                                                  

n - номер сообщения                                           

uidm - уникальный идентификатор сообщения                     

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


Ответ:   "готов"                                                       

Структура +<строка BASE64>                                              

Описание Вызов сервера после подачи пользователем команды AUTH         


Ответы могут быть однострочными и многострочными. В многострочных ответах строки


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


отделяются символами . Последняя строка многострочного ответа состоит из

заключительного октета (с десятичным кодом 46 (".")) и символов . Если строка

многострочного ответа начинается с символа ",", в начало этой строки добавляется еще один символ

".". Таким образом, критерием конца многострочного ответа является последовательность

"CRLF.CRLF". Оконечная последовательность ".CLRF" не считается частью многострочного ответа.


На нереализованные или нераспознанные команды сервер должен отвечать отрицательным

ответом. На команды, не разрешенные в данном состоянии, сервер должен отвечать отрицательным

ответом.


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


Список ответов с фиксированной структурой текста ответа приведен в табл. 2.


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


В приведенном ниже определении синтаксиса команд и ответов сервера POP3 используется

расширенная форма Наура-Бекуса, приведенная в рекомендации RFC 822 [2]. Замечание: в качестве

разделителя в конструкции "#" используется один пробел и не используются запятые. В случае

противоречия в приведенных определениях должно использоваться правило, указанное выше по

списку. Различие между строчными и прописными символами алфавита является несущественным.


;Команда


::="STAT"


              |"LIST"[]


              |"RETR"


              |"DELE"


              |"NOOP"


              |"RSET"


              |"QUIT"


              |"TOP"


              |"UIDL"[]


              |"USER"


              |"PASS"


              |"APOP"


              |"AUTH"


;Примечание 1: регистр символов в ключевых словах "STAT", "LIST",

...,


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


;"AUTH" не имеет значения


;Ответ


::=; Однострочный ответ


       |; Многострочный ответ


::=          ;Приветствие


                  |         ;Статус


                  |;Однострочный ответ


                                       ;"скан-список"


       |;Однострочный ответ


                                       ;"список идентификаторов"


                  |      ;Простой положительный ответ


                  |     ;Простой отрицательный ответ


                  |             ;Ответ сервера на команду AUTH


::=;Многострочный скан-список


          |  ;Сообщение


          | ;Верхняя часть сообщения


          | ;Список идентификаторов сообщений


;Примечание 2: длина строк ответа должна составлять не более 512


;символов включая


       ::="-OK"[]


         ::="+OK";Количество сообщений


                           ;в почтовом ящике


                    ;Размер почтового ящика


                   


  ::="+OK";Номер сообщения


                    ;Размер сообщения


                   


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


   ::="+OK";Номер сообщения


                    ;Идентификатор сообщения


                   


         ::= "+OK"; произвольный текст


::="-ERR"; произвольный текст


    ::= "+"<строка BASE64>; произвольный текст


::= "+OK"


          1*(;Номер сообщения


             ;Размер сообщения


             )


            "."


::="+OK"


         1*();Строки почтового сообщения


         "."


::="+OK>


         1*();Строки заголовка


        


         1*();Начальные строки сообщения


         "."


::="+OK"


          1*(;Номер сообщения


          ;Идентификатор сообщения


          )


          "."


::=<метка времени в соответствии с RFC 822 [2]>


::=


::=


::=2*(PRINT_ASCII|)


       |(EXCEPT_POINT_ASCII|)


::= *(PRINT_ASCII|)


     ::=1*40


     ::=1*40


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


     ::=


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


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


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


     ::=<любая цифра ASCII "0".."9">


::=<печатный символ ASCII>


::=<печатный символ ASCII, кроме символа ".">


::=<идентификатор в соответствии с RFC 1731 [6]>


5. ТРЕБОВАНИЯ К РЕАЛИЗАЦИИ СЕРВЕРА


5.1. Механизм ограничения объема хранящихся сообщений


В сервере может быть реализован механизм ограничения объема хранящихся сообщений.


5.2. Механизм удаления сообщений, хранящихся дольше установленного срока


В сервере может быть реализован механизм удаления сообщений, хранящихся дольше

установленного срока.


Приложение 3


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


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


ПО ПРОТОКОЛУ IMAP4


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


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Настоящее Приложение описывает технические требования к ТС службы ЭП по протоколу

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 в качестве

протокола нижнего уровня ТСР должен использоваться порт 143.


2.1.2. Общая структура протокола


Сессия протокола IMAP4 состоит из установления соединения клиент/сервер, начального

приветствия от сервера и взаимодействия клиент/сервер. В ходе сессии сервер и клиент

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

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

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

символами .


2.1.3. Соответствие команд и ответов


Команда клиента начинает выполнение операции. В начале каждой команды клиента стоит тег.

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

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

команды клиента. Значение тега в ответе с тегом должно быть идентично значению тега

соответствующей команды клиента.


В ответах без тега вместо тега должен следовать символ "*" или символ "+".


2.2. Состояния


Сервер может находиться в одном из 4-х состояний:


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Non-Authenticated ("не идентифицирован");


Authenticated ("идентифицирован");


Selected ("выбран");


Logout ("разъединение").


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

сервер должен выдавать ответ результата выполнения команды BAD или NO. Диаграмма типовых

переходов состояний приведена на рис. 1.


---------------------------------------------------------------------

-----¬


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

сервера             ¦


L-----------------------T------------T---------------------T---------

------


                       \/ 1          ¦                      ¦ 3


              -------------------¬    ¦                      ¦


              ¦ Не идентифицирован ¦    ¦ 2                   ¦


              L---T---------T-----    ¦                      ¦


                  ¦ 7       \/ 4     \/                    ¦


                  ¦      ----------------¬                   ¦


                  ¦      ¦ Идентифицирован ¦ < -¬                ¦


                  ¦      L---T--------T---   ¦                ¦


                  ¦          ¦         \/ 5  ¦ 6             ¦


                  ¦          ¦ 7   -------¬ ¦                ¦


                  ¦          ¦      ¦ Выбран +--                ¦


                  ¦          ¦      L--T----                  ¦


                  \/        \/       \/ 7                  \/


---------------------------------------------------------------------

-----¬


¦                              

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


L--------------------------------------------------------------------

------


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Рисунок 1. Диаграмма типовых переходов состояний


На рис. 1 цифрами обозначены:


1 - соединение без преидентификации (приветствие OK);


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. Иерархическое именование почтовых ящиков


При необходимости экспортировать иерархические имена почтовых ящиков имена почтовых

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

символа, разделяющего уровни иерархии. Один и тот же разделитель иерархии должен


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


использоваться для всех уровней иерархии внутри одного родительского имени.


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

добавлены новые сообщения.


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.

1   2   3   4   5   6   7   8   9   ...   19

Похожие:

26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconСогласовано руководитель Департамента здравоохранения города Москвы А. П. Сельцовский
Методические рекомендации предназначены для всех сторон, участвующих в организации и проведении профилактических медицинских осмотров...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon«согласовано» Руководитель по направлению деятельности

26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconГосударственный центр современного искусства
К участию в сетевом проекте "Агитация за искусство". Первый этап проекта пройдет в Екатеринбурге с 15 ноября по 15 декабря 2000 года,...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon24 июня 2003 года Дата введения
А. В.); Всероссийским нии защиты растений (Долженко В. И. и др.); при участии Департамента
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon«согласовано» Начальник Северного окружного управления образования
Руководитель вмо «Сокол» в г. Москве, член Президиума Совета муниципальных образований по сао г. Москвы
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon«22» июня 2012г согласовано
Адмиралтейского района, финансирование которых осуществляется с использованием субсидий
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconПресс-релиз руди штанцель
С 14 июня по 10 сентября 2000 года в Австрийском музее прикладного искусства (мак) прошла выставка "реформель" австрийского художника...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconБюро стандартизации электросвязи
...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconБюро стандартизации электросвязи
...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconБудет объявлена дополнительно
Д-р Андраш Чепреги (профессор богословия, руководитель Департамента по делам связей с церковью при Министерстве образования и культуры...
Разместите кнопку на своём сайте:
kaz.docdat.com


База данных защищена авторским правом ©kaz.docdat.com 2013
обратиться к администрации
kaz.docdat.com
Главная страница