Кратко

  • RFC 6154, опубликованный в марте 2011 года, определил необязательные атрибуты специального назначения в ответах IMAP LIST. Клиент может найти \Sent, \Drafts и \Trash без догадок о видимом имени папки.
  • \Sent может сопровождать автоматическое сохранение копий сервером или служить советом клиенту сохранять их самому. У одной папки бывает несколько ролей, а одна роль может принадлежать нескольким папкам.
  • Расширенный LIST допускает объявление SPECIAL-USE. Необязательные CREATE и METADATA дают способы запросить или изменить роль, если сервер согласен. Реестр IANA фиксирует общий словарь атрибутов.

Название папки выдавали за правило

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

В рекомендациях по реализации IMAP 1999 года упоминались привычные названия вроде «Sent Mail» и «Trash». Обычай облегчает жизнь людям. Он не связывает две программы одинаковым алгоритмом выбора. Название можно перевести или изменить; оно не говорит, выполняет ли сервер автоматическую запись. Клиент делал из текста на экране вывод о поведении системы хранения.

RFC 6154 перенёс назначение в ответ LIST. Первоначальные атрибуты: \All, \Archive, \Drafts, \Flagged, \Junk, \Sent и \Trash. Сервер может сообщать их вместе с другими свойствами папки. Пользователь волен видеть привычные ему имена, а программа ищет формальную роль. Так информация о размещении поступает от стороны, которая знает собственное хранилище.

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

Атрибут не отправляет письмо в папку

RFC 6154 прямо допускает два сценария для \Sent. Сервер может автоматически помещать туда копии исходящих сообщений. Или он лишь сообщает клиенту подходящее место для сохранения. Клиент, ожидающий автоматического действия там, где его нет, оставит папку пустой. Клиент, который сохраняет сам, когда сервер уже сохраняет, рискует создать дубликаты. Атрибут указывает место разговора; движение конкретного письма показывает исполнителя.

Остальные роли тоже не имеют единой механики. \All может быть виртуальным представлением сообщений и пропускать содержимое \Trash или \Junk. Значение \Archive зависит от сервера. \Drafts бывает виртуальным набором сообщений с флагом черновика или адресом, куда клиент кладёт незаконченный текст. \Trash зависит от модели удаления, в том числе от того, как клиент работает с IMAP-флагом \Deleted. Общие названия упрощают обнаружение различий, а не упраздняют их.

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

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

Обнаружить роль и получить разрешение — разные шаги

Расширение опирается на расширенный LIST. Поддерживающий его сервер объявляет SPECIAL-USE в CAPABILITY. Клиент может запросить только помеченные папки или попросить включить атрибуты в список; запрос отбора уже подразумевает возврат атрибутов. Обычный LIST также может содержать эти метки, причём для такого режима отдельной строки возможностей нет. В сетевой записи надо смотреть на команду и её ответ вместе.

RFC 6154 добавил необязательный параметр USE к CREATE. Если сервер отдельно объявляет CREATE-SPECIAL-USE, клиент может попросить создать папку с нужной ролью. Сервер вправе отказать из-за конфликта, перенести прежнее назначение или допустить две папки с одинаковым атрибутом. Если он не может создать папку с запрошенной ролью, он обязан отклонить создание целиком. Отказ нельзя превращать в локальное убеждение клиента, будто папка настроена.

При поддержке IMAP METADATA запись /private/specialuse может показывать роль существующей папки и, если разрешено, менять её. Сервер должен проверить запрос по собственным правилам. Переименование папки, назначение роли и перемещение письма — три разных действия с разными подтверждениями.

Иногда назначение запускает автоматическое поведение. RFC 6154 приводит \Junk: если сервер помещает туда письма, признанные спамом, а роль можно дать общей папке, ошибочно отсеянные личные письма окажутся видны другим. Сервер обязан решать, чей запрос на такую роль принимать. Маленькая метка становится рычагом доступа, когда за ней стоит работающий фильтр.

Официальные тексты устанавливают процедуру объявления и назначения ролей. Для ответа о конкретном ящике нужны датированные CAPABILITY и LIST, возможные CREATE или METADATA, а затем наблюдаемое место одной отправленной копии. Надпись на папке даёт меньше всего сведений.