Кратко

  • RFC 3028 определил фильтрацию как ограниченный язык действий и ввёл неявное сохранение, если сценарий не выбрал действие, отменяющее обычную доставку.
  • keep, fileinto, redirect, discard и отказ описывали решение интерпретатора, но сами по себе не доказывали устойчивую запись, удалённое принятие или окончательный исход.

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

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

Пропущенный случай не должен был уничтожать письмо

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

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

Это не была дополнительная копия после каждого явного действия. keep, fileinto, redirect и discard отменяли неявное сохранение. Расширение с побочным эффектом должно было объяснить, оставляет ли оно защиту в силе.

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

За каждым глаголом находился другой исполнитель

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

fileinto называл папку. RFC 3028 рекомендовал поддержку, одновременно признавая среды, где она невозможна. Строка с именем была поручением агенту доставки, а не доказательством существования папки и устойчивой записи.

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

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

Совместимость действий ограничивала противоречия

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

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

RFC 5228 заменил RFC 3028, сохранил неявное сохранение и базовые действия, но уточнил ошибки, лимиты и обязанности расширений. RFC 9122 позднее создал реестр действий Sieve в IANA, где отдельно указаны взаимодействия и отмена неявного сохранения. Реестр описывает договор действий, а не успешность конкретной обработки.

Отказ показал цену неверно выбранного момента

Исходный reject из RFC 3028 отбрасывал сообщение и отправлял уведомление отправителю конверта. При этом принимающая система могла уже принять письмо. Если адрес отправителя был подделан, уведомление шло невиновной стороне и создавало обратный мусорный трафик.

RFC 5429 добавил ereject, предпочитающий отказ во время SMTP или LMTP, когда компонент способен это сделать. Документ уточнил отмену неявного сохранения, запретил несколько отказов и не рекомендовал сочетать отказ с доставкой. Причина была содержательной: нельзя заявлять, что письмо не доставлено, если система одновременно сохранила или переслала его.

Состояние «отклонено» скрывало разные факты. Сценарий мог выбрать отказ; исполнитель мог иметь или не иметь возможность отказать на протокольной границе; отправитель мог увидеть немедленный ответ, поздний отчёт или ничего. Без слоя и свидетельства статус неполон.

ManageSieve в RFC 5804 стандартизировал отдельную административную поверхность: загрузку, проверку, перечисление и активацию сценариев. Активный сценарий не доказывает обработку данного письма. Выбранное действие не доказывает результат. Управление, решение и эффект требуют разных записей.

Источники

Lu Heng не писал и не одобрял RFC 3028, RFC 5228 или RFC 5429. Его эссе используются здесь как явно обозначенные аналитические рамки.