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

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

Аннотация

Этот документ добавляет новую возможность под названием «SAVEDATE» в протокол доступа к сообщениям в Интернете (IMAP). Он определяет новый атрибут сообщения IMAP под названием «дата сохранения», который, в отличие от существующего атрибута «внутренняя дата», всегда указывает момент, когда сообщение было сохранено в его текущем почтовом ящике. Возможность SAVEDATE расширяет команду FETCH средствами для извлечения атрибута даты сохранения и расширяет команду SEARCH, чтобы разрешить использование атрибута даты сохранения в критериях поиска.

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

 

Оглавление

1. Введение
2. Условные обозначения, используемые в этом документе
3. Сохранить дату сообщения атрибут
4. Изменения протокола IMAP
4.1. Идентификация CAPABILITY
4.2. FETCH Расширения команд и ответов
4.3. SEARCH Расширение команды
5. Формальный синтаксис
6. Вопросы безопасности
7. Соображения IANA
8. Нормативные ссылки
Благодарности
Адрес автора

 

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

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

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8514.

 

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

Copyright (c) 2019 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На этот документ распространяется действие BCP 78 и Правовая группа IETF Trust.

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

 

1. Введение

Этот документ расширяет протокол доступа к сообщениям в Интернете (IMAP) [IMAP4rev1] с новой возможностью, называемой «SAVEDATE». Эта возможность добавляет новый атрибут сообщения IMAP, который называется «дата сохранения». Дата сохранения — это дата и время, когда сообщение было сохранено в почтовом ящике, в котором оно находится в данный момент. Дата сохранения аналогична существующему атрибуту «внутренняя дата» в том смысле, что она установлена во время доставки.

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

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

Например, обычным способом использования клиента является перемещение удаленных сообщений в почтовый ящик корзины. Эти сообщения считаются «удаленными» во время их перемещения в почтовый ящик корзины. Стремясь ограничить размер почтового ящика корзины, клиент может впоследствии захотеть навсегда удалить (удалить) все сообщения в этом почтовом ящике корзины, удаленные до определенного времени (например, настраиваемый интервал истечения срока действия). В этом случае внутренний атрибут даты нельзя использовать, поскольку он, вероятно, относится ко времени, когда сообщение было первоначально получено. Вместо этого правильным атрибутом сравнения времени должно быть время, когда сообщение было сохранено в почтовый ящик корзины. Подобные модели использования могут наблюдаться для решений архивирования.

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

 

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

В примерах «C:» указывает строки, отправленные клиентом, который подключен к серверу. «S:» указывает строки, отправленные сервером клиенту.

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

 

3. Сохранить дату сообщения атрибут

Атрибут сообщения о дате сохранения — это дата и время, когда сообщение было сохранено в почтовом ящике, в котором оно сейчас находится. В отличие от внутреннего атрибута сообщения о дате, определенного в [IMAP4rev1], это значение даты и времени не может быть установлено произвольно, когда сообщение доставляется командой IMAP APPEND. Кроме того, когда сообщение доставляется в почтовый ящик командой IMAP COPY [IMAP4rev1] или командой IMAP MOVE [IMAP-MOVE], атрибут даты сохранения не копируется из исходного сообщения. Вместо этого для установки атрибута даты сохранения ДОЛЖНЫ использоваться текущие дата и время, когда сообщение доставляется в почтовый ящик. После расчета атрибут даты сохранения НЕ ДОЛЖЕН изменяться, если сообщение содержится в одном и том же почтовом ящике.

Это означает, что когда сообщение копируется в другой почтовый ящик, дата сохранения сообщения в исходном почтовом ящике остается неизменной; только новая копия сообщения получает новую дату сохранения. Следовательно, когда сообщение перемещается в другой почтовый ящик с использованием команды MOVE или последовательности команд, включающей команду COPY [IMAP-MOVE], сообщение всегда получает новую дату сохранения в целевом почтовом ящике.

Для некоторых конкретных почтовых ящиков базовое хранилище может не поддерживать атрибут даты сохранения. Обработка этой ситуации подробно описана в следующем разделе для каждой задействованной команды IMAP.

 

