RFC 8508 | Протокол доступа к интернет-сообщениям (IMAP)

Аннотация

Этот документ определяет расширение IMAP, которое можно использовать для замены существующего сообщения в хранилище сообщений новым сообщением. Замена сообщений — это обычная операция для клиентов, которые автоматически сохраняют черновики или заметки по мере их составления пользователем.

Скачать оригинальный документ на английском языке RFC 8508 PDF

1. Обзор
2. Условные обозначения, используемые в этом документе
3. REPLACE и UID REPLACE
3.1. Рекламная поддержка для REPLACE
3.2. Команда REPLACE
3.3. Команда UID REPLACE
3.4. Семантика REPLACE и UID REPLACE
3.5. Воздействие диаграммы состояния IMAP
4. Взаимодействие с другими расширениями
4.1. ACL
4.2. CATENATE
4.3. UIDPLUS
4.4. IMAP события в сите
4.5. CONDSTORE / QRESYNC
4.6. OBJECTID
4.7. MULTIAPPEND
5. Формальный синтаксис
6. Вопросы безопасности
7. Соображения IANA
8. Ссылки
8.1. Нормативные ссылки
8.2. Информационные ссылки
Благодарности
Адрес автора

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8508.

Уведомление об авторских правах

На данный документ распространяется действие BCP 78 и Правовые положения IETF Trust в отношении документов IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать в себя текст упрощенной лицензии BSD, как описано в разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.

1. Обзор

Этот документ определяет расширение IMAP ([RFC3501]), чтобы облегчить замену существующего сообщения новым. Это достигается путем определения новой команды REPLACE и расширения команды уникального идентификатора (UID), чтобы разрешить UID REPLACE.

Поскольку в базовой спецификации IMAP нет функции замены, клиентам вместо этого пришлось использовать комбинацию из трех отдельных команд, выдаваемых последовательно; ПРИЛОЖИТЬ (APPEND), ХРАНИТЬ (STORE), И ВЫЧЕРКНУТЬ (EXPUNGE). Конвейерная обработка этих трех команд не рекомендуется, поскольку сбой любой отдельной команды должен препятствовать выполнению последующих команд, чтобы не потерять исходную версию сообщения.

Из-за неатомарного характера существующей последовательности прерывания могут оставлять сообщения в промежуточных состояниях, которые могут быть просмотрены и обработаны другими клиентами. Такие прерывания могут также связывать старые версии сообщений, что вынуждает пользователя вручную очищать несколько версий одного и того же сообщения во избежание расточительного использования квот. Кроме того, существующая последовательность может завершиться с ошибкой в APPEND из-за условия превышения квоты, даже если последующее STORE / EXPUNGE освободит достаточно места для вновь исправленного сообщения. И, наконец, эффективность работы сервера может быть возможна с помощью одной операции замены логического сообщения по сравнению с существующей последовательностью APPEND / STORE / EXPUNGE.

В своей простейшей форме команда REPLACE представляет собой инкапсуляцию в одну команду APPEND, STORE + flags \ DELETED и UID EXPUNGE для сообщения, за исключением того, что она избегает любых последствий квот или промежуточных состояний, связанных с последовательностью из трех команд. Разработчикам серверов рекомендуется использовать REPLACE как элементарную операцию, чтобы упростить обработку ошибок, минимизировать эксплуатационные проблемы и уменьшить потенциальные проблемы безопасности. Для систем, где это невозможно, связь с запрашивающим клиентом не должна гарантировать путаницу состояния хранилища сообщений. Сервер НЕ ДОЛЖЕН генерировать код ответа для части последовательности STORE + flags \ DELETED. Кроме того, серверы, поддерживающие команду REPLACE, НЕ ДОЛЖНЫ выводить какое-либо наследование содержимого, флагов или аннотаций из заменяемого сообщения.

2. Условные обозначения, используемые в этом документе

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119], [RFC8174]

Формальный синтаксис определен в [RFC5234].

Примеры строк с предваряющим «C:» отправляются клиентом, а строки с предваряющим «S:» отправляются сервером.

3. REPLACE и UID REPLACE

3.1. Рекламная поддержка для REPLACE

