Опубликован: 10.10.2007 | Доступ: свободный | Студентов: 3342 / 453 | Оценка: 4.40 / 4.15 | Длительность: 35:10:00
ISBN: 978-5-94774-708-9
Лекция 4:

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

Команда FETCH

Аргументы: набор сообщений,
имена информационных сообщений.
Отклики: немаркированные отклики: FETCH
Результат: OK операция успешно завершена;
NO команда не прошла: не удалось доставить эти данные;
BAD команда неизвестна или неверен аргумент.

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

ALL: Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
BODY: Нерасширяемая форма BODYSTRUCTURE.
BODY[<section>]<< partial >>

BODY — текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен:

HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT.

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

Сообщения не-[MIME-IMB] и несоставные сообщения [MIMEIMB] без инкапсуляции имеют только часть 1.

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

Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT и TEXT являются базовыми. Перед ними могут размещаться один или более числовых спецификаторов частей сообщения, которые указывают на принадлежность типу MESSAGE/RFC822. Перед спецификатором части MIME должны размещаться один или более числовых спецификаторов. Спецификаторы частей HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT относятся к заголовку сообщения [RFC-822] или инкапсулированному сообщению [MIME-IMT]MESSAGE/RFC822. За HEADER.FIELDS и HEADER.FIELDS.NOT следует список имен полей (как это определено в [RFC-822]). Субнабор, возвращаемый HEADER.FIELDS, содержит только те поля заголовка, имена которых соответствуют одному из имен списка. Аналогично, субнабор, возвращаемый HEADER.FIELDS.NOT, содержит только поля заголовка с несоответствующими именами полей. Соответствие является точным, но нечувствительным к использованию строчных и прописных букв. Во всех случаях вставляется разграничивающая пустая строка между заголовком и телом сообщения.

Спецификатор MIME части относится к заголовку [MIME-IMB] этой части. Спецификатор текстовой части относится к телу сообщения, без заголовка [RFC-822]. Ниже приведен пример составного сообщения с некоторыми спецификаторами его частей:

HEADER ([RFC-822] заголовок сообщения)
TEXT MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.HEADER ([RFC-822] заголовок сообщения)
3.TEXT ([RFC-822] текстовое тело сообщения)
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/MIXED
4.1 IMAGE/GIF
4.1.MIME ([MIME-IMB] заголовок для IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2.HEADER ([RFC-822] заголовок сообщения)
4.2.TEXT ([RFC-822] текстовое тело сообщения)
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT

Имеется возможность доставить субстроку определенного текста. Это делается путем присоединения к спецификатору требующейся части открытой угловой скобки ("<"), положения первого нужного октета, точки, максимального требуемого числа октетов и закрывающей угловой скобки. Если начальный октет находится за пределами текста, возвращается пустая строка.

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

Замечание: это означает, что запрос BODY[]<0.2048> сообщения длиной 1500 октетов пришлет BODY[]<0> с литералом размером 1500, а не BODY[].

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

BODY.PEEK[<section>]<partial> Альтернативная форма BODY[<section>], которая не устанавливает флаг \Seen.
BODYSTRUCTURE Структура тела сообщения [MIME-IMB]. Она вычисляется сервером путем разбора полей заголовка [MIME-IMB] [RFC-822] и заголовков [MIME-IMB].
ENVELOPE Структура заголовка сообщения. Она вычисляется сервером в результате разбора заголовка [RFC-822] на части, присваивая им значения по умолчанию, если это необходимо.
FAST Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE)
FLAGS Флаги, присвоенные сообщению.
FULL Макро эквивалент (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
INTERNALDATE Внутренняя дата сообщения.
RFC822 Функционально эквивалентно BODY[], отличается по синтаксису результирующих немаркированных данных (возвращается RFC822).
RFC822.HEADER Функционально эквивалентно BODY.PEEK[HEADER], отличается по синтаксису результирующих немаркированных данных (возвращает данные в формате RFC822.HEADER).
RFC822.SIZE Размер сообщения [RFC-822].
RFC822.TEXT Функционально эквивалентно BODY[TEXT], отличается по синтаксису результирующих немаркированных данных (возвращается RFC822.TEXT).
UID Уникальный идентификатор сообщения.

Команда STORE

Аргументы: набор сообщений,
имя элемента сообщения,
значение элемента сообщения.
Отклики: немаркированные отклики: FETCH.
Результат: OK операция успешно завершена;
NO команда не прошла: данные не могут быть запомнены;
BAD команда неизвестна или неверен аргумент.

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

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

В настоящее время определены следующие элементы данных.

FLAGS <список флагов> Заменить флаги для сообщения, приведенного в аргументе. Новое значение флагов присылается, как если бы выполнялась команда FETCH для этих флагов.
FLAGS.SILENT <список флагов> Эквивалентно FLAGS, но без возвращения нового значения.
+FLAGS <список флагов> Добавить аргумент к флагам сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.
+FLAGS.SILENT <список флагов> Эквивалентно +FLAGS, но без возвращения нового значения.
-FLAGS <список флагов> Удаляет аргумент из флагов сообщения. Новое значение флагов возвращается, как при исполнении команды FETCH.
-FLAGS.SILENT <список флагов> Эквивалентно -FLAGS, но без возвращения нового значения.

Пример:

C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH FLAGS (\Deleted\Seen)
S: * 3 FETCH FLAGS (\Deleted)
S: * 4 FETCH FLAGS (\Deleted\Flagged \Seen)
S: A003 OK STORE completed

Команда COPY

Аргументы: набор сообщений,
имя почтового ящика.
Отклики: Команда не требует какого-либо специального отклика.
Результат: OK команда успешно завершена;
NO команда не прошла: не могут быть скопированы эти сообщения вообще или в данный почтовый ящик;
BAD команда неизвестна или неверен аргумент.

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

Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика [TRYCREATE] в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.

Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик в состояние, которое он имел до выполнения COPY.

Пример:

C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed

Команда UID

Аргументы: имя команды,
аргументы команды.
Отклики: немаркированные отклики: FETCH, SEARCH.
Результат OK команда UID завершена;
NO команда UID не прошла;
BAD команда неизвестна или неверен аргумент.

Команда UID имеет две формы. В первой она использует в качестве аргумента имена команд COPY, FETCH или STORE (с их аргументами). Однако числа в списке аргументов в этом случае представляют собой уникальные идентификаторы, а не порядковые номера сообщений.

Во второй форме команда UID использует команду SEARCH с ее аргументами. Интерпретация аргументов та же, что и в случае SEARCH; однако, числа, возвращаемые в отклике на команду UID SEARCH, представляют собой уникальные идентификаторы, а не порядковые номера сообщений. Например, команда UID SEARCH 1:100 UID 443:557 возвратит уникальный идентификатор, соответствующий пересечению набора порядковых номеров сообщений 1:100 и набора UID 443:557.

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

Число после "*" в немаркированном отклике FETCH всегда является порядковым номером сообщения, а не уникальным идентификатором, даже для отклика на команду UID. Однако реализации сервера должны безоговорочно включать значения UID в качестве части любого отклика FETCH, вызванного командой UID, вне зависимости от того, был ли UID специфицирован в качестве элемента сообщения для FETCH.

Пример:

C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed
Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?

Нияз Сабиров
Нияз Сабиров

Здравствуйте. А уточните, пожалуйста, по какой причине стоимость изменилась? Была стоимость в 1 рубль, стала в 9900 рублей.