Кратко

  • RESERVE делал имя ящика недоступным для других заявок, но RFC 3656 прямо уточнял: это ещё не означает, что ящик готов для клиентов.
  • Доступную активную запись обозначал MAILBOX — после локального создания и ACTIVATE. Такая последовательность рекомендовалась, но зависела от сотрудничества участников и не была обязательным условием команды сервера.

Сначала имя, потом ящик

Группе почтовых серверов нужно ответить на два разных вопроса: какой сервер закрепил за собой имя и можно ли сейчас открыть ящик? Опубликованный в декабре 2003 года экспериментальный RFC 3656 разделил эти ответы. MUPDATE должен был дать серверам IMAP и POP3 единое пространство имён, пока несколько машин совместно отвечали за доставку.

Обычная последовательность создания начиналась с RESERVE. Клиент просил мастер-сервер закрепить имя ящика за указанным местом. После ответа OK клиент создавал ящик локально и отправлял ACTIVATE с именем, местом хранения и ACL. Успешная активация переводила запись в активное состояние. Местоположение помогало направить клиента к серверу с ящиком, а ACL описывал права доступа.

Ответы показывают границу. RESERVE означает, что другое приложение уже не может занять имя, но RFC подчёркивает: ящик от этого не становится доступным клиентам в тот же момент. MAILBOX описывает запись, готовую к доступу. Если считать ответы синонимами, блокировка имени превращается в ложный сигнал готовности: локального объекта ещё может не быть или создание ещё не завершилось.

Атомарность поддерживалась общей дисциплиной

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

Это видно и по нормативным словам. Новые ящики SHOULD резервироваться до активации: проект предполагал, что аутентифицированные участники будут сотрудничать ради атомарности. Однако ACTIVATE не требует предыдущего RESERVE. Спецификация допускает это, чтобы упростить синхронизацию с фактическим расположением ящиков. Участник, обходящий общее правило блокировки, может создать несогласованное состояние базы. База не способна вывести локальную транзакцию, о которой ей не сообщили.

DEACTIVATE возвращал активное имя в зарезервированное состояние, но не удалял его из пространства имён. RFC также предупреждал, что известная ACL-информация при этом может потеряться. Во время миграции или прерванного создания имя может оставаться занятым без опубликованного активного ящика. Записанное местоположение не доказывает, что пользователь вошёл в систему или прочитал сообщение.

У ответа реплики была временная граница

После UPDATE ведомый получал исходный список, а затем поток последующих изменений. Мастер должен был отправить изменение ведомому не позднее чем через 30 секунд после изменения основной базы. Ведомый мог отправить NOOP; после UPDATE ответ OK разрешалось вернуть лишь после отправки всех обновлений, ожидавших на момент этого NOOP. Это задавало ограниченную точку синхронизации, но не обещало, что база останется глобально актуальной после ответа.

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

Источники