Серверы, которые реализуют расширение REPLACE, вернут «REPLACE» в качестве одной из поддерживаемых возможностей в ответе команды CAPABILITY.

3.2. Команда REPLACE

Аргументы:

порядковый номер сообщения
имя почтового ящика
флаг OPTIONAL в скобках
OPTIONAL строка даты / времени
буквенное сообщение

Ответы:

нет конкретных ответов для этой команды

Результат:

ОК — замена завершена
НЕТ — заменить ошибку; не может удалить указанное сообщение или не может добавить новое содержимое сообщения
BAD — команда неизвестна или аргументы неверны

Пример:

C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822388-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C:
S: * OK [APPENDUID 1 2000] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A003 OK Replace completed

3.3. Команда UID REPLACE

Это расширяет первую форму команды UID (см. Раздел 6.4.8 [RFC3501]), чтобы добавить команду REPLACE, определенную выше, в качестве допустимого аргумента. Эта форма REPLACE использует UID, а не порядковый номер в качестве первого параметра.

Пример:

C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Subject: happy new year !!
C: To: miss.mitzy@example.org
C: Message-Id: <B238822389-0100000@example.org>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Just saw the best fireworks show. Wish you were here.
C: Hopefully next year you can join us.
C:
S: * OK [APPENDUID 1 2001] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A004 OK Replace completed

3.4. Семантика REPLACE и UID REPLACE

Команды REPLACE и UID REPLACE принимают пять аргументов: идентификатор сообщения, именованный почтовый ящик, необязательный список флагов в скобках, необязательную строку даты / времени сообщения и литерал сообщения. Литерал сообщения будет добавлен к указанному почтовому ящику, а сообщение, указанное идентификатором сообщения, будет удалено из выбранного почтового ящика. Эти операции будут показаны клиенту как одно действие. Это имеет тот же эффект, что и следующая последовательность:

APPEND
[UID] STORE +FLAGS.SILENT \DELETED
UID EXPUNGE

В приведенной последовательности значения APPEND для квот оцениваются в контексте ожидающего EXPUNGE, так что учитывается только потребление чистой квоты. Кроме того, часть последовательности EXPUNGE применяется только к указанному сообщению, а не ко всем сообщениям, помеченным как «\Deleted».

Хотя эффект REPLACE идентичен вышеописанным шагам, семантика не идентична; аналогично MOVE [RFC6851], промежуточные состояния не возникают, а коды ответов отличаются. В частности, будут возвращены коды ответов для APPEND и EXPUNGE, а коды для операции STORE НЕ ДОЛЖНЫ генерироваться.

Если во время обработки REPLACE или UID REPLACE возникает ошибка, сервер НЕ ДОЛЖЕН оставлять выбранный почтовый ящик в несогласованном состоянии; любой неотмеченный ответ EXPUNGE НЕ ДОЛЖЕН быть отправлен до тех пор, пока все действия не будут успешно завершены.

Хотя для именованного аргумента почтового ящика может быть свойственно совпадение с выбранным почтовым ящиком для общего случая замены черновика, расширение REPLACE преднамеренно не требует, чтобы оба были одинаковыми. Например, можно использовать команду REPLACE, чтобы заменить сообщение в почтовом ящике специального назначения \ Drafts (см. Раздел 2 в [RFC6154]) сообщением в почтовом ящике специального назначения \ Sent после отправки сообщения.

Из-за сходства REPLACE и APPEND, расширения, которые влияют на APPEND, влияют на REPLACE таким же образом. Коды ответа, такие как TRYCREATE (см. Раздел 6.3.11 [RFC3501]), наряду с кодами, определенными расширениями, отправляются по мере необходимости. См. Раздел 4 для получения дополнительной информации о том, как REPLACE взаимодействует с другими расширениями IMAP.

3.5. Воздействие диаграммы состояния IMAP

В отличие от команды APPEND, которая действует в аутентифицированном состоянии, команды REPLACE и UID REPLACE ДОЛЖНЫ быть действительными только в выбранном состоянии. Это отличие от APPEND необходимо, поскольку REPLACE работает с порядковыми номерами сообщений. Кроме того, расширение REPLACE намеренно следует соглашению для команд UID, приведенному в разделе 6.4.8 [RFC3501], в том смысле, что вариант команды UID не поддерживает использование из аутентифицированного состояния.

