Кратко

  • RFC2061 оставляет разработчику выбор: поддерживать старое программное обеспечение или отказывать во взаимодействии. Распознавание варианта сервера ещё не подтверждает свойства отдельных операций. RFC2061
  • Компенсация изменения \Seen не равна получению данных без изменения флага; успешный COPY не удостоверяет сохранность метаданных IMAP2bis. RFC2061, RFC2060

Предпросмотр может показать нужный фрагмент письма, но оставить след на сервере. Вместо BODY.PEEK[section] RFC2061 предлагает BODY[section] с последующим ручным снятием \Seen при необходимости. Байты получены; обещание не менять состояние уже требует оговорок. В этом и состоит главный вопрос совместимости: какой сокращённый набор свойств клиент согласен предложить пользователю? RFC2061

Не единый протокол, а конкретный переход

Декабрьский RFC2061 1996 года — информационный меморандум, не стандарт. Его автор Mark Crispin из University of Washington описывал IMAP2bis как широко распространённый вместе с Pine, но не имевший однозначной спецификации. Это свидетельство своего времени, не измерение доли рынка. Автор признавал неполноту знаний и протокольный фольклор; речь шла о наиболее вероятном старом варианте, не обо всех реализациях IMAP. Ни одна из предложенных мер не обязательна для IMAP4. RFC2061

Исходный IMAP2 описан в RFC1176 августа 1990 года. IMAP4 из RFC1730 декабря 1994 года нужно отличать от IMAP4rev1 из RFC2060 декабря 1996-го: поддержка обеих версий требует обращения к обеим спецификациям. Сам RFC2061 следует читать вместе с RFC1176 и RFC2060. Более широкий RFC1732, также декабрьский документ 1994 года, охватывает и другие старые варианты; он не взаимозаменяем с более узким RFC2061.

При успешном CAPABILITY (OK) сервер сообщает поддерживаемые варианты IMAP4. Если клиент не узнаёт ни одного, RFC2061 предлагает считать сервер IMAP2bis; BAD указывает на IMAP2bis либо более ранний вариант. Это эвристика выбора режима, не достоверная идентификация неизвестного сервера и не проверка будущих операций. Таймаут, NO или сбой защиты нельзя приравнивать к BAD. RFC2061

Предлагаемые замены полезно разделить на три редакционных класса. Это способ анализа, а не терминология RFC2061.

Класс Замены и их границы
Близкая по задаче замена Вместо LISTFIND ALL.MAILBOXES: синтаксис и ответы похожи на FIND MAILBOXES из RFC1176, но сам старый FIND MAILBOXES вряд ли даст полезные сведения. Вместо * в последовательности — число сообщений из последнего незапрошенного ответа EXISTS; зафиксированного снимка ящика это не создаёт.
Приближение или компенсация SEARCH переформулируется по синтаксису RFC1176, иногда несколькими поисками, без гарантии одинаковой поддержки наборов символов и критериев. BODYSTRUCTURE заменяется нерасширяемым BODY, а секции HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT — номерами секций: более богатая семантика от переименования не возникает. Замены PEEK и .SILENT требуют отдельных оговорок ниже.
Функционального эквивалента нет Для элемента данных UID, команд UID и команды CLOSE эквивалентов нет. Порядковые номера не становятся постоянными идентификаторами; цепочка с EXPUNGE не становится эквивалентом CLOSE.

У LSUB, SUBSCRIBE, UNSUBSCRIBE нет прямых функциональных аналогов. Старые bboards были отдельным механизмом; RFC2061 рекомендует не реализовывать их команды в новом программном обеспечении, даже в серверах для старых клиентов. Всеобщая эмуляция здесь не обещана. RFC2061

Снять флаг — не отменить промежуточное изменение

RFC2060 различает обычный BODY[section], неявно устанавливающий \Seen, и BODY.PEEK[section], который этого не делает. Уже установленный до запроса \Seen нельзя вслепую снимать. Та же спецификация допускает изменение флагов другими участниками и рекомендует автоматические уведомления об изменениях.

Отсюда редакционный вывод: для совместно изменяемого состояния получение данных и компенсация — последовательность действий с записями, не атомарное сохранение исходного состояния. Другой клиент может увидеть промежуточный флаг либо изменить его сам. Совпадение значений до и после не исключает такого вмешательства. Это предел схемы, а не описанный в RFC2061 инцидент или утверждение об одинаковом режиме разделения флагов на всех серверах. RFC2061, RFC2060

Для FLAGS.SILENT, +FLAGS.SILENT, -FLAGS.SILENT меморандум предлагает соответствующие элементы STORE без .SILENT и игнорирование возвращённых нетегированных ответов FETCH. Но локальное игнорирование не отменяет ни отправку ответов сервером, ни изменение состояния, ни возможность наблюдения извне. RFC2061

Ответ об успехе не удостоверяет сохранность

С COPY неопределённость ещё глубже: из описания совместимости невозможно узнать, сохраняет ли сервер IMAP2bis флаги и внутренние даты. Рекомендация SHOULD сохранять их из RFC2060 не создаёт задним числом обязательства для IMAP2bis. Успешный COPY не подтверждает сохранность метаданных; испытание конкретного сервера подтверждает наблюдавшийся случай, не универсальное правило. Кроме того, TRYCREATE приходит отдельным незапрошенным OK, а не внутри NO: разбирать эту подсказку нужно с сохранением контекста отказа. Она не превращает неудавшийся COPY в успешный. RFC2061

В обратном направлении меморандум называет для хорошо написанного клиента IMAP2bis и сервера IMAP4 только проблему обратной косой черты в строках с кавычками: при наличии \ или " следует использовать литералы. Это оговорённая оценка известных проблем, не гарантия для любого старого клиента. RFC2061

Замена отсутствующего AUTHENTICATE командой LOGIN — исторический совет из документа, прямо оставляющего безопасность за рамками. Это не современная рекомендация передавать учётные данные открыто или снижать защиту. Документ IETF RFC8314 января 2018 года рассматривает использование TLS и относит нешифрованный почтовый доступ к устаревшим практикам. Это позднейший ориентир безопасности, не свидетельство о защите систем 1996 года. RFC2061

Источники и границы интерпретации

В эссе о добровольном принятии изменений 2026 года Lu Heng пишет: «Non-adoption is not a violation.» Здесь это помогает осмыслить добровольный выбор набора совместимости. В эссе о слоях реальности и символической власти 2025 года его формулировка — «Most conflicts persist because participants mix these layers.» Применительно к IMAP полезно отделить название поддерживаемой возможности от исполняемого действия и побочных изменений. Такое сопоставление — редакционная интерпретация позднейших суждений, не историческое доказательство поведения IMAP или намерений Mark Crispin в 1996 году.

Источник Роль в анализе
RFC2061 Основной исторический источник: замены, добровольность, ограничения и неизвестное.
RFC2060 IMAP4rev1: получение тела, флаги, уведомления и COPY.
RFC1176 Синтаксис IMAP2; не окончательная спецификация IMAP2bis.
RFC1730 IMAP4 образца 1994 года, отдельно от редакции 1996-го.
RFC1732 Более ранний и широкий обзор совместимости.
RFC8314 Только позднейшая граница безопасности: TLS для доступа к почте и её отправки клиентом.
Lu Heng: минимальная спецификация и добровольное принятие Позднейшая концепция добровольной совместимости, не свидетельство об IMAP.
Lu Heng: слои реальности и символическая власть Интерпретационная рамка, не техническая проверка реализации.