Кратко

  • RFC 2180 разрешал несколько корректных ответов, когда одна IMAP-сессия меняла ящик, которым пользовалась другая; успешная команда не доказывала, что все сессии сразу увидели одно и то же пространство имён и те же данные.
  • Практическим условием совместимости была терпимость клиента: программе приходилось согласовывать задержанные EXPUNGE, частичные результаты, «призрачные» сообщения и сдвигающиеся номера, а не принимать привычки одного сервера за весь протокол.

Удалённое имя не всегда означало недоступное содержимое

Представим, что два клиента выбрали ящик FOO. Первый посылает DELETE FOO и получает помеченный ответ OK. Третий клиент затем спрашивает о FOO, и сервер сообщает, что такого ящика нет. Однако второй клиент, выбравший ящик до удаления, может продолжать выполнять FETCH или STORE над его содержимым.

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

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

То же расхождение видно при переименовании. Сервер может изменить только атрибут имени. Клиент, который уже выбрал ящик, продолжит выполнять FETCH, потому что команда обращается к выбранному состоянию, а не к старому имени. Но APPEND FOO может завершиться неудачей и вернуть подсказку NEWNAME. Поверхность содержимого и поверхность пространства имён разошлись: старая сессия всё ещё держит объект, которого новый поиск по прежнему имени уже не находит.

Нумерация могла устареть раньше, чем клиенту разрешалось узнать причину

Параллельный EXPUNGE создаёт более острый конфликт. Номера сообщений в IMAP — это позиции в текущем выбранном ящике. После окончательного удаления одного сообщения все последующие позиции сдвигаются. Но RFC 2060 запрещает ответу EXPUNGE прерывать некоторые команды, включая FETCH, STORE и SEARCH. Поэтому клиент может действовать по старой карте позиций, пока обновление уже существует, но ещё не может быть передано.

RFC 2180 перечисляет несколько допустимых решений. Сервер может ненадолго сохранять призрачные копии, чтобы ответить на начатый FETCH. Может вернуть данные только для сохранившихся сообщений и завершить запрос ответом NO. Может выдать обычные данные для существующих сообщений, формы с NIL для исчезнувших и закончить OK. Наконец, он может вовсе не допускать EXPUNGE, пока ящик открыт несколькими клиентами.

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

Команда STORE раскрывает ещё одно ограничение смысла успеха. С модификатором .SILENT сервер может обновить все ещё существующие сообщения из запрошенного набора и ответить OK, хотя часть номеров уже относилась к удалённым другой сессией сообщениям. Квитанция подтверждает завершение разрешённой работы над сохранившимися объектами. Она не подтверждает, что исходный набор оставался неизменным.

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

COPY фиксировала смысл одной команды, а не всего ящика

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

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

Запись о совместимости, а не универсальное описание реализации

Информационная карточка RFC Editor относит RFC 2180 к Informational. Введение прямо говорит, что документ не определяет соответствие IMAP4 и не перечисляет все допустимые варианты; нормативной основой оставался RFC 2060. Он фиксирует поведение некоторых серверов и решения, которые сообщество рассылки IMAP сочло разумными.

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

Более поздние расширения сократили отдельные издержки, но не стерли границу между слоями реальности. RFC 2177 позволил клиенту в IDLE быстрее получать незапрошенные обновления, не отменяя смысловых ограничений. RFC 7162 добавил номера модификаций, VANISHED и QRESYNC для более эффективной повторной синхронизации. Ни одно расширение не превратило помеченный OK в доказательство мгновенного глобального согласия.

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