4. Взаимодействие с другими расширениями

В этом разделе описывается, как REPLACE взаимодействует с некоторыми другими расширениями IMAP.

4.1. ACL

Права списка управления доступом (ACL) [RFC4314], необходимые для замены UID, представляют собой объединение прав ACL, требуемых для хранилища UID и UID EXPUNGE в текущем почтовом ящике, и APPEND в целевом почтовом ящике.

4.2. CATENATE

Серверы, поддерживающие REPLACE и CATENATE [RFC4469], ДОЛЖНЫ поддерживать дополнительные элементы append-data и resp-text-code, определенные в Разделе 5 («Формальный синтаксис») [RFC4469] в сочетании с командой REPLACE. В сочетании с CATENATE REPLACE может стать весьма эффективным способом манипулирования сообщениями.

Примеры:

Пользователь составляет сообщение и прикрепляет фотографию

C: A010 APPEND Drafts (\Seen \Draft) {1201534}
S: + Ready for literal data
C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
C: From: Fritz Schmidt <fritz.ze@example.org>
C: Message-ID: <B238822388-0100003@example.org>
C: MIME-Version: 1.0
C: Content-Type: multipart/mixed;
C: boundary=»————030305060306060609050804″
C:
C: —————030305060306060609050804
C: Content-Type: text/plain; charset=utf-8; format=flowed
C: Content-Transfer-Encoding: 7bit
C:
C: Here is picture from the fireworks
C:
C: Yours…
C: Fritz
C:
C: —————030305060306060609050804
C: Content-Type: image/jpeg;
C: name=»Fireworks.jpg»
C: Content-Transfer-Encoding: base64
C: Content-Disposition: attachment;
C: filename=»Fireworks.jpg»
C:
<large base64 encoded part goes here>
C:
C: —————030305060306060609050804—
S: A010 OK [APPENDUID 1 3002] APPEND complete

Пользователь заполняет сообщение полями To: и Subject:

C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
S: + Ready for literal data
C: To: Mitzy <miss.mitzy@example.org>
C: Subject: My view of the fireworks
C: URL «/Drafts/;UID=3002»)
S: * OK [APPENDUID 1 3003] Replacement Message ready
S: * 5 EXISTS
S: * 4 EXPUNGE
S: A011 OK REPLACE completed

4.3. UIDPLUS

Серверы, поддерживающие и REPLACE, и UIDPLUS [RFC4315], ДОЛЖНЫ отправить APPENDUID в ответ на команду UID REPLACE. Для получения дополнительной информации см. Раздел 3 [RFC4315]. Серверам, реализующим REPLACE и UIDPLUS, также рекомендуется отправлять код ответа APPENDUID без метки OK перед отправкой EXPUNGE или замененных ответов. (Отправка APPENDUID в помеченном OK, как описано в спецификации UIDPLUS, означает, что клиент сначала получает EXPUNGE для сообщения, а затем APPENDUID для нового сообщения. Может быть излишне сложно обработать эту последовательность с пользой.)

4.4. IMAP события в сите

REPLACE применяется к событиям IMAP в Sieve [RFC6785] так же, как APPEND. Таким образом, REPLACE может вызвать запуск сценария Sieve, если для imap.cause задано значение «APPEND». Поскольку промежуточное состояние STORE + FLAGS.SILENT \ DELETED не отображается в REPLACE, не будет предпринято никаких действий, приводящих к imap.cause FLAG.

4.5. CONDSTORE / QRESYNC

Серверы, реализующие как REPLACE, так и CONDSTORE / QRESYNC [RFC7162], ДОЛЖНЫ трактовать заменяемое сообщение так, как если бы оно было удалено командой UID EXPUNGE. Разделы 3.2.9 и 3.2.10 [RFC7162] особенно актуальны для этого условия.

4.6. OBJECTID

Серверы, реализующие как REPLACE, так и OBJECTID [RFC8474], ДОЛЖНЫ возвращать разные EMAILID как для замененных, так и для замещающих сообщений. Единственным исключением из этого является случай, описанный в Разделе 5.1 («Идентификатор EMAILID для идентичных сообщений») [RFC8474], когда сервер обнаруживает, что неизменяемое содержимое обоих сообщений является идентичным.

