Кратко

  • В исходном SMTP ошибка размера или хранилища могла обнаружиться лишь после полной передачи DATA и удаления объекта.
  • RFC 1870 разрешил серверу объявить фиксированный максимум в EHLO, а клиенту — оценку октетов в MAIL FROM. Постоянное превышение получило код 552, временная нехватка — 452.
  • Число осталось ограниченным свидетельством: оно не завершает DATA, не резервирует ресурсы всей цепочки и не превращает успешный MAIL в гарантию доставки.

Решение после затрат

RFC 821 задавал порядок: MAIL, один или несколько RCPT, затем DATA. После ответа 354 отправитель передавал заголовок, тело и завершающую строку. Только после этого получатель отвечал за весь объект.

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

Два заявления с разными владельцами

Механизм появился в RFC 1427 в 1993 году, был пересмотрен RFC 1653 и стал стандартом в RFC 1870 в 1995-м. Сервер указывает SIZE в EHLO и может добавить наибольший размер, всегда допустимый его фиксированным правилом.

Ноль означает отсутствие фиксированного максимума. Отсутствие числа означает лишь отсутствие сведений о нём, а не бесконечную ёмкость. Клиент может добавить свой SIZE к MAIL FROM — оценку конкретного письма. Если точный подсчёт непрактичен, допустима эвристика с предпочтением завышения.

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

Подсчёт не задаёт границу

Размер включает заголовок, тело и пары CR-LF после ответа 354. Завершающая точка DATA и дополнительные точки для прозрачности SMTP не учитываются.

RFC 1870 запрещает применять SIZE для поиска конца данных. Ошибочная оценка может изменить решение о приёме, но не должна превратить содержимое в команды. Терминатор DATA сохраняет власть над границей. SIZE касается ресурсов; точечная прозрачность и BDAT — кадрирования.

452 оставляет время, 552 закрывает его

Если заявление превышает фиксированный предел, сервер может вернуть 552: повтор того же объекта при той же политике бесполезен. Если ресурсов нет сейчас, но они могут появиться, 452 позволяет снова поставить попытку в очередь.

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

Ранний 250 не является квитанцией

Успех MAIL не гарантирует DATA, хранение, следующий ретранслятор или конечный ящик. Реальный объект может быть больше заявления, ресурсы могут измениться. Сервер вправе простить занижение, но не обязан.

Есть ограниченное доверие: приняв заявленный размер, сервер не должен после DATA отвечать 552 только из-за обычного фиксированного предела, если фактический объект не превысил заявление. Раннее решение становится полезным, но не изображает всеобщую бронь.

RFC 5321 позже потребовал принимать не менее 64K октетов и рекомендовал SIZE серверам с ограничениями. Единого мирового размера вложения он не создал. Каждый узел сохранил власть над своими затратами; стандарт лишь дал способ вовремя сообщить границу.

Источники и ограничения

RFC 821 задаёт исходную сделку, RFC 1427, RFC 1653 и RFC 1870 — развитие SIZE, RFC 5321 — позднюю основу. Они не измеряют современное внедрение или пределы провайдеров. SIZE не аутентифицирует содержимое, не доказывает квоту, не резервирует каждый переход и не подтверждает доставку. Узкое свидетельство ёмкости устранило часть обречённой работы без централизации власти.