Кратко

  • Число в запросе UIDBATCHES задаёт максимальное количество существующих сообщений в одном диапазоне, а не точный размер. Сервер вправе вернуть меньше, а начальный и конечный UID могут не принадлежать существующим сообщениям.
  • OK UIDBATCHES completed подтверждает только расчёт границ. За операционное завершение отвечают отдельные доказательства: выбранный ящик и UIDVALIDITY, эпоха плана, поток изменений, реально адресованные UID и конечный исход для исчезнувших, новых и нерешённых сообщений.

Диапазон не обязан начинаться с письма

Представим, что сервер вернул 163886:99703. В интерфейсе две крайние цифры легко превращаются в две найденные записи, а ширина диапазона — в оценку количества. Оба вывода могут быть неверны.

UID растут внутри поколения ящика, но удаления оставляют пробелы. Сервер также может выбрать удобные числовые границы вокруг приблизительной группы. RFC 10022 прямо разрешает, чтобы на первом или последнем UID диапазона сообщения не было.

Последующая команда выбирает существующие сообщения внутри границ. Она не создаёт пустые края. Для самого старого пакета сервер может довести диапазон до UID 1, хотя минимальный существующий UID равен 302. Единица однозначно показывает, что ниже нет следующего пакета; существование письма 1 из неё не следует.

Эта деталь определяет модель данных. Граница — параметр выборки, а не подтверждённый объект. Числовая длина — не кардинальность. Система, которая сохраняет края как письма, добавляет собственное утверждение и затем ошибочно приписывает его протоколу.

Устойчивая ссылка по-прежнему требует имени ящика, UIDVALIDITY и UID. UIDBATCHES добавляет эпоху рабочего плана, но не заменяет поколение ящика и не удостоверяет содержимое.

Запрошенный размер — одностороннее обещание

При UIDBATCHES 2000 сервер не может вернуть диапазон, содержащий больше 2.000 существующих сообщений. Верхняя граница жёсткая.

Снизу симметрии нет. Серверу следует приблизиться к размеру запроса и по возможности достигать 90%, но он может вернуть меньше ради существенно более простой или эффективной реализации и из-за изменения ящика во время расчёта, особенно expunge.

Пакеты на 1.990, 1.977 и 2.000 сообщений могут быть результатом одного корректного ответа. Рекомендация 90% не превращается в безусловный порог качества. Она помогает клиенту ожидать разумную близость, не уничтожая свободу реализации и реальность конкурирующих изменений.

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

Минимальный размер равен 500. Меньший запрос получает TOOFEW. Ограничение защищает и вычисления, и смысл UIDONLY: если бы UIDBATCHES позволял один элемент на пакет, клиент восстановил бы тонкие последовательные позиции, которые UIDONLY удаляет.

Четыре пакета не удерживают 6.823 сообщения

В примере RFC 10022 выбранный ящик содержит 6.823 сообщения. Запрос размера 2.000 приводит к четырём диапазонам, расположенным от новых UID к старым. Это хороший план очереди и плохой снимок.

Новые сообщения получают UID выше прежнего максимума, поэтому не входят внутрь старых диапазонов. Их геометрия не расширяется из середины. Зато удаление уменьшает состав. При планировании в диапазоне могло быть около 2.000 сообщений, а FETCH позже увидит 1.982.

Диапазон может оставаться пригодным. Утверждение «обработано 2.000» уже непригодно. Новые сообщения формируют дополнительную область над старой верхней границей. Для выгрузки на фиксированный момент они относятся к следующей эпохе; для непрерывной синхронизации — к новому пакету сейчас. Это локальное решение владельца задачи.

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

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

Пусто и OK могут быть одним правильным ответом

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

Если доступно четыре пакета, а клиент запросил 6:8, пустой ответ означает отсутствие диапазонов в этом окне. Он не означает отсутствие сообщений во всём ящике.

Нужен конверт контекста: учётная запись, выбранный ящик, UIDVALIDITY, тег, размер, окно и время. Хранить только OK — значит сохранить ответ и потерять вопрос.

