Кратко

  • 8 мая 2026 года IESG одобрила draft-ietf-mailmaint-expires-06 как Proposed Standard. Поле указывает дату, после которой сообщение утрачивает действительность, но не задаёт единого обязательного действия.
  • Почтовая программа не должна отвергать или отбрасывать сообщение только из-за Expires и не должна удалять письмо с прошедшей датой, если владелец ящика не настроил такое поведение намеренно.

У отправителя есть часы, у получателя — архив

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

Expires даёт Reader точку для такого решения. Значение записывается как date-time по RFC 5322; Message Creator не должен добавлять более одного поля Expires. После указанного момента сообщение теряет действительность.

Однако спецификация намеренно не превращает эту формулу в универсальное «удалить», «скрыть», «отозвать» или «отказать в приёме». Для более точного нормативного смысла нет согласия, а существующие реализации исторически вели себя по-разному.

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

Решение принято, редакционный путь продолжается

IESG объявила об одобрении 8 мая 2026 года в 22:11 UTC. Документ подготовила Mail Maintenance Working Group; предполагаемый статус — Proposed Standard на Standards Track. На дату фиксации источников редакция 06 находилась в очереди RFC Editor, ожидала первого редактора, а состояние действия IANA было RFC-Ed-Ack.

В реестре Message Headers IANA поле Expires для электронной почты уже отмечено как standard со ссылкой на Internet-Draft. Для Netnews существует отдельная запись. Одинаковое имя поля не переносит автоматически правила одной среды сообщений в другую.

У поля есть более ранняя история: оно появлялось в отображениях X.400 и в старых регистрациях почтовых заголовков. Программы трактовали его неодинаково. Новая работа не объявляет это разнообразие давно существовавшей командой. Она фиксирует минимальный общий смысл и запрещает опасную реакцию по умолчанию.

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

От сравнения дат до удаления — несколько событий

Архитектура почты различает Message Creator и Message Reader. Reader может быть агентом хранения или пользовательским приложением. Он вправе уменьшить заметность устаревшего письма, исключить его из обычного вида или предложить очистку под контролем пользователя.

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

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

В IMAP4rev2 последние шаги видны непосредственно. Флаг \Deleted задаёт состояние сообщения. EXPUNGE окончательно удаляет сообщения с этим флагом, а UID EXPUNGE ограничивает действие выбранными UID. Другие хранилища могут использовать иной механизм, но должны сохранять сопоставимый след решения и результата.

Если весь путь назвать одним словом «истечение», аудит теряет причинность. Оператор уже не понимает, сработало ли утверждение отправителя, правило интерфейса, политика владельца или отдельная операция уничтожения.

DKIM подтверждает автора утверждения, а не его власть

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

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

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

Автоматизация допустима, если источник власти остаётся явным. Reader может учитывать дату, аутентификацию, историю отправителя, класс сообщения и предпочтения владельца. Журнал должен показывать, какое локальное правило превратило эти данные в изменение вида или удаление.

Злоумышленник тоже выбирает корректную дату

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

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

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

Различие в словах сохраняет различие в контроле. Если интерфейс его стирает, он скрывает и того, кто отвечает за потерю.

Источники