4. Изменения протокола IMAP

4.1. Возможность идентификации

Серверы IMAP, которые поддерживают это расширение, ДОЛЖНЫ включать «SAVEDATE» в список ответов на команду CAPABILITY.

4.2. FETCH Расширения команд и ответов

Это расширение определяет один новый элемент данных для команды FETCH:

SAVEDATE (Дата сохранения сообщения.)

Это расширение определяет один новый элемент данных для ответа FETCH:

SAVEDATE (Строка, представляющая дату сохранения сообщения. Однако если базовое хранилище почтовых ящиков не поддерживает атрибут сообщения о дате сохранения, значение, возвращаемое для элемента SAVEDATE, всегда равно NIL, а не строке.)

Пример:

C: A101 FETCH 998 (SAVEDATE)
S: * 998 FETCH (SAVEDATE «01-Jan-2015 18:50:53 +0100»)
S: A101 OK Fetch completed.

 

4.3. SEARCH Расширение команды

Это расширение определяет четыре новых ключа поиска для команды SEARCH:

  • SAVEDBEFORE <дата> Сообщения, дата сохранения которых (без учета времени и часового пояса) раньше указанной даты.
  • SAVEDON <дата> Сообщения, дата сохранения которых (без учета времени и часового пояса) находится в пределах указанной даты.
  • SAVEDSINCE <дата> Сообщения, дата сохранения которых (без учета времени и часового пояса) находится в пределах или позже указанной даты.
  • SAVEDATESUPPORTED Соответствует всем сообщениям в почтовом ящике, когда базовое хранилище этого почтового ящика поддерживает атрибут даты сохранения. И наоборот, он не совпадает ни с одним сообщением в почтовом ящике, если атрибут даты сохранения не поддерживается.

Если базовое хранилище почтового ящика не поддерживает атрибут даты сохранения, ключи поиска SAVEDBEFORE, SAVEDON и SAVEDSINCE ДОЛЖНЫ использовать вместо этого внутренний атрибут даты. В контексте расширения IMAP Multimailbox SEARCH [MULTISEARCH] это резервное поведение ДОЛЖНО применяться к каждому почтовому ящику индивидуально, то есть только почтовые ящики, в которых отсутствует поддержка атрибута даты сохранения, вместо этого используют атрибут внутренней даты.

Пример:

C: A102 SEARCH SAVEDON 28-Dec-2014
S: * SEARCH 993 994
S: A102 OK Search completed.
C: A103 SEARCH SAVEDSINCE 28-Dec-2014
S: * SEARCH 993 994 995 996 997 998 999 1000 1001
S: A103 OK Search completed.

 

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

Следующая спецификация синтаксиса дополняет грамматику, указанную в [IMAP4rev1]. Он использует расширенную нотацию Бэкуса-Наура (ABNF), как указано в [ABNF]. Элементы, не определенные здесь, взяты из [IMAP4rev1].

capability =/ "SAVEDATE"
fetch-att =/ "SAVEDATE"
msg-att-static =/ "SAVEDATE" SP (date-time / nil)
search-key =/ "SAVEDBEFORE" SP date /
"SAVEDON" SP date /
"SAVEDSINCE" SP date /
"SAVEDATESUPPORTED"

 

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

Нет никаких известных дополнительных проблем безопасности с этим расширением кроме тех, которые описаны в базовом протоколе, описанном в [IMAP4rev1].

 

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

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

 

8. Нормативные документы

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

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

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

[KEYWORDS] 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/rfc/rfc2119>.

[KEYWORDS-UPD] 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>.

[MULTISEARCH] Leiba, B. and A. Melnikov, «IMAP4 Multimailbox SEARCH Extension», RFC 7377, DOI 10.17487/RFC7377, October 2014, <https://www.rfc-editor.org/info/rfc7377>.

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

Спасибо Брон Гондване, Алексею Мельникову, Тимо Сирайнену и Майклу Слюсарзу за отзывы и предложения.

Адрес автора

Stephan Bosch
Open Xchange Oy
Lars Sonckin kaari 12
Espoo 02600
Finland

Email: stephan.bosch@open-xchange.com