Отказы тоже нельзя свести к одному «сбою пагинации». TOOFEW требует увеличить размер. TOOMANY требует сузить окно или разделить запрос. LIMIT требует остановить лишний пересчёт. Окно, записанное 4:1 вместо 1:4, может получить CLIENTBUG. Разные причины дают полномочия разным владельцам на разные исправления.

Точная классификация уменьшает зависимость от частной трактовки поставщика: общая семантика уже говорит, что именно следует изменить.

Сто тысяч задают общий минимум, а не бесконечный максимум

Явное окно пакетов не должно охватывать больше 100.000 сообщений. Сервер обязан поддерживать выдачу диапазонов как минимум для такого населения. Но очень большой ящик может отвергнуть неограниченный запрос всех диапазонов с TOOMANY.

Правило ограничивает обе стороны. Сервер не вправе рекламировать пустой символ без общей минимальной способности. Клиент не получает права на неограниченный глобальный расчёт только из-за стандартизированного имени.

Крупный ящик обходят последовательными окнами. Поскольку состояние между запросами меняется, RFC 10022 предлагает перекрыть границу: 1:100, затем 100:200. Повторённый пакет позволяет сравнить две версии.

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

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

Соседние расширения не делятся полномочиями молча

UIDONLY запрещает номера последовательности после включения и сообщает об удалениях через VANISHED. UIDBATCHES даёт грубые UID-границы, но не возвращает поэлементную позиционную власть.

PARTIAL выдаёт страницы фактического SEARCH или ограничивает фактический UID FETCH. UIDBATCHES заранее готовит границы, которые ещё предстоит применить. Страница — часть результата; диапазон — часть плана.

SEARCHRES хранит результат поиска в $. RFC 10022 запрещает UIDBATCHES записывать туда, потому что команда не является SEARCH. Приблизительный план не должен незаметно превращаться в подтверждённый набор сообщений.

QRESYNC и CONDSTORE помогают увидеть изменения, модификационные последовательности и VANISHED. Они показывают расхождение с планом, но не превращают старый план в новый снимок задним числом.

MESSAGELIMIT сообщает, сколько сообщений способна обработать последующая команда. При лимите 1.000 клиенту следует выбирать UIDBATCHES не больше 1.000. Допустимый диапазон на 2.000 не даёт FETCH права нарушить собственный контракт.

CAPABILITY — перечень отдельных условий. Реальная рабочая единица определяется их пересечением с конкретным глаголом и текущим состоянием.

Завершение требует семи множеств

Один процент скрывает идентичность. Нужны отдельные населения:

Множество Вопрос доказательства
P Какие сообщения входят в политику задачи и это поколение ящика?
B Какие существующие сообщения были достижимы через диапазоны в момент планирования?
A К каким сообщениям реально применили последующие команды?
C Какие получили допустимый конечный результат?
X Какие ожидаемые сообщения наблюдались как удалённые или исчезнувшие?
N Какие новые сообщения появились выше старого максимума?
U Какие исходы неизвестны или допускают повтор?

Выгрузка на фиксированный момент может потребовать P = C ∪ X, пустое U и объяснение каждого X, а N отнести к следующей эпохе. Непрерывная синхронизация может сразу открыть для N новый пакет. Протокол оставляет выбор оператору.

Совпадение чисел недостаточно. Одно ожидаемое сообщение может исчезнуть, одно новое — успешно обработаться, и итог не изменится. Сверка требует ящика, UIDVALIDITY, UID и эпохи задачи.

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

Чего публичные источники не доказывают

RFC 10022 не устанавливает внедрение у названного провайдера, поведение продукта или производственное соответствие. 90% не являются опубликованной метрикой сервиса. Сценарии — эксплуатационные тесты из текста стандарта, а не сообщения об инцидентах.

Реестр IANA закрепляет значение UIDBATCHES, TOOFEW и TOOMANY, но не проверяет работающий код. CAPABILITY декларирует, диапазон отражает плановое состояние, последующая команда создаёт эффект.

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

Источники