Кратко

  • DELIVERBY добавил к SMTP-конверту секунды и режим истечения. R прекращал попытки и требовал отказа, а N сообщал о задержке, не отменяя локальную политику доставки.
  • Поддерживающий ретранслятор вычитал прошедшее время и передавал остаток. Расширение не давало приоритета, не гарантировало своевременную доставку, не продлевало обычное хранение и не ускоряло автоматически обратную DSN.

В обычной арифметике отрицательный остаток означает, что бюджет исчерпан. В RFC 2852 он мог нести ещё одно значение: событие опоздало, но сообщение не потеряло право на доставку. Поэтому BY=-30;N мог быть допустим, а BY=-30;R — нет.

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

Deliver By SMTP Service Extension, опубликованный в июне 2000 года, позволил отправителю сделать выбор явно. RFC приводил пример письма, способного вызвать pager: до 17:00 оно полезно, после — нежелательно. Обычная очередь знала правила повторов, но не знала внешнего смысла этой границы.

Два режима давали истечению разные последствия

Клиент помещает параметр BY в MAIL FROM. В нём есть знаковое число секунд, R или N, а также необязательный T для трассировки. Максимальный модуль равен девятистам девяноста девяти миллионам девятистам девяноста девяти тысячам девятистам девяноста девяти секундам и может иметь отрицательный или положительный знак.

В Return (R) ноль и отрицательные значения недопустимы. Если deliver-by-time наступил до доставки или передачи, новые попытки запрещены. Для подходящих получателей MTA формирует failed DSN со статусом 5.4.7, delivery time expired.

В Notify (N) очередь продолжает работу по локальной политике. Для получателей, которым полагается уведомление, создаётся delayed DSN со статусом 4.4.7. Ноль и минус сохраняют доказательство опоздания, не превращая его в приказ уничтожить сообщение.

Постоянная ошибка может завершить доставку раньше. Временная допускает повторы до срока. Локальная retention policy может быть короче. DELIVERBY не заменял жизненный цикл очереди; он добавлял точку, в которой заранее выбранное значение меняло допустимое действие.

Отправитель не покупал место в начале очереди

Сервер сообщает поддержку словом DELIVERBY в EHLO и может объявить фиксированный минимум для Return. Клиент не получает нового SMTP-глагола и не может потребовать особой сортировки.

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

Положительный ответ на MAIL FROM тоже не является полной гарантией. Ограничение может обнаружиться при RCPT TO, DATA или конце данных, когда стали известны получатели и содержание. Ранний успех относится только к уже проверенному этапу.

Разность времени не требовала общей абсолютной шкалы

Число в BY — delta. Приняв его, сервер прибавляет секунды к собственным часам и получает локальный deliver-by-time. Перед новым MAIL FROM он вычисляет, сколько осталось.

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

Delta не задаёт deliver-after: сообщение не обязано ждать до будущей даты. Она задаёт верхнюю границу. И она не увеличивает обычный период хранения: MTA может вернуть безнадёжное письмо раньше.

На каждом hop первоначальный кредит уменьшался

Если следующий сервер тоже поддерживает DELIVERBY, ретранслятор сохраняет режим и передаёт новое значение оставшихся секунд. В примере RFC из 120 после 22 потраченных остаётся 98. Возврат к 120 позволил бы каждому домену стирать собственную задержку.

Для R нужна непрерывная цепочка capability. Сообщение нельзя передать серверу без DELIVERBY или серверу, чей заявленный minimum превышает остаток. Можно проверить другой законный маршрут; если подходящего нет, письмо считается недоставимым. Перенести bytes, но удалить срок — значит изменить решение отправителя.

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

Стандарт не централизует очереди. Он определяет только маленькое общее состояние: остаток времени, режим и свидетельство точки, где смысл больше не наследуется. Локальная автономия остаётся, но потраченное время нельзя объявить непотраченным.

Уведомление жило в другой очереди

DELIVERBY использует DSN для failed, delayed и relayed, а также добавляет поле Deliver-By-Date. Флаг T может запросить промежуточные relayed DSN; они не являются финальным результатом.

DSN описывает действие в машиночитаемой форме. DELIVERBY выбирает действие, требуемое истечением. В R меняется право продолжать; в N — обязанность показать опоздание. Поэтому предмет статьи не общий bounce, а наследование временного ограничения.

Обратный отчёт не обязан вернуться по тому же таймеру. BY=60;R может остановить сообщение через минуту, но failed DSN идёт как отдельная почта. RFC предупреждает, что она не получает гарантированного ускорения. Ограниченный forward decision не создаёт мгновенного знания у отправителя.

Отрицательные значения могли раскрывать инфраструктуру

T показывает передачи. Даже без него серия сообщений с постепенно увеличивающимися короткими сроками позволяет грубо исследовать пороги и задержки. RFC 2852 относит такую трассировку к security considerations.

Интерпретация остаётся узкой. Отрицательное N не называет виновный hop. 5.4.7 не доказывает небрежность. relayed подтверждает передачу, а не финальную mailbox delivery. Временной сигнал — evidence, а не готовый приговор.

Текущий реестр SMTP IANA по-прежнему содержит DELIVERBY, ссылается на RFC 2852 и указывает уровень MAY. Это регистрационный факт, не статистика внедрения.

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

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

Источники