Кратко

  • RFC 9787 — Informational RFC августа 2025 года, а не документ Standards Track. В разделе 9.5 он рекомендует шифровать черновики, если клиент не знает заранее, что итоговое письмо уйдёт открытым, или что хранилище Drafts недоступно потенциальному атакующему.
  • Защищённый черновик должен шифроваться только для собственного сертификата пользователя либо эквивалентного секрета, которым владеет только он. Предполагаемые адресаты не получают доступ до фактической отправки, а обычный ключ подписи автора не должен подписывать незавершённый текст.
  • Самая трудная часть — продолжение работы на нескольких MUA. Второму клиенту нужен доступ и к тому же почтовому ящику, и к секретному ключу расшифрования; RFC 9787 прямо оставляет безопасный межклиентский обмен ключами и сертификатами нерешённым вопросом.
  • IMAP и JMAP умеют обозначать состояние «черновик» и показывать переход к отправке, но эти метки не являются сами по себе полной криптографической политикой. Они описывают состояние объекта и хранилища, а не всю границу авторского обязательства.

Черновик — не уменьшенная копия отправленного письма

RFC 9787 опубликован как Informational и прямо говорит, что не является спецификацией Internet Standards Track. Это важная рамка: документ даёт реализационные рекомендации для MUA и описывает риски, а не объявляет новый обязательный транспортный протокол.

Раздел 9.5 начинается с практической привычки почтовых клиентов: незавершённое сообщение сохраняется в Drafts. Если такая папка находится вне непосредственного контроля пользователя — в качестве примера назван удалённый IMAP-ящик, — хранение открытого черновика создаёт очевидную точку утечки. Причём проблема существует ещё до того, как известно, каким будет итоговый режим отправки. Автор может в последнюю минуту выбрать шифрование; сохранённые до этого версии уже успели пройти через удалённое хранилище.

Отсюда рекомендация SHOULD: MUA следует шифровать все черновики, кроме случаев, когда он явно знает, что готовое письмо не будет зашифровано при отправке, либо что папка Drafts недоступна атакующему. Это не обещание абсолютной секретности и не измерение реального поведения поставщиков. Это узкая рекомендация в конкретной модели риска.

Следующее требование жёстче. Если черновик зашифрован, он MUST быть зашифрован только для собственного сертификата пользователя или эквивалентного секретного ключа, которым владеет лишь пользователь. Потенциальный адресат не должен становиться участником криптографического доступа только потому, что его адрес уже появился в окне составления. RFC 9787 проводит здесь ясную границу: шифрование для получателей относится к фактической отправке.

Сохранение между устройствами превращает секретность в проблему координации

Именно в межустройственном сценарии простая формула «зашифровать черновик для себя» становится операционной системой, а не одной криптографической операцией. Второй MUA сможет продолжить работу только при двух условиях: он видит тот же почтовый ящик и имеет доступ к секретному ключу, способному расшифровать сохранённый объект.

RFC 9787 не делает вид, что эта часть уже стандартизована. В приложении A.4.1 сказано, что многие пользователи обращаются к одному ящику более чем через один MUA, и будущая работа могла бы описать эффективный и безопасный обмен собственными сертификатами и секретным ключевым материалом между клиентами. Там же упоминается безопасная передача секретных ключей как часть ещё не закрытой задачи. Приложение A.4.2 отмечает альтернативу — переносимые аппаратно защищённые секреты, — но также оставляет рекомендации по такой схеме за рамками документа.

Это ограничивает то, что можно утверждать по источникам. S/MIME 4.0 и OpenPGP задают криптографические механизмы сообщений; OpenPGP, например, определяет формат переносимых секретных ключей. Но из наличия этих механизмов не следует, что существует широко внедрённый, единый и безопасный способ синхронизации именно ключей черновика между всеми почтовыми клиентами. Проверенные источники такого вывода не дают.

Почему обычная подпись должна появиться позже

Вторая граница раздела 9.5 касается не конфиденциальности, а значения подписи. Соответствующий MUA MUST NOT подписывать черновик обычным ключом подписи пользователя. Обоснование RFC осторожно, но существенно: неотказуемая подпись под незавершённым текстом может быть представлена как свидетельство того, что отправитель уже принял содержание, хотя решение ещё не было принято.

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

