Кратко

  • RFC4865 позволяет клиенту поручить серверу подачи почты хранить сообщение до будущего момента. Запрет выпустить его раньше не гарантирует выпуск ровно в назначенную секунду, доставку в ящик или прочтение.
  • При совместном использовании с DELIVERBY клиент обязан поставить срок доставки строго позже выпуска. Условие отказа сервера сформулировано отдельно; даже непротиворечивая заявка сохраняет зависимости от квот, часов, режима истечения срока и последующих наблюдений.

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

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

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

В этом состоит управленческий интерес RFC4865. Опубликованный в мае2007 года документ определяет Future Message Release для подачи почты через SMTP. Клиент может заранее передать сообщение серверу, чтобы тот хранил его до будущего выпуска. Это полезно устройствам без подходящего локального хранения или возможности оставаться доступными в назначенный момент.

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

Что именно откладывает расширение

Сервер сообщает о FUTURERELEASE в ответе EHLO и указывает две границы: максимальную продолжительность ожидания и наиболее далёкую допустимую дату со временем. Клиент проверяет поддержку и включает в MAIL ровно один параметр удержания.

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

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

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

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

Относительная запись тоже не устраняет зависимость от часов. RFC4865 прямо предупреждает: неточное или меняющееся время сервера может вызвать преждевременный либо запоздалый выпуск при обоих механизмах. Удобная для клиента форма запроса не удостоверяет качество временной основы оператора.

Другая граница — другое обязательство

DELIVERBY, определённое в RFC2852, задаёт период доставки и требуемое поведение, если письмо не удаётся доставить вовремя. Расширение не требует приоритетной обработки. Сервер вправе назначить приоритет, но сам параметр не даёт отправителю такого права.

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

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

Раздел5.2.1 RFC4865 требует от клиента, использующего оба расширения, обеспечить срок доставки строго позже указанного или вычисленного времени выпуска. Недостаточно проверить, что обе величины относятся к будущему. Важен порядок между ними.

Для сервера раздел5.2.2 задаёт иную формулировку: если сервер поддерживает оба расширения и определяет, что выпуск приходится позже срока доставки, он обязан отклонить MAIL. Документ рекомендует ответ501 и расширенный код состояния5.5.4.

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

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

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

Истечение срока не всегда означает остановку

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

В Notify достижение срока само по себе не требует прекращать работу. Документ рекомендует продолжать попытки согласно политике узла и выдать установленное уведомление о задержке соответствующим адресатам. Граница информирования отличается от границы прекращения попыток.

Сводка «срок истёк» может быть удобна для экрана, но недостаточна для автоматики. Повторять всё без разбора — значит рисковать нарушением Return. Останавливать всё — значит прерывать работу Notify, которая должна была продолжаться. Большее число доставленных писем не всегда означает более точное исполнение.

Есть и условия для следующего участка. Return нельзя передать серверу без поддержки DELIVERBY или серверу, чей фиксированный минимальный интервал превышает оставшееся время. Notify может пройти через неподдерживающий узел с последствиями для уведомления, указанными в RFC2852.

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

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

Даже положительный ответ необходимо привязывать к стадии SMTP. Успех MAIL не равен окончательному принятию всех данных сообщения и тем более доставке. Невозможность исполнить требование может выясниться при обработке адресатов или завершении передачи данных, что отдельно оговаривает RFC2852. Единый счётчик «принято» стирает эту разницу.

Завтрашняя работа занимает сегодняшнее место

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

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

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

Коды X.7.16 и X.7.17 разделяют нехватку пользовательской и системной квоты. В одном случае может помочь освобождение очереди данного пользователя, в другом требуется восстановление общего запаса. Эти состояния не дают основания назначать единое время повторной попытки.

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

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

В Note32 Lu Heng разбирает агентскую проблему, возникающую при отделении контроля от экономических последствий. В применении к этому случаю полезно спросить, кто расширяет календарь доступных обещаний, кто оплачивает накопленную работу и кто отвечает за её исполнение. Это не доказывает дурных намерений компании или инженера. Note36 о BTW.Media как раз требует описывать структуру, не подменяя её защитой одной из сторон.

Инструкция и наблюдение должны сохраняться рядом

Если сервер подачи создаёт DSN о сообщении с запросом будущего выпуска, RFC4865 требует поля Arrival-Date и Future-Release-Request в машиночитаемой части. Второе сохраняет исходное значение ожидания в предусмотренной форме.

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

Клиенту запрещено запрашивать Future Message Release при подаче DSN или уведомления о распоряжении сообщением MDN. Отчёт об обработке не должен через этот механизм превращаться в ещё один намеренно отложенный отчёт. Это ограничение не обещает, что транспорт никогда не задержит уведомление.

Поле Date также не заменяет историю очереди. RFC4865 описывает его неизменность после подачи: клиент может выбрать будущую дату, а от транспорта не ожидается изменения следов маршрута, чтобы скрыть задержку. Это отличается от ограниченного добавления отсутствующего Date или исправления его синтаксиса при подаче, допускаемого RFC6409.

RFC6409 заменяет RFC4409 и разделяет подачу и ретрансляцию. Для подачи обычно используется порт587. Общее разрешение назначить некоторые службы на25 службами подачи не превращает обычный ретранслятор в службу, которой следует объявлять FUTURERELEASE. Собственная область применимости расширения остаётся в силе.

Где заканчивается документальное основание

Проверенная редакционная поправка2040 к RFC4865 исправляет неопределённую грамматическую продукцию даты и времени ссылкой на date-time из RFC3339. Замечание автора сообщения о его работающем сервере относится к2010 году. Это атрибутированное историческое свидетельство, а не нынешняя статистика внедрения.

Редакционная поправка2300 к RFC2852 отложена до обновления документа. Она касается пробелов в грамматике, а не изменения режимов или сроков. Состояние поправки нужно сохранять так же точно, как её содержание.

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

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

Источники