Кратко

  • При наличии подходящего ящика специального назначения Sieve выбирает его раньше папки, указанной по имени. К обычному именованному назначению возвращаются, когда соответствующего ящика нет или реализация не знает атрибут.
  • Если доставка в выбранный ящик завершилась ошибкой, не связанной с его существованием, последующая попытка в папку по умолчанию запрещена. Иначе временные сбои незаметно распределяли бы переписку между разными местами.
  • Назначение ролей, выбор среди нескольких ящиков, начальная настройка, права и доступная ёмкость — разные условия. Неизменность фильтра не доказывает неизменность результата.

Хронологию переписки разделила бы хронология аварии

Представим журнал работы почтового фильтра. Первая часть сообщений попала в архивный ящик. Во время нехватки места следующая часть была сохранена в другой папке. После восстановления ёмкости новые письма снова стали поступать в архив.

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

Это условный пример, а не описание исследованной аварии. Он показывает, зачем RFC 8579 ограничивает использование папки по умолчанию в расширении Sieve для ящиков специального назначения.

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

Запрещён более узкий шаг: нельзя без отдельного основания превратить проблему записи в решение о новом месте хранения.

Как назначение стало важнее имени

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

Расширение IMAP в RFC 6154 позволяет обозначать назначения атрибутами, например \Archive, \Drafts и \Junk. Клиенту не обязательно угадывать функцию по названию. При этом папка с привычным названием ещё не становится назначенным архивом только из-за этого названия.

RFC 8579 добавляет аналогичный выбор в Sieve через аргумент :specialuse. Операция сначала ищет в личном пространстве имён пользователя ящик с запрошенным атрибутом. Если находит, использует его вместо ящика, названного обычным позиционным аргументом.

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

Здесь есть приоритет, а не список равноправных мест, которые разрешено пробовать до первого успеха. Вторая ссылка нужна для определённого исхода поиска. Она не означает, что после выбора первой цели можно всякий раз продолжать перебор.

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

Полный ящик не равен отсутствующему

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

Аргумент в пользу записи туда кажется убедительным: сообщение сохранено, пользователь избежал задержки, счётчик ошибок уменьшился. Однако поиск назначенного ящика не провалился. Выбранная цель не исчезла из-за недостаточной ёмкости.

Именно эту подмену предотвращает RFC 8579. Документ объясняет запрет риском неожиданного распределения сообщений по двум ящикам при временных или перемежающихся ошибках. Сбой хранения не должен тайно становиться правилом сортировки.

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

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

Допустимый запасной режим нужно выбрать явно

Пользователь действительно может предпочесть другое место задержке. Организация может предусмотреть режим работы при нехватке ёмкости. Из запрета в расширении не следует, что такие решения всегда ошибочны.

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

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

Сохранение ошибки в её исходной точке также не освобождает эксплуатацию от обязанностей. Нужно восстановить условия доставки, выяснить итог обработки и объяснить его пользователю. Ограничение не устраняет работу по восстановлению; оно не позволяет скрыть её за неоговорённой сменой назначения.

Проверка разрешения не резервирует ёмкость

Тест specialuse_exists проверяет определённые условия существования, назначения и возможности доставки в контексте пользователя, от имени которого выполняется сценарий.

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

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

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

В журнале полезно сохранять оба этапа: контекст пользователя и проверенные назначения, выбранный ящик и фактический результат. Одна зелёная отметка предварительной проверки не объясняет последующий отказ и не даёт права менять цель.

Несколько кандидатов на одну роль

Специальное назначение не обязательно уникально. RFC 8579 допускает несколько личных ящиков с одним атрибутом.

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

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

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

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

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

Настройка не возникает из объявления возможности

Атрибуты специального назначения в RFC 6154 необязательны. Создание ящика с таким назначением зависит от отдельной возможности CREATE-SPECIAL-USE. Изменение роли через метаданные тоже требует поддержки и проверки допустимости со стороны сервера.

В списке исправлений RFC 6154 запись 4422 описывает неформальную проверку совместимости от 19 июля 2015 года. Сервер ожидал, что начальные назначения установит клиент, а клиент ожидал этого от сервера.

Статус записи — Held for Document Update. Предложенные меры нельзя представлять как новые действующие обязательные требования. Это также не измерение поведения сегодняшних поставщиков. Историческое наблюдение уже: обе стороны могут понимать механизм, но не договориться о том, кто подготовит данные для его работы.

Когда ни специальный, ни обычный именованный ящик не существует, применяются обычные правила отсутствующей цели. Явный аргумент :create требует при необходимости создать ящик, заданный по имени. При поддержке CREATE-SPECIAL-USE RFC 8579 рекомендует присвоить новому ящику запрошенное назначение, но не обещает одинаковый результат у любой реализации.

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

Область поиска — часть полномочий

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

RFC 8579 объясняет ограничение нагрузкой и риском неожиданного либо злонамеренного помещения писем в общие ящики. Присвоение роли общему месту не должно само по себе делать его целью чужого фильтра за счёт произвольно расширенного поиска.

Это не обещание, что личный ящик никогда не бывает общим. Ограничение также не переносится автоматически на каждую явно названную папку по умолчанию. Речь идёт именно об обнаружении специальной цели по атрибуту.

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

Что подтверждает эта исследовательская база

Здесь не проверялись реальные учётные записи, инциденты или продукты. Подтверждённое техническое исправление 5877 к RFC 8579 меняет оператор сопоставления в одном из последующих примеров, а не рассматриваемую границу выбора и ошибки доставки. Примеры протокола не выполнялись в рамках исследования.

Разбор агентской проблемы у Lu Heng предлагает полезный вопрос: несёт ли принимающий решение те расходы, которые оно создаёт? Сервис записи может показать успех, переложив поиск разбросанных сообщений на пользователя и поддержку.

Его объяснение задачи BTW требует описывать структуру, а не придумывать противостояние. В данном случае структура состоит в разделении двух фактов: место доступно и место разрешено использовать. Первое не устанавливает второе.