Кратко

  • RFC 5232 позволяет Sieve формировать и проверять набор флагов для текущего письма, а затем передавать его копии, которую доставляет keep или fileinto.
  • Это не универсальный интерфейс редактирования IMAP-хранилища: флаги, которые ящик не может сохранить постоянно, нужно игнорировать, не превращая это само по себе в ошибку выполнения скрипта.

Отметка следовала за решением о доставке

Входящее письмо разбирается, направляется и в итоге попадает в почтовый ящик. IMAP-флаг — это состояние, связанное с уже хранящимся сообщением. Опубликованный в январе 2008 года RFC 5232 связал язык фильтрации Sieve с такими отметками, но не смешал выбор действий для обрабатываемого письма с переписыванием всего ящика.

Расширение imap4flags требует четыре действия или теста: setflag, addflag, removeflag и hasflag; кроме того, оно добавляет аргумент :flags для keep и fileinto. Первые три операции изменяют набор флагов, а тест проверяет наличие имен. Аргумент доставки передаёт флаги копии текущего письма, помещаемой в целевой ящик.

Этот набор существует только в рамках одного выполнения Sieve. В начале внутренняя переменная пуста. setflag заменяет набор, addflag добавляет имена, removeflag убирает их, а hasflag проверяет текущее значение. Если движок поддерживает отдельное расширение Variables, можно использовать именованные наборы. Без него явное имя переменной приведёт к ошибке, но внутренняя переменная остаётся доступной. Имена флагов сравниваются без учёта регистра; скрипт не должен рассчитывать на сохранение порядка, написания или дубликатов.

Важный переход происходит при доставке. Если в keep или fileinto указан :flags, для сохраняемой копии используется переданный список. Без него берётся текущее значение внутренней переменной. То же значение применяется при неявном keep — варианте по умолчанию, когда явное действие доставки его не заменило. Скрипт может добавить отметку в одной ветви и передать её следующему действию либо указать другой список прямо при размещении письма.

Однако область RFC 5232 ограничена сообщением, которое обрабатывает этот запуск Sieve. Он не разрешает скрипту выбрать другое, уже лежащее в ящике сообщение и поменять его флаги. Расширение также не действует на отдельное письмо, созданное как побочный результат другой команды. Это точка интеграции с доставкой, а не общий API для изменения IMAP-хранилища.

Сам целевой ящик задаёт ещё одно ограничение. :flags описывает желаемые флаги доставленной копии, но не гарантирует, что любое хранилище сможет сохранить их постоянно. Интерпретатор должен игнорировать флаги, которые нельзя сохранить надолго, и не должен только поэтому срывать выполнение Sieve. В примере RFC команда fileinto :flags "\\Deleted" эквивалентна fileinto без этого запроса, если ящик не поддерживает такую отметку. В IMAP \\Deleted лишь помечает письмо для последующего expunge; это не доказательство физического удаления.

Фраза «правило поставило флаг» поэтому объединяет несколько отдельных фактов: сработала ли ветвь, сформировал ли интерпретатор список, запросило ли действие доставки эти флаги, что ящик сохранил постоянно и что позднее показал клиент. Одно не доказывает другое. RFC 5232 не предписывает, должен ли интерпретатор подключаться к IMAP как клиент или обращаться непосредственно к почтовому хранилищу. Архитектура различается, но область действия остаётся прежней: текущее письмо.

Для нескольких действий доставки стандарт задаёт приоритет. Если дедупликация объединяет несколько keep или fileinto, победить должен последний список флагов. Итоговая копия не обязана объединять намерения всех предыдущих ветвей. Чтобы понять конечный набор, нужно проследить порядок действий и механизм доставки, а не просто сложить все вызовы addflag в сценарии.

RFC 5232 входит в семейство Sieve рядом с базовым RFC 5228, расширением переменных RFC 5229 и отношениями сравнения RFC 5231. Эти документы объясняют синтаксис и обработку значений, не меняя границу доставки. Более поздний IMAP4rev2, RFC 9051, различает постоянные флаги и флаги только на время сеанса, а \\Recent считает устаревшим. Запросить отметку — не то же самое, что доказать её долговременное сохранение. Стандарт задаёт протокольный контракт, но не доказывает реализацию на конкретном сервере, фактическую доставку до читателя или отображение значка в клиенте.

Источники