Кратко

  • RFC 10022 позволяет получить убывающие диапазоны UID примерно по заданному числу сообщений, в том числе в режиме UIDONLY. Они готовят последующие операции, но не замораживают ящик и не являются сохранённым поиском.
  • Границы диапазона могут не соответствовать существующим письмам. Пакет бывает меньше запроса, сокращается после удалений и не гарантирует одинаковые байты, задержку или вычислительную стоимость.
  • Daniel Eggert редактировал консенсусный документ IETF. Спецификация задаёт узкий общий механизм, оставляя алгоритм серверу, планирование клиенту, а доказательство результата оператору.

Клиент получил диапазон и сохранил его на неделю. За это время сотни писем были удалены. Числовые границы по-прежнему выглядят убедительно, но пакет уже содержит меньше сообщений. Попытка назвать его «страницей 12» переносит ожидание стабильного состава туда, где протокол обещал лишь ограничение работы.

RFC 10022, IMAP UIDBATCHES Extension, опубликована в июле 2026 года как Proposed Standard. Редактор — Daniel Eggert из Apple Inc. Расширение позволяет заранее разбить выбранный почтовый ящик на диапазоны UID, чтобы последующие FETCH, SEARCH или STORE не охватывали неограниченное число сообщений.

В UIDONLY номера последовательности недоступны, поэтому такой механизм особенно полезен. Но его польза не отменяет времени: ящик остаётся изменяемой системой.

Диапазон сокращается вслед за ящиком

Новые сообщения получают более высокие UID и не появляются внутри уже возвращённого диапазона. Поэтому его население не растёт. Удаление через EXPUNGE, напротив, убирает сообщения из диапазона.

Клиент может учитывать EXPUNGE, VANISHED и EXISTS. RFC 10022 разрешает повторный расчёт после выбора другого ящика, после удаления более половины размера пакета или после прихода более половины пакета новых сообщений. В других случаях клиент не должен повторять UIDBATCHES.

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

Журнал должен объяснять право на пересчёт: исходный размер, накопленные события, порог и момент его пересечения. Запись «обновлено» без причины скрывает разницу между законной реакцией и дефектным циклом.

Идентичность ещё важнее. UID имеет смысл внутри выбранного ящика при конкретном UIDVALIDITY. Перенос кэша в другой ящик или новую валидность не создаёт устаревшую страницу; он лишает номера надёжной системы координат.

Концы диапазона не обязаны существовать

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

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

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

Ответ UIDBATCHES — инструкция для разделения. Фактический состав появляется в ответе последующего FETCH или SEARCH; результат изменения — в STORE. Обе ступени следует хранить отдельно и связывать одним идентификатором работы.

UIDBATCHES не является SEARCH или UID SEARCH, а SEARCHRES не должен сохранять его результат в $. PARTIAL предоставляет страничные SEARCH и FETCH, тогда как UIDBATCHES даёт диапазоны до выбора последующей операции.

Одинаковое число не означает одинаковую работу

Минимальный запрос — 500 сообщений. Сервер не вправе вернуть больше запрошенного, должен стремиться к точному размеру и по возможности к уровню не ниже 90%. Меньший пакет допустим ради существенной простоты или эффективности, а также при изменении ящика во время расчёта. Последний пакет обычно содержит остаток.

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

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

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

Соседним окнам нужна общая граница

Большой ящик можно запрашивать частями: 1:100, затем 101:200. Размер приблизителен, а состояние меняется. Поэтому RFC предлагает перекрывать одну позицию: 1:100, 100:200, 200:300.

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

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

Диапазонный запрос не должен охватывать больше 100 тысяч сообщений. Сервер обязан поддерживать как минимум такой объём, но может ответить TOOMANY сверх него. Для огромного ящика допустим отказ от выдачи всех диапазонов. MESSAGELIMIT добавляет предел на число сообщений в последующей команде.

Минимум 500 поддерживает замысел UIDONLY. Слишком мелкие пакеты позволили бы восстановить детальную позиционную информацию, похожую на номера последовательности.

Пустой ответ требует исходного вопроса

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

Различие несут tag команды, диапазон индексов и состояние EXISTS при выборе. Панель «0 пакетов» может ошибочно назвать ящик пустым, хотя клиент лишь запросил окно за его концом.

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

Daniel Eggert не заменяет владельцев реализации

На момент сохранения 1 сентября 2026 года официальный профиль Daniel Eggert в IETF Datatracker перечислял RFC 10022 и RFC 9979. В материале Swift.org о SwiftNIO IMAP 2022 года он представлен участником команды Apple, работающей над Mail для iOS и macOS, со ссылкой на публичный профиль GitHub.

Это датированный профессиональный контекст, а не доказательство внедрения в конкретный продукт. Источники не показывают, что Eggert управляет производственным сервером или владеет консенсусом IETF. Редактор, разработчик и оператор отвечают за разные акты.

Документированный вклад сохраняет это разделение. RFC задаёт общую команду и защитные границы; сервер выбирает расчёт, клиент — стратегию, оператор — критерий завершения. Minimum Initial Specification у Heng Lu объясняет достоинство малого общего слоя, а Running-Code Primacy возвращает окончательную проверку к фактическому выполнению.

Квитанция вместо догадки

Сначала сохранить сервер, границу учётной записи, ящик, UIDVALIDITY и возможности. Затем tag, количество, индексы, код и точные диапазоны. Связать EXISTS, EXPUNGE, VANISHED, основание пересчёта и сравнение перекрытий.

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

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

Источники