Почтовые протоколы POP3 и IMAP

Отклик FETCH

Отклик FETCH возвращает данные о сообщении клиенту. Данные объединяются в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера, например, об изменении флагов. В настоящее время существуют следующие информационные элементы:

BODY Форма BODYSTRUCTURE без расширения данных.
BODY[<section>]<<origin_octet>>

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

Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что BODY[ ]<0> может быть укорочено, но BODY[ ] никогда не укорачивается.

Если идентификатор [CHARSET] является частью списка параметров тела секции, допустимы 8-битовые текстовые данные. Заметьте, что заголовки (спецификаторы частей HEADER, MIME или часть заголовка секции MESSAGE/RFC822), должны содержать только 7-битовые символы (применение 8-битовых символов в заголовке запрещено). Заметим также, что пустая строка в конце заголовка всегда включается в текст заголовка.

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

BODYSTRUCTURE — список, заключенный в скобки, который описывает [MIME-IMB], и структура тела сообщения.

Эта структура формируется сервером путем разбора полей заголовка [MIME-IMB] и подстановки при необходимости значений по умолчанию.

Например, простое текстовое сообщение из 48 строк и 2279 октетов может иметь структуру тела: (TEXT PLAIN (CHARSET US-ASCII) NIL NIL 7BIT 2279 48)

Если имеется несколько частей, они выделяются вложенными скобками. Вместо типа тела в качестве первого элемента списка используется тело с иерархической структурой. Вторым элементом списка, заключенного в скобки, является составной субтип (mixed, digest, parallel, alternative, и т.д.).

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

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

Список содержит пары атрибут/значение [например, (foo bar baz rag), где bar представляет собой значение foo, а rag является значением baz] как это определено в [MIME-IMB].

Размещение тела

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

Язык тела

Строка или список в скобках, определяющие язык, так, как это задано в [LANGUAGE-TAGS].

Тип тела

Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].

Субтип тела

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

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

Список пар атрибут/значение, заключенный в скобки, [например, (foo bar baz rag), где bar является значением foo, а rag — значением baz], как это описано в [MIME-IMB].

Идентификатор тела

Строка, описывающая идентификатор содержимого, как это определено в [MIME-IMB].

Описание тела

Строка, предоставляющая описание содержимого, как это задано в [MIME-IMB].

Шифрование тела

Строка, предоставляющая транспортную кодировку, как это задано в [MIME-IMB].

Размер тела

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

Тип тела MESSAGE и субтип RFC822 сразу после базовых полей содержат структуру заголовка, структуру тела и размер вложенного сообщения в строках.

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

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

Эти расширения для несоставной части тела располагаются в следующем порядке.

MD5 тела

Строка, содержащая значение MD5 тела, как это описано в [MD5].

Размещение тела

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

Язык тела

Строка или список, заключенный в скобки, определяющие язык тела, как это задано в [LANGUAGE-TAGS].

ENVELOPE — список, заключенный в скобки, который описывает структуру заголовка (конверта) сообщения. Он формируется сервером в результате разбора заголовка [RFC-822], при необходимости некоторым полям присваиваются значения по умолчанию.

Поля структуры конверта размещаются в следующем порядке: дата, subject (предмет сообщения), from (от), отправитель, reply-to (ответ на), to, cc, bcc, in-reply-to (в ответ на), и идентификатор сообщения. Поля дата, subject, in-reply-to и идентификатор сообщения являются строками. Поля from, отправитель, reply-to, to, cc и bcc являются списками адресных структур, заключенными в скобки.

Адресная структура представляет собой список, который описывает электронный почтовый адрес. Поля адресной структуры размещаются в следующем порядке: персональное имя, [ SMTP ] @-домен (маршрут отправителя), имя почтового ящика и имя ЭВМ.

Синтаксис группы [RFC-822] определяется специальной формой адресной структуры, в которой поле имени ЭВМ равно NIL. Если поле имени почтового ящика также равно NIL, это является концом группового маркера (двоеточие в синтаксисе RFC 822). Если поле имени почтового ящика не равно NIL, это обозначает начало группового маркера, а поле имени почтового ящика содержит имя группы.

Любое поле в конверте или адресной структуре, которое не используется, характеризуется значением NIL. Заметим, что сервер должен заполнять по умолчанию поля reply-to и sender из поля from. Кроме того, определены следующие информационные объекты.

Отклики сервера — запрос продолжения команды

Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.

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

Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.