Кратко

  • RFC 2342 стандартизировала обнаружение правил именования для Personal, Other Users' и Shared Namespace.
  • Объявление ветви, ответ LIST, существование, SELECT, права, получение сообщения, отображение и человеческое внимание требовали разных подтверждений.

Сначала сервер выдавал легенду карты

Ответ ("" "/") ("~" "/") NIL позволяет клиенту составить имя ~mark/INBOX. Но он ничего не говорит о существовании Mark, видимости его INBOX или праве текущего пользователя открыть этот ящик.

Именно такую узкую задачу решала RFC 2342. Раньше клиент часто просил пользователя вручную указать локальный префикс. NAMESPACE возвращала три упорядоченных поля — личное, других пользователей и общее — с NIL либо списком префиксов и разделителей.

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

Широкий LIST мог не раскрыть никого

RFC 2342 предлагала добавить % к префиксу Other Users' и выполнить LIST. Одновременно серверу не следовало выдавать имена пользователей без list access. Он мог вернуть только разрешённые имена либо ответить NO на широкий запрос и потребовать конкретное имя.

В примере #Users/% не даёт результата, а #Users/Mike/% возвращает INBOX и Foo. Пространство имён не изменилось. Изменились точность запроса и политика раскрытия. Сокрытие списка защищает сведения об учётных записях и не даёт готовую поверхность для атаки.

RFC 9051 прямо определяет LIST как подмножество всех имён, доступных клиенту. Ответов может быть ноль. Имя может получить \Noselect или \NonExistent, а список подписок — содержать имя уже не существующего ящика.

Объявленная ветвь, показанное имя, подписка, существование и возможность выбрать ящик сейчас — разные состояния.

Видеть имя и читать содержимое — разные права

В RFC 4314 право l отвечает за видимость в LIST/LSUB, r — за SELECT/STATUS, s — за сохранение Seen/Unseen. Отдельные права регулируют создание, вставку, удаление, expunge и управление ACL.

Поэтому видимый ящик может быть недоступен для чтения. RFC 9051 рассматривает ситуацию, когда есть l, но нет r: LIST показывает имя, STATUS невозможен, а ящик отмечается как недоступный для выбора. RFC 8440 добавляет MYRIGHTS к расширенному LIST, однако разрешение всё ещё не равно выполненной операции.

Успешный SELECT доказывает больше: это соединение перешло в selected state и получило FLAGS, EXISTS, UIDNEXT и UIDVALIDITY. Но FETCH, обработка клиентом, видимость окна и внимание человека остаются впереди.

Даже \Seen не является распиской читателя. Его могут изменить FETCH, STORE, предпросмотр или фоновая синхронизация. Протокол хранит состояние сообщения, а не понимание.

Точное утверждение сильнее удобного преувеличения

RFC 2342 устранила одну догадку и не заменила её новой. Префикс помогал правильно задать следующий вопрос; ответ зависел от текущего объекта, прав и состояния сервера.

Это общий принцип инфраструктуры. Схема может определить форму ссылки, не создавая объект. CAPABILITY может объявить команду, не гарантируя успех. Зелёный контрольный ответ может открыть следующий тест, но не сертифицировать итог.

NAMESPACE показывала путь к двери. Она не подтверждала дверь и не могла свидетельствовать за читателя.