Если подпись черновика нужна лишь для криптографической координации между несколькими MUA одного пользователя, RFC предлагает договариваться об ином ключе. Механизм такого согласования не определён. То есть документ проводит границу назначения ключа, но не превращает её в готовую межклиентскую систему.

Метка «черновик» помогает хранению, но не заменяет криптографическую границу

IMAP4rev2 определяет системный флаг \Draft: сообщение ещё не завершено и помечено как черновик. RFC 6154 определяет специальное назначение почтового ящика \Drafts. JMAP Mail использует ключевое слово $draft; в спецификации оно прямо названо эквивалентом IMAP \Draft.

JMAP особенно полезен как иллюстрация перехода состояния. В примере EmailSubmission/set уже сохранённый черновик отправляется, после успешной операции с него снимается $draft, а объект перемещается из папки черновиков в Sent. Это хорошо показывает механическую границу: до события отправки объект имеет одно состояние хранения, после успешной отправки — другое.

Но механика не должна переоцениваться. \Draft, \Drafts и $draft не сообщают, каким именно ключом был зашифрован объект, какие клиенты могли его расшифровать, был ли применён обычный ключ подписи или каков был конечный набор получателей в момент отправки. Состояние хранилища — необходимая часть картины, но не вся политика.

Предложение Daniel Kade: квитанция хранения намерения черновика

Здесь полезен дополнительный редакционный механизм — «квитанция хранения намерения черновика». Это предложение Daniel Kade, а не требование RFC 9787 и не утверждение о существующем стандарте.

Её назначение узкое: сохранить минимальное доказательство того, в каком состоянии находился изменяемый объект между сохранением на одном MUA, продолжением на другом и фактической отправкой. Она не должна превращаться в копию письма или универсальный журнал активности.

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

Для границы отправки достаточно зафиксировать отсутствие шифрования для адресатов до фактической отправки, затем само событие отправки, клиент, время и дайджест конечного набора получателей. К этому добавляются хеш объекта, отметка об очистке либо tombstone, владелец квитанции и правило её проверки или истечения.

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

Три редакционные линзы, а не дополнительные нормы IETF

Running-Code Primacy Хэн Лу полезна здесь как напоминание: рекомендация и опубликованная идея не равны реальному внедрению. Поэтому нельзя превращать текст RFC 9787 в утверждение, будто поставщики уже одинаково реализуют межклиентские ключи черновика.

Minimum Initial Specification подсказывает другую дисциплину: общая граница должна оставаться узкой. Для черновика это означает отделить несколько необходимых инвариантов — кто может расшифровать объект, когда появляется доступ адресатов, каким ключом нельзя подтверждать незавершённый текст — от более широкой системы журналирования и корпоративной политики.

Reality Not Advocacy требует держать раздельно факт, вывод и предложение. Факт: RFC задаёт конкретные SHOULD, MUST и MUST NOT для черновиков. Вывод: межклиентская непрерывность превращает ключевой материал в центральную операционную зависимость. Предложение: квитанция может помочь сохранить доказательство перехода. Эти три уровня нельзя смешивать. И ни одна из этих редакционных линз не является доктриной IETF.

Что проверенные источники не позволяют утверждать

На дату исследования поиск errata для RFC 9787 не показывал совпадающих записей. Это состояние проверки, а не обещание, что оно никогда не изменится.

Также в проверенном наборе источников нет данных, позволяющих оценить распространённость реализации раздела 9.5, соответствие конкретных поставщиков, измеренный масштаб утечки открытых черновиков, юридический эффект подписи незавершённого текста или наличие стандартизованного механизма обмена ключами черновика между MUA. Наличие S/MIME, OpenPGP, IMAP или JMAP не закрывает эти пробелы автоматически.

Именно поэтому полезно читать раздел 9.5 как описание границы состояния. До отправки удалённое хранение не должно превращать незавершённый текст в доступный сервису открытый объект; предполагаемые адресаты не должны получать ключевой доступ; обычная подпись автора не должна прикреплять к черновику значение окончательного подтверждения. После фактической отправки набор участников и криптографическая цель меняются. Между этими состояниями и находится самая трудная часть — безопасно перенести изменяемый объект и возможность его расшифрования с одного клиента на другой, не стирая различие между «сохранено» и «отправлено».

Источники