Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача
| Вид материала | Задача |
- Поурочне планування курсу "Основи Інтернет – технологій", 88.8kb.
- Работа nat введение, 150.17kb.
- 1. Сервіси Internet, 731.38kb.
- 1. Сервіси Internet, 347.99kb.
- Internet Information Services (iis). Понимание организации сетей, tcp/ip и Domain Name, 17.07kb.
- Что такое Internet? Ресурсы Internet*, 347.7kb.
- Лабораторна робота №19 ”Internet”, 103.46kb.
- Е. Е. Израилевич Практическая грамматика английского языка с упражнениями и ключами, 14711.83kb.
- Математическая логика сквозь школьные предметы, 133.29kb.
- Мифы и реальности Internet известные и скрытые возможности сети Что такое Internet, 306.75kb.
5.3.9. Команда LSUB
Аргументы: имя-шаблон,
имя почтового ящика может содержать символы подмены (wildcards).
Отклики: немаркированный отклик: LSUB
| Результат: | OK | команда успешно исполнена; |
| NO | команда не прошла: не возможна выдача списка для предлагаемого шаблона или имени; | |
| BAD | команда неизвестна или неверен аргумент. |
Команда LSUB возвращает субнабор имен из списка пользователя, который декларирован как "активный" или "подписной". При этом отправляется нуль или более немаркированных откликов LSUB. Аргументы LSUB имеют тот же формат, что и для команды LIST.
Сервер может проверить имена из подписного листа с тем, чтобы проверить, существуют ли они еще. Если имени не существует, оно должно быть помечено в отклике LSUB атрибутом \Noselect. Сервер не должен по своему усмотрению удалять имена почтовых ящиков из подписного листа даже, если такого ящика более не существует.
Пример: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
5.3.10. Команда STATUS
Аргументы: имя почтового ящика, статусная информация имен.
Отклики: немаркированные отклики: STATUS.
Результат: OK - команда успешно выполнена;
NO - команда не прошла: нет статусной информации для данного имени;
BAD - команда неизвестна или неверен аргумент.
Команда STATUS запрашивает статусные данные для указанного почтового ящика. Она не изменяет выбор почтового ящика и не вносит каких-либо изменений в состояние сообщений для запрошенного ящика (в частности команда STATUS не должна вызывать потерю флага \Recent).
Команда STATUS предоставляет альтернативу открытию дополнительного IMAP 4.1 соединения и реализует команду EXAMINE для запрашиваемого почтового ящика, не изменяя выбора, выполненного при первичном соединении.
В отличии от команды LIST, команда STATUS не гарантирует быстрого отклика. В некоторых реализациях сервер обязан открыть почтовый ящик в режиме "только чтение", чтобы получить нужные статусные данные. Кроме того, команда STATUS не допускает символов подмены в шаблоне имени. В настоящее время определены следующие статусные данные, которые могут быть запрошены:
| MESSAGES | Число сообщений в почтовом ящике |
| RECENT | Число сообщений с установленным флагом \Recent |
| UIDNEXT | Следующее значение, которое будет предписано новому сообщению в почтовом ящике. Гарантируется, что это значение не изменится, если только в ящик не будет положено новое сообщение. UID будет изменен при укладке нового сообщения, даже если оно после этого стерто. |
| UIDVALIDITY | Уникальный валидатор почтового ящика |
| UNSEEN | Число сообщений, не имеющих установленного флага \Seen |
Пример: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed
5.3.11. Команда APPEND
Аргументы: имя почтового ящика,
опционно - флаг списка со скобками,
опционно - строка даты и времени,
литерал сообщения
Отклики: команда не требует какого-либо специального отклика
| Результат: | OK | команда успешно исполнена |
| NO | команда не прошла: добавление в почтовый ящик не удалось, ошибка во флагах или дате/времени, или в тексте сообщения | |
| BAD | команда неизвестна или неверен аргумент |
Команда APPEND добавляет литеральный аргумент в качестве нового сообщения в почтовый ящик. Этот аргумент должен следовать формату сообщений [RFC-822]. Допускается использование в сообщениях 8-битовых символов. Реализация сервера, которая не может работать с 8-битовыми данными, должна быть способна преобразовывать 8-битовую информацию APPEND в 7-битовую, используя транспортное кодирование [MIME-IMB]. Если специфицирован флаг списка со скобками, в результирующих сообщениях должны быть установлены флаги, в противном случае список флагов будет установлен по умолчанию пустым.
Если специфицировано date_time, в результирующем сообщении должна быть установлена внутренняя дата, в противном случае, внутренняя дата и время результирующего сообщения будут установлены по умолчанию равными текущим значениям. Если команда append по какой-то причине не прошла, почтовый ящик должен быть возвращен в состояние, которое он имел до команды APPEND.
Если почтовый ящик места назначения не существует, сервер должен сообщить об ошибке, а не должен автоматически создавать новый почтовый ящик. Если не ясно, может или нет быть создан почтовый ящик, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это указывает клиенту на возможность попытки исполнения команды CREATE, после чего, в случае успеха, повторить команду APPEND.
Если в настоящее время почтовый ящик и выбран, то немедленно должны начаться почтовые операции. Сервер должен уведомить клиента об этом, послав немаркированный отклик EXISTS. Если сервер не делает этого, клиент после одной или более команд APPEND может выдать команду NOOP (или при неудаче команду CHECK).
Пример: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id:
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Замечание: команда APPEND не используется для доставки сообщений, так как она не содержит в себе механизма передачи служебной информации [SMTP].
5.4. Команды клиента в состоянии "выбор сделан"
В состоянии "выбор сделан", разрешены команды, которые манипулируют сообщениями в почтовом ящике. Помимо универсальных команд (CAPABILITY, NOOP и LOGOUT), а также команд режима аутентификации (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS и APPEND), в данном режиме доступны следующие команды: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY и UID.
5.4.1. Команда CHECK
Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика;
Результат: OK - проверка завершена;
BAD - команда неизвестна или неверен аргумент.
Команда CHECK осуществляет проверку выбранного почтового ящика. Проверка относится к любым характеристикам, зависящим от реализации (например, выявление положения почтового ящика в памяти сервера и на диске). Если сервер не поддерживает таких возможностей, команда эквивалентна NOOP.
Не существует гарантии, что в результате CHECK будет прислан немаркированный отклик. Для проверки поступления новой почты следует использовать команду NOOP, а не CHECK.
Пример: C: FXXZ CHECK
S: FXXZ OK CHECK Completed
5.4.2. Команда CLOSE
Аргументы: отсутствуют.
Отклики: команда не требует какого-либо специального отклика.
Результат: OK - команда выполнена, система в состоянии "аутентификация выполнена";
NO - команда не прошла, никакого ящика не выбрано;
BAD - команда неизвестна или неверен аргумент.
Команда CLOSE навечно удаляет из выбранного почтового ящика все сообщения, помеченные флагом \Deleted, и возвращает систему в состояние "аутентификация выполнена". Никакого немаркированного отклика EXPUNGE не посылается.
Никаких сообщений не удаляется и никаких флагов ошибки не возвращается, если почтовый ящик был выбран командой EXAMINE или находился в режиме "только для чтения".
Даже если почтовый ящик выбран, команды SELECT, EXAMINE или LOGOUT могут быть использованы без предварительного исполнения команды CLOSE. Команды SELECT, EXAMINE и LOGOUT безоговорочно закрывают выбранный в данный момент почтовый ящик без удаления сообщений. Однако когда удалено много сообщений, последовательность CLOSE-LOGOUT или CLOSE-SELECT значительно быстрее, чем EXPUNGE-LOGOUT или EXPUNGE-SELECT, так как здесь не посылается никаких немаркированных откликов EXPUNGE (которые клиент вероятно проигнорирует).
Пример: C: A341 CLOSE
S: A341 OK CLOSE completed
5.4.3. Команда EXPUNGE
Аргументы: отсутствуют.
Отклики: немаркированные отклики: EXPUNGE.
Результат: OK - команда успешно завершена;
NO - команда не прошла: стирание не выполнено (например, запрещено);
BAD - команда неизвестна или неверен аргумент.
Команда EXPUNGE навечно удаляет из выбранного почтового ящика все сообщения, которые помечены флагами \Deleted. Прежде чем выдать клиенту сигнал OK, посылается немаркированный отклик EXPUNGE для каждого из удаляемых сообщений.
Пример: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Замечание: в этом примере, сообщения 3, 4, 7 и 11 имеют установленный флаг \Deleted. Следует учитывать, что после каждого удаления сообщения перенумеруются.
5.4.4. Команда SEARCH
Аргументы: опционны, [CHARSET]-спецификация.
Критерии поиска (один или более).
Отклики: необходим немаркированный отклик: SEARCH.
Результат: OK - поиск завершен;
NO - ошибка: поиск для данного набора символов или критериев не возможен;
BAD - команда неизвестна или неверен аргумент
Команда SEARCH ищет почтовый ящик, который отвечает выбранным критериям отбора. Критерий отбора состоит из одного или более ключей поиска. Немаркированный отклик SEARCH от сервера содержит список номеров сообщений, которые соответствуют критериям отбора.
Когда специфицировано несколько ключей, результатом является (функция AND) совокупность всех сообщений, отвечающим заданным критериям. Например, критерий DELETED FROM "SMITH" SINCE 1-Feb-1994 относится ко всем стертым сообщениям от Смита, которые были положены в почтовый ящик после 1-го февраля 1994. (например, для объединения этих ключей с помощью функций OR и NOT).
Опционная спецификация [CHARSET] состоит из слова "CHARSET", за которым следует зарегистрированное наименование символьного набора [CHARSET]. Он включает в себя [CHARSET] строк, которые используются в качестве критерия отбора. Транспортное кодирование содержимого [MIME-IMB] и строки [MIME-HDRS] в [RFC-822]/[MIME-IMB] заголовках, должны декодироваться перед сравнением текста в представлении [CHARSET], отличном от US-ASCII. US-ASCII должно поддерживаться всегда, но могут использоваться и другие символьные наборы. Если сервер не поддерживает специфицированный набор символов [CHARSET], он должен вернуть маркированный отклик NO (но не BAD).
Для всех ключей поиска, которые используют строки, сообщение соответствует ключу, если строка является частью строки поля в сообщении. Соответствие не должно зависеть от использования строчных или прописных символов. Стандартными ключами поиска являются следующие слова и выражения.
| <набор сообщений> | Сообщения с номерами, соответствующими специфицированному набору номеров |
| ALL | Все сообщения в почтовом ящике. Ключ отбора по умолчанию для применения команд AND |
| ANSWERED | Сообщения с установленным флагом \Answered. |
| BCC <строка> | Сообщения, которые содержат специфицированную строку в поле BCC структуры заголовка сообщения. |
| BEFORE <дата> | Сообщения, чьи внутренние даты раньше указанной. |
| BODY <строка> | Сообщения, которые содержат специфицированную строку в теле сообщения. |
| CC <строка> | Сообщения, которые содержат специфицированную строку в CC поле заголовка. |
| DELETED | Сообщения с установленным флагом \Deleted. |
| DRAFT | Сообщения с установленным флагом \Draft. |
| FLAGGED | Сообщения c установленным флагом \Flagged. |
| FROM <строка> | Сообщения, которые содержат специфицированную строку в поле FROM заголовка. |
| HEADER <имя поля> <строка> | Сообщения, которые содержат заголовок со специфицированным именем поля (в соответствии с [RFC-822]) и специфицированную строку в теле данного поля. |
| KEYWORD <флаг> | Сообщения со специфицированным ключевыми словами. |
| LARGER | Сообщения с размером [RFC-822] больше чем специфицированное число октетов. |
| NEW | Сообщения, которые имеют установленный флаг \Recent, но не имеют флага \Seen. Это функционально эквивалентно "(RECENT UNSEEN)". |
| NOT <ключ поиска> | Сообщения, которые не содержат специфицированного ключевого слова. |
| OLD | Сообщения, которые не имеют флага \Recent. "NOT RECENT" (противоположно "NOT NEW"). |
| ON <дата> | Сообщения, чья внутренняя дата соответствует специфицированному значению даты. |
| OR <ключ поиска 1> <ключ поиска 2> | Сообщения, которые соответствуют любому из ключевых слов поиска. |
| RECENT | Сообщения, которые имеют установленный флаг \Recent. |
| SEEN | Сообщения, которые имеют установленный флаг \Seen. |
| SENTBEFORE <дата> | Сообщения, чье содержимое заголовка, соответствует дате ранее специфицированного значения [RFC-822]. |
| SENTON <дата> | Сообщения, чье содержимое заголовка, соответствует специфицированной дате [RFC-822] |
| SENTSINCE <дата> | Сообщения, чье содержимое заголовка, соответствует [RFC-822]: специфицированному значению даты или позже. |
| SINCE <дата> | Сообщения, чья внутренняя дата соответствует или позже специфицированного значения. |
| SMALLER | Сообщения с размером [RFC-822] меньше чем специфицированное число октетов. |
| SUBJECT <строка> | Сообщения, которое содержит специфицированную строку в поле SUBJECT заголовка. |
| TEXT <строка> | Сообщения, которые содержат специфицированную строку в заголовке или теле сообщения |
| TO <строка> | Сообщения, которые содержат специфицированную строку в поле заголовка TO. |
| UID <набор сообщений> | Сообщения с уникальными идентификаторами, соответствующими заданному значению идентификатора. |
| UNANSWERED | Сообщения, которые не имеют флага \Answered. |
| UNDELETED | Сообщения, которые не имеют флага \Deleted. |
| UNDRAFT | Сообщения, которые не имеют флага \Draft. |
| UNFLAGGED | Сообщения, которые не имеют флага \Flagged. |
| UNKEYWORD <флаг> | Сообщения, которые не содержат заданных ключевых слов. |
| UNSEEN | Сообщения, которые не имеют флага \Seen. |
Пример: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed
5.4.5. Команда FETCH
Аргументы: набор сообщений,
имена информационных сообщений.
Отклики: немаркированные отклики: FETCH
Результат: OK - операция успешно завершена;
NO - команда не прошла: не удалось доставить эти данные;
BAD - команда неизвестна или неверен аргумент.
Команда FETCH извлекает данные, соответствующие сообщению в почтовом ящике. В качестве доставляемых данных может выступать отдельный атом или список элементов, помещенных в скобками. В настоящее время определены следующие типы данных, которые могут быть доставлены:
ALL Эквивалентно: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
BODY Нерасширяемая форма BODYSTRUCTURE.
BODY[]<>
Текст определенной части тела сообщения. Спецификация секции представляет собой нуль или более спецификаторов, разделенных точками. Спецификатором части является либо число, либо одно из имен:
HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME и TEXT. Пустая спецификация относится ко всему сообщению, включая заголовок.
Каждое сообщение имеет номер, по крайней мере, одной части.
Сообщения не-[MIME-IMB] и несоставные сообщения [MIME-IMB] без инкапсуляции имеют только часть 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[].
| BODY.PEEK[] <> | Альтернативная форма BODY[], которая не устанавливает флаг \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[], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822). |
| RFC822.HEADER | Функционально эквивалентно BODY.PEEK[HEADER], отличается по синтаксису результирующих немаркированных данных FETCH (возвращает данные в формате RFC822.HEADER). |
| RFC822.SIZE | Размер сообщения [RFC-822]. |
| RFC822.TEXT | Функционально эквивалентно BODY[TEXT], отличается по синтаксису результирующих немаркированных данных FETCH (возвращается RFC822.TEXT). |
| UID | Уникальный идентификатор сообщения. |
Пример: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A654 OK FETCH completed
5.4.6. Команда 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
5.4.7. Команда COPY
Аргументы: набор сообщений,
имя почтового ящика.
Отклики: команда не требует какого-либо специального отклика.
| Результат: | OK | команда успешно завершена; |
| NO | команда не прошла: не могут быть скопированы эти сообщения вообще или в данный почтовый ящик; | |
| BAD | команда неизвестна или неверен аргумент. |
Команда COPY копирует специфицированное сообщение в конец указанного почтового ящика. Флаги и внутренняя дата сообщения должны быть сохранены в копии.
Если указанный почтовый ящик отсутствует, сервер должен прислать сообщение об ошибке. Он не должен автоматически создавать почтовый ящик. Если заведомо не известно, что ящик не может быть создан, сервер должен послать код отклика "[TRYCREATE]" в качестве префикса текста маркированного отклика NO. Это предлагает клиенту возможность исполнить команду CREATE, после чего в случае успешного завершения повторно исполнить COPY.
Если команда COPY не прошла по какой-то причине, сервер должен восстановить почтовый ящик назначения в состояние, которое он имел до выполнения COPY.
Пример: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed
5.4.8. Команда 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
5.5. Команды клиента - экспериментальные и расширения 5.5.1. Команда X
Аргументы: определяется приложением.
Отклики: определяется приложением.
Результат: OK - команда выполнена;
NO - отказ;
BAD - команда неизвестна или неверен аргумент.
Любая команда с префиксом X является экспериментальной командой. Команды, которые не являются частью этой спецификации стандарта, модификации стандарта или одобренного IESG экспериментального протокола, должны использовать префикс X.
Любой добавленный немаркированный отклик, посланный экспериментальной командой также должен иметь префикс X. Реализации сервера не должны посылать такие немаркированные отклики, если только клиент не запрашивает их посредством какой-либо экспериментальной команды.
Пример: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN completed-cay
6. Отклики сервера
Существует три вида откликов сервера: отклики состояния, информация сервера и запрос продолжения команды. Информация, содержащаяся в отклике сервера, идентифицируется словом "Содержимое:".
Клиент должен быть готов воспринять любой отклик в любое время. Отклики состояния могут быть маркированными или нет. Маркированные отклики состояния указывают на результат завершения команды клиента (OK, NO или BAD) и имеют метку, соответствующую команде.
Некоторые отклики состояния и любая информация сервера не маркируются. Немаркированный отклик выделяется символом "*" вместо метки. Немаркированные отклики состояния отмечают реакцию сервера, они не указывают на завершение выполнения команды (например, предупреждение о предстоящем отключении системы). По историческим причинам немаркированные информационные отклики сервера называются также "незапрашиваемыми данными".
Определенные данные от сервера должны записываться клиентом при получении. Такие данные несут критическую информацию, которая влияет на интерпретацию всех последующих команд и откликов (например, создание или уничтожение сообщений).
Прочие данные сервера следует записывать для последующих ссылок, если клиент не нуждается в записи данных или если запись данных не имеет очевидного смысла (например, отклик SEARCH, когда никакой команды SEARCH не исполняется), такая информация должна игнорироваться.
Немаркированная информация посылается сервером, когда соединение IMAP находится в состоянии "выбрано". В этом состоянии при выполнении команды сервер проверяет наличие новых сообщений в выбранном почтовом ящике. В норме, это часть процедуры выполняется любой командой, следовательно, даже команды NOOP достаточно для проверки наличия новых сообщений. Если обнаружены новые сообщения, сервер посылает немаркированные отклики EXISTS и RECENT, отражающие новые размеры почтового ящика. Реализации сервера, которые предлагают множественный одновременный доступ к одному и тому же ящику, также должны посылать соответствующие немаркированные отклики FETCH и EXPUNGE, если другие агенты изменяют состояние любого флага сообщения или удаляют любое сообщение.
Отклики запросов продолжения команды используют символ "+" вместо метки. Эти отклики посылаются сервером для индикации приема незавершенной команды клиента и готовности приема остальной части команды.
6.1. Отклики сервера - отклики состояния
Статусными откликами являются OK, NO, BAD, PREAUTH и BYE. OK, NO и BAD могут быть маркированными или нет. PREAUTH и BYE - всегда не маркированы.
Статусные отклики могут включать опционный код отклика. Код отклика состоит из информации, заключенной в квадратные скобки, в форме атома. Далее может следовать пробел и аргументы. Код отклика содержит дополнительную информацию или статусные коды для программы клиента помимо условий OK/NO/BAD. Эти данные определяются, когда клиент может предпринять действия на основе этой дополнительной информации. В настоящее время определены следующие коды откликов:
| ALERT | Текстовое сообщение, содержащее специальное предупреждение, которое должно быть представлено пользователю в форме, привлекающей внимание. |
| NEWNAME | За этим откликом следует имя почтового ящика и новое имя. Команды SELECT или EXAMINE не пройдут, так как ящик места назначения более не существует из-за переименования. Это является указанием для клиента, попытаться повторить команду с новым именем почтового ящика. |
| PARSE | Текстовое сообщение, которое указывает на ошибку при разборе заголовка [RFC-822] или заголовка [MIME-IMB] сообщения в почтовом ящике. |
| PERMANENTFLAGS | Когда за этим кодом следует в скобках список флагов, это указывает, какие из известных флагов могут быть изменены на постоянной основе. Любые флаги, которые указаны в немаркированном отклике FLAGS, но отсутствуют в списке PERMANENTFLAGS, могут быть установлены на постоянной основе. Если клиент пытается запомнить (STORE) флаг, который отсутствует в списке PERMANENTFLAGS, сервер либо отвергнет этот запрос с помощью отклика NO или запомнит состояние только до конца текущей сессии. Список PERMANENTFLAGS может также включать специальный флаг \*, который указывает, что имеется возможность создать новые ключевые слова путем записи этих флагов в почтовом ящике. |
| READ-ONLY | Почтовый ящик выбран в режиме только для чтения или доступ к нему был сменен с read-write на read-only. |
| READ-WRITE | Почтовый ящик находится в режиме read-write, или доступ к нему был сменен с read-only на read-write. |
| TRYCREATE | Попытка выполнения APPEND или COPY оказалась неуспешной из-за того, что почтовый ящик места назначения отсутствует. Это указывает клиенту, что операция может оказаться успешной, если почтовый ящик будет сначала создан с помощью CREATE |
| UIDVALIDITY | Когда за этим кодом следует десятичное число, это указывает на значение уникального идентификатора. |
| UNSEEN | Когда за этим кодом следует десятичное число, это указывает на значение номера первого сообщения без флага \Seen. |
Дополнительные коды откликов определенные конкретным клиентом или сервером должны иметь префикс "X", если они отклоняются от рекомендаций данного документа. Реализации клиента должны игнорировать отклики, которые ими не распознаются.
6.1.1. Отклик OK
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик OK индицирует информационное сообщение от сервера. Если оно маркировано, сообщение указывает на успешное завершение соответствующей команды. Пользователю может быть предложено текстовое информационное сообщение. Немаркированная форма указывает на чисто информационное сообщение; природа информации может быть указана в коде отклика.
Немаркированная форма используется также как один из трех видов оповещения об установлении начального соединения. Эта форма указывает, что еще не выполнена аутентификация и необходима команда LOGIN.
Пример: S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed
6.1.2. Отклик NO
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик NO указывает на сообщение от сервера об операционной ошибке. В помеченной форме он отмечает неудачное завершение соответствующей команды. Непомеченная форма служит для индикации предупреждения, команда все еще может завершиться успешно. Текстовое сообщение описывает условия.
Пример: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full
6.1.3. Отклик BAD
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BAD отмечает сообщение об ошибке со стороны сервера. В маркированной форме он сообщает об ошибке протокольного уровня в команде клиента; метка отмечает команду, которая вызвала ошибку. Непомеченная форма указывает на ошибку протокольного уровня, для которой нельзя указать команду, вызвавшую ошибку; это может также означать внутреннюю ошибку сервера. Текстовое сообщение описывает условия.
Пример: C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed
6.1.4. Отклик PREAUTH
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик PREAUTH является всегда непомеченным и представляет собой одну из трех возможных реакций при установлении соединения. Он указывает, что для соединения уже выполнена аутентификация, и команда LOGIN не нужна.
Пример: S: * PREAUTH IMAP4rev1 server logged in as Smith
6.1.5. Отклик BYE
Содержимое: опционный код отклика;
текст, читаемый человеком
Отклик BYE является всегда непомеченным, он указывает, что сервер намеривается разорвать соединение. При этом пользователю может быть послано текстовое сообщение, проясняющее статус клиента. Отклик BYE посылается при выполнении одного из четырех условий:
- Как часть нормальной процедуры logout. Сервер закроет соединение после отправки маркированного отклика OK на команду LOGOUT.
- Как уведомление об аварийном прерывании сессии. Сервер немедленно разрывает соединение.
- Как уведомление о процедуре автоматического logout по причине отсутствия активности. Сервер немедленно разрывает соединение.
- Как одно из трех возможных сообщений при установлении соединения, уведомляя, что сервер не может установить соединение с данным клиентом. Сервер немедленно разрывает соединение.
Отличие между откликом BYE, который является частью обычной процедуры LOGOUT (первый вариант), и BYE при отказе (остальные три варианта), заключается в том, что соединение в последнем случае разрывается немедленно.
Пример: S: * BYE Autologout; idle for too long
6.2. Отклики сервера - сообщения о состоянии сервера и почтового ящика
Эти отклики всегда не маркированы. Они служат для передачи статусной информации сервера и почтового ящика клиенту. Большинство этих откликов являются результатом команд, носящих то же имя.
6.2.1. Отклик CAPABILITY
Содержимое: список возможностей.
Отклик CAPABILITY возникает в результате исполнения одноименной команды. Список возможностей, содержащийся в перечне наименований, разделенных пробелами, характеризует функции, поддерживаемые сервером. Список возможностей должен включать в себя атом "IMAP 4.1".
Имя возможности, которое начинается с "AUTH=" указывает, что сервер поддерживает данный механизм аутентификации. Другие наименования возможностей отмечают, что сервер поддерживает расширение, модификацию или усовершенствования протокола IMAP 4.1. Отклик сервера должен соответствовать данному документу до тех пор, пока клиент использует команды, согласованные со списком возможностей.
Имена возможностей должны либо начинаться с "X", либо быть стандартными, либо соответствовать расширениям IMAP 4.1, модификациям или усовершенствованиям, зарегистрированным IANA. Сервер не должен предлагать незарегистрированные или нестандартные имена возможностей, если их имена не начинаются с символа "X".
Реализациям клиента не следует требовать каких-либо имен возможностей, отличных от "IMAP 4.1", они должны игнорировать неизвестные имена возможностей.
Пример: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
6.2.2. Отклик LIST
Содержимое: атрибуты имени, иерархический разделитель, имя.
Отклик LIST посылается как результат команды LIST. Он возвращает одно имя, которое соответствует спецификации LIST. Допускается несколько откликов LIST на одну команду.
Определено четыре атрибута имени:
| \Noinferiors | Дочерние уровни иерархии не могут иметь то же самое имя. Не существует дочерних уровней в настоящее время, и они не могут быть созданы в будущем. |
| \Noselect | Не допускается использование данного имени для именования почтового ящика, который может быть выбран. |
| \Marked | Почтовый ящик помечен сервером как "interesting"; почтовый ящик, вероятно, содержит сообщения, которые добавлены со времени, когда почтовый ящик последний раз был выбран. |
| \Unmarked | Почтовый ящик не содержит каких-либо дополнительных сообщений, со времени, когда почтовый ящик последний раз был выбран. |
Если сервер не может определить, является ли почтовый ящик "интересным", или, если имя имеет атрибут \Noselect, сервер не должен посылать отклики \Marked или \Unmarked. Иерархическим разделителем является символ, используемый для разграничения уровней иерархии имен почтового ящика. Клиент может использовать разделитель для формирования дочерних уровней в почтовом ящике, а также для поиска в иерархической системе имен. Все дочерние уровни верхнего уровня иерархии должны использовать один и тот же тип разделителя. Иерархический разделитель NIL означает, что никакой иерархии нет.
Имя представляет собой однозначную иерархию (слева направо) и должно быть пригодным для использования в качестве шаблона командами LIST и LSUB. Если не использован атрибут \Noselect, имя должно быть пригодно в качестве аргумента команд, типа SELECT, которые требуют ввода имени почтового ящика.
Пример: S: * LIST (\Noselect) "/" ~/Mail/foo
6.2.3. Отклик LSUB
Содержимое: атрибуты имени, иерархический разграничитель, имя.
Отклик LSUB является результатом команды LSUB. Он возвращает одно имя, которое соответствует спецификации LSUB. Допускается несколько откликов на одну команду LSUB. Формат данных идентичен используемому в отклике LIST.
Пример: S: * LSUB () "." #news.comp.mail.misc
6.2.4. Отклик STATUS
Содержимое: имя, статусный список, заключенный в скобки.
Отклик STATUS является результатом команды STATUS. Он возвращает имя почтового ящика, которое соответствует спецификации STATUS, и запрашиваемую статусную информацию почтового ящика.
Пример: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
6.2.5. Отклик SEARCH
Содержимое: нуль или более чисел.
Отклик SEARCH является результатом команды SEARCH или UID SEARCH. Числа относятся к тем сообщениям, которые отвечают критериям отбора. Для SEARCH это порядковые номера сообщений, а для UID SEARCH - их уникальные идентификаторы. Числа отделяются друг от друга пробелами.
Пример: S: * SEARCH 2 3 6
6.2.6. Отклик FLAGS
Содержимое: список флагов, заключенный в скобки.
Отклик FLAGS является результатом команды SELECT или EXAMINE. Список флагов, заключенный в скобки определяет флаги (системные флаги), которые могут использоваться для данного почтового ящика. Допускаются флаги, отличные от системных, это зависит от реализации сервера. Отклик FLAGS должен записываться клиентом.
Пример: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
6.3. Отклики сервера - размер почтового ящика
Эти отклики являются немаркированными. Они передают от сервера клиенту информацию об изменении размера почтового ящика. Число, которое следует за символом "*" определяет количество сообщений.
6.3.1. Отклик EXISTS
Содержимое: отсутствует.
Отклик EXISTS сообщает о числе сообщений в почтовом ящике. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение). Отклик EXISTS должен регистрироваться клиентом.
Пример: S: * 23 EXISTS
6.3.2. Отклик RECENT
Содержимое: отсутствует.
Отклик RECENT сообщает число сообщений с флагами \Recent. Этот отклик является результатом команды SELECT, EXAMINE или изменения размера почтового ящика (например, получено новое почтовое сообщение).
Замечание: Нельзя гарантировать, чтобы порядковые номера для последних сообщений образовывали в почтовом ящике непрерывный ряд с предыдущими. Примерами, когда складывается такая ситуация могут служить варианты: несколько клиентов, имеют один и тот же открытый почтовый ящик; или случай, когда сообщения в почтовом ящике переставлены не-IMAP приложением.
Единственным способом идентифицировать последние сообщения является рассмотрение флагов \Recent, или выполнение команды SEARCH RECENT. Информация отклика RECENT должна регистрироваться клиентом.
Пример: S: * 5 RECENT
6.4. Отклики сервера - статусное сообщение
Эти отклики являются немаркированными. Они несут информацию о том, как сообщения доставляются от сервера к клиентам, и возникают как результат работы одноименных команд. Сразу за символом "*" следует число, которое является порядковым номером сообщения.
6.4.1. Отклик EXPUNGE
Содержимое: отсутствует.
Отклик EXPUNGE уведомляет, сообщение с каким порядковым номером удалено из почтового ящика. Порядковые номера последующих сообщений немедленно уменьшаются на единицу.
Как результат этого немедленного уменьшения порядковых номеров следует рассматривать то, что порядковые номера сообщений, появляющиеся при последующих командах EXPUNGE, зависят от того, в каком порядке удаляются сообщения. Например, если последние 5 сообщений в почтовом ящике с 9 сообщениями стерты, сервер, удаляющий записи "снизу-вверх" пошлет 5 немаркированных откликов EXPUNGE (с номером 5), в то время как сервер, стирающий записи "сверху вниз", пошлет немаркированные отклики с номерами 9, 8, 7, 6 и 5.
Отклик EXPUNGE не должен посылаться, когда не исполняется никакая команда, или при отклике на команды FETCH, STORE или SEARCH. Это правило необходимо, чтобы предотвратить потерю синхронизации нумерации для клиента и сервера.
Информация отклика EXPUNGE должна регистрироваться клиентом.
Пример: S: * 44 EXPUNGE
6.4.2. Отклик FETCH
Содержимое: текст сообщения.
Отклик FETCH возвращает данные о сообщении клиенту. Данные сформированы в группы из имени элемента и его значения в скобках. Этот отклик является следствием команды FETCH или STORE, а также одностороннего решения сервера (например, об изменении флагов). В настоящее время существуют следующие информационные элементы:
BODY Форма BODYSTRUCTURE без расширения данных.
BODY[]<>
Строка, отражающая содержимое специфицированной секции. Строка должна интерпретироваться клиентом согласно транспортной кодировке, типу и субтипу тела.
Если специфицирован начальный октет, то это субстрока полного содержимого тела, начинающаяся с заданного октета. Это означает, что 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, и т.д.).
Например, сообщение из двух частей, включающее в себя текст и приложение, закодированное в BASE64, может иметь структуру тела: (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") "<960723163407.20117h@cac.washington.edu>" "Compiler diff" "BASE64" 4554 73) "MIXED"))
Данные расширения следуют за составным субтипом. Данные расширения никогда не присылаются при доставке тела, но могут быть доставлены с помощью BODYSTRUCTURE. Данные расширения, если они присутствуют, должны иметь следующий формат:
Список параметров тела, заключенный в скобки.
Список содержит пары атрибут/значение [например, ("foo" "bar" "baz" "rag"), где "bar" представляет собой значение "foo", а "rag" является значением "baz"] как это определено в [MIME-IMB].
Размещение тела
Список, заключенный в скобки, состоящий из строки типа размещения, за которой следует список пар атрибут/значение. Имена типов размещения и атрибутов будут определены в будущих стандартах.
Язык тела
Строка или список в скобках, определяющие язык, так как это задано в [LANGUAGE-TAGS].
Любое из последующих расширений данных в данной версии протокола не определено. Такие расширения могут состоять из нуля или более NIL-строк, чисел, или вложенных списков таких данных, заключенных в скобки. Реализации клиента, которые осуществляют доставку BODYSTRUCTURE, должны быть готовы принять такие расширения данных. Реализации сервера не должны посылать такие расширения, до тех пор, пока они не войдут в новую версию протокола. Базовые поля несоставной части тела размещаются в следующем порядке:
Тип тела
Строка, описывающая имя типа содержимого, как это определено в [MIME-IMB].
Субтип тела
Строка, описывающая имя субтипа, как это определено в [MIME-IMB].
Список параметров тела, заключенный в скобки
Список пар атрибут/значение, заключенный в скобки, [например, ("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.
| FLAGS | Список флагов, установленных для данного сообщения, заключенный в скобки. |
| INTERNALDATE | Строка, представляющая внутреннюю дату сообщения. |
| RFC822 | Эквивалент BODY[]. |
| RFC822.HEADER | Эквивалент BODY.PEEK[HEADER]. |
| RFC822.SIZE | Число, выражающее размер сообщения [RFC-822]. |
| RFC822.TEXT | Эквивалент BODY[TEXT]. |
| UID | Число, выражающее уникальный идентификатор сообщения. |
Пример: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
6.5 Отклики сервера - запрос продолжения команды
Отклик на запрос продолжения команды вместо метки выделяется символом "+". Эта форма отклика указывает на то, что сервер готов принять продолжение команды от клиента. Остальная часть этого отклика имеет текстовую форму.
Этот отклик используется командой AUTHORIZATION, для того чтобы передать данные от сервера клиенту, и запросить дополнительные данные у клиента. Этот отклик применяется также, если аргументом какой-то команды является литерал.
Клиенту не позволено посылать литеральные октеты, если только сервер в явной форме не запросил их. Это позволяет серверу обрабатывать команды и отвергать ошибки строчка за строчкой. Остальная часть команды, включая CRLF, завершающие команду, следует за октетами литерала. Если имеются какие-либо дополнительные аргументы команды, за литеральными октетами следует пробел, после чего передаются аргументы.
Пример: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"