Кратко

  • RFC 5230 добавил в Sieve действие, создающее новое сообщение для отправителя исходного SMTP-конверта, и учет того, получал ли этот адрес тот же ответ в течение заданного периода.
  • Управлял не только текст: проверка адресата, идентичность ответа, заголовки против петель и ограниченный интервал решали, кому и когда придет уведомление.

Отсутствие могло затронуть других

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

В 2008 году RFC 5230 добавил vacation в Sieve — намеренно ограниченный язык фильтрации почты. Скрипт мог сообщить, что пользователь не ответит быстро, а интерпретатор создавал отдельное сообщение. Это было первое расширение Sieve, способное сформировать совершенно новое письмо. Последствие отличалось от перемещения сообщения в папку: правило запускало внешнюю коммуникацию, на которую могла отреагировать другая автоматическая система.

Ответ отправляется на адрес SMTP-конверта исходного сообщения — MAIL FROM; если Sieve работает после окончательной доставки, этот адрес обычно доступен в Return-Path. Видимый пользователю заголовок From не является достаточным основанием. Для нового сообщения рекомендуется пустой адрес отправителя конверта. Если поддерживается расширение уведомлений о доставке, следует запросить, чтобы сбой ответа не породил еще одно уведомление. Auto-Submitted обозначает автоматическую отправку. Поля даты, отправителя, получателя и ссылки на исходное сообщение описывают именно новое сгенерированное письмо, а не маскируют его под исходное.

Один адрес, один определенный ответ, один интервал

Самое важное состояние легко не заметить. Vacation отслеживает ответы по каждому адресу в течение заданного срока. Тот же человек может написать снова, пока пользователь отсутствует, но система не обязана каждый раз повторять тот же текст. :days задает интервал подавления. Если параметр пропущен, выбирается большее из семи дней и минимального значения сайта. Сайт может определить положительный минимум и максимум; выходящие за границы значения ограничиваются ими. Число в скрипте поэтому не всегда равно фактическому периоду.

Это не общий флаг «об отсутствии уже сообщили». Система различает, какой именно ответ получил конкретный отправитель. Явный :handle назначает общий идентификатор ответам, в которых он совпадает. Без него идентичность выводится из :subject, :from, :mime и строки причины. Так разные ветви могут отправить одному человеку разные пояснения, а совпадающие аргументы разделяют историю подавления. Если используется расширение переменных RFC 5229, их значения нельзя подставлять до расчета идентичности ответа: ключ строится по параметрам команды, а не по строке, меняющейся при каждом запуске.

Интервал работает как небольшая база политик. Ключ объединяет адрес отправителя и идентичность ответа. Это убирает бесполезные повторы, но позволяет сообщить новое, если изменился контекст. Автор скрипта определяет, какие ответы считать одним и тем же; оператор задает предел фактической частоты.

Ответ должен был предназначаться отсутствующему пользователю

RFC 5230 требует, чтобы адрес пользователя присутствовал в To, Cc, Bcc или соответствующих Resent-полях. Система может установить принадлежность адреса по данным учетной записи, финальному получателю SMTP-конверта либо списку :addresses в скрипте для дополнительных псевдонимов. Такой список помогает при нескольких адресах, но пересылка и подадресация могут сделать его неполным.

Есть и ограничения для автоматизированных систем и списков. Реализация обязана хранить перечень адресов, которым нельзя отправлять ответы; среди рекомендованных примеров — типичные имена демонов и программ управления списками. Не следует отвечать на письма с заголовками управления списком или со значением Auto-Submitted, отличным от no. Реализация также может подавлять сообщения, если их заголовки или содержание делают ответ неуместным. Стандарт не обещает, что каждый сервер распознает все автоматические потоки: часть списка определяется самой реализацией, а защита зависит от наблюдаемых данных.

RFC 3834 еще в 2004 году опубликовал общие рекомендации по автоматическим ответам. RFC 5230 говорит, что vacation как персональный автоответчик задумывался в соответствии с ними. Более поздние RFC расширили границы: RFC 6131 добавил :seconds, включая ноль для ответа на каждое письмо; RFC 6133 показал сочетание с присутствием и адресной книгой; RFC 8580 разрешил сохранять копию созданного ответа в ящике. Это история возможностей стандарта, а не свидетельство их повсеместного внедрения.

Сообщение — это не только его текст

RFC 5230 поддерживает UTF-8 и MIME, в том числе варианты на нескольких языках. Скрипт может выбирать текст по заголовкам, но спецификация предупреждает: простая проверка поля языка может ошибиться. Тон ответа тоже может зависеть от того, пишет коллега или незнакомый человек, а не только от языка. Выбор текста одновременно определяет его аудиторию.

Действие остается узким: выполняется не более одного раза за скрипт, несовместимо с reject и refuse и не отменяет неявное keep в Sieve. Эти ограничения помогают понять его место в языке, но не повторяют общий разбор RFC 3028 о выборе действий. Собственный исторический вклад RFC 5230 — политика нового исходящего сообщения: его получатель, идентичность ответа, заголовки и интервал повтора.

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

Источники