Кратко
- Исходный литерал IMAP был строкой с октетным счётчиком внутри одной команды. После
{n}клиент ждал продолжение+, затем отправлял данные и остаток синтаксиса. - LITERAL+ ввёл
{n+}без промежуточного ответа. Сервер, решивший отказать, теперь должен был осушить уже разрешённый поток или закрыть соединение. - LITERAL- сохранил ту же форму, но ограничил инициативу 4096 октетами. APPENDLIMIT отдельно сообщил глобальную или почтовую политику, а IMAP4rev2 включил ограниченный вариант в базовую грамматику.
CRLF был лишь остановкой парсера
Литерал может содержать CR и LF, поэтому его нельзя завершить поиском новой строки. Получатель отсчитывает объявленное количество, а сразу после него продолжает разбирать ту же команду. Там может быть пробел, новый аргумент или следующий литерал.
RFC 2060 требовал после A001 LOGIN {11} дождаться запроса продолжения. Если сервер видел ошибку в префиксе, он отвечал BAD и не допускал нежелательные данные в поток. RFC 3501 сохранил правило.
Ответ + не принимал всю LOGIN или APPEND. Он открывал только очередной фрагмент. Даже {0} обязан был ждать: право продолжить существовало независимо от размера нагрузки.
Это не окно TCP. Транспорт управляет буферами и не знает почтовых ящиков. Продолжение IMAP было прикладным решением внутри синтаксиса.
Право отправить без нового вопроса
RFC 2088 в январе 1997 года определил LITERAL+. После такой capability клиент мог написать {n+} и сразу передать n октетов. Без объявления он использовал синхронизированную форму.
Счётчик оставался границей. Сервер распознавал плюс в конце строки, читал точное количество и возвращался к команде. Исчезло не кадрирование, а один обмен запросом и разрешением. При большом RTT и нескольких литералах выигрыш накапливался.
Capability означала добровольную делегацию. Сервер заранее отдавал клиенту решение, которое раньше принимал у каждого литерала. Одновременно он отодвигал момент дешёвого отказа.
Отказ после начала передачи
RFC 7888 описал последствия. С LITERAL+ огромный литерал может идти, когда сервер уже понял, что не примет его. Можно прочитать и выбросить заявленные октеты, сохранив границу потока ценой сети и памяти. Можно послать BYE и закрыть соединение, создав повторное подключение и возможную новую попытку.
Ранний BAD или NO сообщает решение, но не отзывает байты, отправка которых была разрешена. APPEND делает цену особенно заметной: в литерале помещаются целое сообщение и вложения. Клиент экономит ожидание, сервер получает уборку.
Почему минус не появился на проводе
RFC 7888 заменил RFC 2088 и определил LITERAL+ и LITERAL-. При LITERAL- несинхронизированный литерал не превышает 4096 октетов. Более крупный возвращается к {n} и ожиданию.
На проводе всё равно стоит {n+}. Минус находится в имени capability. Сервер не объявляет обе одновременно, поскольку именно договорённость говорит, безграничен ли плюс или ограничен малым объёмом.
4096 — не квота ящика и не максимум письма. Это предел отправки без отдельного приглашения. Малый APPEND может провалиться, большой — пройти после продолжения. Множество малых литералов по-прежнему способно исчерпать ресурсы, поэтому улучшение против DoS лишь частичное.
Иная шкала APPENDLIMIT
RFC 7889 позволил объявить максимальный размер APPEND. Значение может быть общим или запрашиваться для конкретного ящика через STATUS либо LIST-STATUS.
Клиент не начинает заведомо слишком большую загрузку. Однако размер ниже значения не обещает успеха: ACL, квота и другие причины остаются. Если лимит неизвестен, RFC советует не применять несинхронизированный литерал для APPEND.
Две шкалы намеренно раздельны. 4096 ограничивает общую синтаксическую делегацию. APPENDLIMIT выражает локальную политику, способную различаться по ящикам. Минимальное общее правило не присваивает себе будущие решения оператора.
Ожидание стало частью IMAP4rev2
RFC 9051 встроил семантику LITERAL- в IMAP4rev2. Обычно более 4096 октетов снова требуют продолжения. Современный протокол сохранил паузу там, где до больших затрат нужно согласие.
Реестр IANA содержит LITERAL+, LITERAL- и APPENDLIMIT. Он подтверждает стандартные значения, а не сегодняшнее распространение.
История описывает переход полномочий: отдельное разрешение сервера, предварительная делегация клиенту, ограниченная делегация и отдельное свидетельство политики. Устранённый сетевой круг не исчез бесследно — его цена стала риском отказа другой стороны.
Источники и границы
- https://www.rfc-editor.org/rfc/rfc2060.html
- https://www.rfc-editor.org/rfc/rfc2088.html
- https://www.rfc-editor.org/rfc/rfc3501.html
- https://www.rfc-editor.org/rfc/rfc7888.html
- https://www.rfc-editor.org/rfc/rfc7889.html
- https://www.rfc-editor.org/rfc/rfc9051.html
- https://www.iana.org/assignments/imap-capabilities/imap-capabilities.xhtml
Источники не измеряют нынешнюю поддержку, производительность или атаки. Продолжение не равно окончательному приёму, 4096 не квота, а APPENDLIMIT не гарантирует меньшую загрузку.
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