4.7. MULTIAPPEND

Расширение REPLACE не взаимодействует с MULTIAPPEND [RFC3502]. Этот документ явно не описывает метод одновременной замены нескольких сообщений.

5. Формальный синтаксис

В следующей спецификации синтаксиса используется нотация расширенной формы Бэкуса-Наура (ABNF), как указано в [RFC5234]. [RFC3501] определяет нетерминалы «возможность», «выбор команды», «почтовый ящик», «номер seq» и «uid». [RFC4466] определяет нетерминальное «приложение-сообщение».

Если не указано иное, все буквенные символы не чувствительны к регистру. Использование символов верхнего и нижнего регистра для определения строк токенов предназначено только для редакционной ясности. Реализации ДОЛЖНЫ принимать эти строки без учета регистра.

capability =/ «REPLACE»
command-select =/ replace
replace = «REPLACE» SP seq-number SP mailbox append-message
uid =/ «UID» SP replace

6. Вопросы безопасности

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

7. Соображения IANA

IANA добавила замену в реестр «Возможности IMAP» по адресу <https://www.iana.org/assignments/imap-capabilities>.

8. Ссылки

8.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3501] Crispin, M., «INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1», RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.

[RFC4314] Melnikov, A., «IMAP4 Access Control List (ACL) Extension», RFC 4314, DOI 10.17487/RFC4314, December 2005, <https://www.rfc-editor.org/info/rfc4314>.

[RFC4315] Crispin, M., «Internet Message Access Protocol (IMAP) — UIDPLUS extension», RFC 4315, DOI 10.17487/RFC4315, December 2005, <https://www.rfc-editor.org/info/rfc4315>.

[RFC4466] Melnikov, A. and C. Daboo, «Collected Extensions to IMAP4 ABNF», RFC 4466, DOI 10.17487/RFC4466, April 2006, <https://www.rfc-editor.org/info/rfc4466>.

[RFC4469] Resnick, P., «Internet Message Access Protocol (IMAP) CATENATE Extension», RFC 4469, DOI 10.17487/RFC4469, April 2006, <https://www.rfc-editor.org/info/rfc4469>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC6785] Leiba, B., «Support for Internet Message Access Protocol (IMAP) Events in Sieve», RFC 6785, DOI 10.17487/RFC6785, November 2012, <https://www.rfc-editor.org/info/rfc6785>.

[RFC7162] Melnikov, A. and D. Cridland, «IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)», RFC 7162, DOI 10.17487/RFC7162, May 2014, <https://www.rfc-editor.org/info/rfc7162>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8474] Gondwana, B., Ed., «IMAP Extension for Object Identifiers», RFC 8474, DOI 10.17487/RFC8474, September 2018, <https://www.rfc-editor.org/info/rfc8474>.

8.2. Информационные ссылки

[RFC3502] Crispin, M., «Internet Message Access Protocol (IMAP) — MULTIAPPEND Extension», RFC 3502, DOI 10.17487/RFC3502, March 2003, <https://www.rfc-editor.org/info/rfc3502>.

[RFC6154] Leiba, B. and J. Nicolson, «IMAP LIST Extension for Special-Use Mailboxes», RFC 6154, DOI 10.17487/RFC6154, March 2011, <https://www.rfc-editor.org/info/rfc6154>.

[RFC6851] Gulbrandsen, A. and N. Freed, Ed., «Internet Message Access Protocol (IMAP) — MOVE Extension», RFC 6851, DOI 10.17487/RFC6851, January 2013, <https://www.rfc-editor.org/info/rfc6851>.

Благодарности

Автор хотел бы поблагодарить участников IMAPEXT с особой благодарностью Арнту Гулбрандсену, Алексею Мельникову, Крису Ньюману и Брон Гондване за их конкретный вклад.

Адрес автора

Stuart Brandt
Verizon
22001 Loudoun County Parkway
Ashburn, VA 20147
United States of America

Email: stujenerin@aol.com

RFC 8508 | Протокол доступа к интернет-сообщениям (IMAP) — расширение REPLACE