Resumo

  • O RFC 9787, seção 9.5 trata o rascunho como um estado diferente da mensagem enviada: recomenda criptografar rascunhos quando a pasta remota possa expô-los e exige que um rascunho protegido seja cifrado apenas para o próprio usuário, não para destinatários previstos.
  • A continuidade entre dispositivos depende de outro MUA ter acesso à mesma caixa postal e a uma chave secreta capaz de descriptografar. O próprio RFC reconhece que o compartilhamento seguro desse material entre clientes continua sem mecanismo definido no documento.
  • Um MUA conforme não deve assinar o rascunho com a chave normal de assinatura do usuário. A preocupação do RFC é que uma assinatura não repudiável sobre texto ainda inacabado possa ser interpretada como compromisso se o rascunho vazar; isso não equivale a estabelecer uma regra jurídica universal.
  • A proposta editorial deste artigo é um “recibo de custódia da intenção do rascunho”: um registro curto, com retenção estrita, para demonstrar como o objeto mudou de rascunho protegido para mensagem efetivamente submetida sem conservar o conteúdo sensível.

O texto que reaparece sem ter sido enviado

Imagine, explicitamente como hipótese, que algumas palavras salvas automaticamente em um notebook reapareçam segundos depois no telefone do mesmo usuário. A continuidade é útil, mas não deveria produzir duas conclusões que ainda não existem: que os destinatários já podem ler o conteúdo e que o autor já assumiu compromisso com aquelas palavras. O objeto atravessou dispositivos; não atravessou, por isso, a fronteira do envio.

Essa distinção é o núcleo operacional da orientação sobre rascunhos no RFC 9787, publicado em agosto de 2025 como RFC Informational, não como documento Standards Track. Muitos clientes de e-mail salvam mensagens ainda não enviadas em uma pasta de rascunhos. Quando essa pasta está em infraestrutura remota — o exemplo do texto é uma caixa IMAP — guardar o rascunho em claro pode expor conteúdo que o usuário ainda está formulando.

O detalhe importante é temporal. Enquanto a composição está em andamento, o cliente pode não conhecer a decisão final de proteção. O usuário ainda pode optar por enviar em claro ou criptografar. Por isso, o RFC afirma que o MUA SHOULD criptografar todos os rascunhos, salvo quando souber explicitamente que a mensagem será enviada sem criptografia ou que a pasta Drafts não pode ser lida por um atacante potencial.

A proteção, porém, não antecipa o envio. Quando um rascunho é criptografado, ele MUST ser cifrado somente para o certificado do próprio usuário, ou para uma chave secreta equivalente que apenas o usuário possua. O objetivo é permitir que o autor volte ao objeto e continue a composição sem transformar destinatários previstos em leitores antecipados. A criptografia destinada aos destinatários pertence ao ato real de enviar.

Esse desenho separa confidencialidade de autoridade. Um servidor de caixa postal pode armazenar um objeto que não consegue interpretar; outro dispositivo do mesmo usuário pode, se possuir o segredo necessário, recuperá-lo; os destinatários ainda permanecem fora desse círculo. A mensagem pode parecer pronta na interface e, mesmo assim, continuar sendo apenas material de trabalho.

O ponto difícil é a continuidade entre MUAs

A criptografia do rascunho cria uma exigência prática: um segundo MUA ligado à mesma caixa só consegue retomar a composição se também tiver uma chave secreta capaz de descriptografar o objeto. O Apêndice A.4.1 reconhece o problema de compartilhar certificados e chaves secretas entre vários clientes do mesmo usuário e deixa a solução para trabalho futuro. O Apêndice A.4.2 discute mecanismos portáteis como outra área de gestão de chave, também sem converter isso em um protocolo completo de continuidade de rascunhos.

Esse limite é decisivo para não transformar recomendação em implantação imaginária. S/MIME 4.0, definido no RFC 8551, e OpenPGP, especificado no RFC 9580, fornecem mecanismos de criptografia de mensagens. Isso não demonstra, por si só, adoção ampla de uma chave específica de rascunho sincronizada entre dispositivos, nem resolve como dois clientes independentes obtêm, atualizam e protegem o mesmo segredo operacional.

A mesma cautela vale para assinaturas. O RFC 9787 determina que um MUA conforme MUST NOT assinar o rascunho com a chave normal de assinatura do usuário. O motivo indicado é a associação que uma assinatura não repudiável pode criar entre o autor e um texto que ainda não está decidido. O documento sugere que, se uma assinatura de rascunho for usada para coordenação criptográfica entre MUAs do mesmo usuário, ela deveria empregar outra chave. Não define, contudo, o mecanismo de negociação, distribuição, rotação ou recuperação dessa chave.

Esse ponto deve ser lido estritamente. O RFC descreve um risco técnico e semântico de compromisso; ele não cria uma doutrina jurídica geral sobre o valor probatório de toda assinatura digital em todas as jurisdições.

Estado de armazenamento não é política criptográfica

Os protocolos de caixa postal conseguem marcar que um objeto é rascunho sem, com isso, definir toda a sua proteção. No IMAP4rev2, \Draft indica que a composição da mensagem não foi concluída. O RFC 6154 define \Drafts como atributo de uso especial para uma caixa destinada a mensagens em elaboração.

No JMAP Mail, o RFC 8621 usa a palavra-chave $draft e apresenta um exemplo de submissão bem-sucedida que remove esse estado e move a mensagem de Drafts para Sent. O exemplo é útil porque torna visível uma transição que interfaces gráficas costumam esconder: composição e submissão são estados distintos do mesmo fluxo.

Mas \Draft, \Drafts e $draft são sinais de armazenamento ou estado. Nenhum deles, sozinho, prova que o conteúdo foi cifrado para o autor, que destinatários ficaram sem acesso, que a chave normal de assinatura não foi usada, ou que dois clientes compartilham com segurança o segredo necessário para continuar a edição. A fronteira criptográfica precisa de evidência própria.

Proposta: um recibo de custódia da intenção do rascunho

A seguir está uma proposta editorial de Daniel Kade, não um requisito do RFC 9787: registrar um recibo mínimo que acompanhe a custódia do objeto sem reproduzir a mensagem. O propósito é responder, depois, a uma pergunta estreita: o sistema preservou a diferença entre “texto ainda em elaboração” e “mensagem efetivamente enviada” enquanto o objeto passou por salvamentos e clientes diferentes?

Evidência mínima Função
Referência do objeto e versão Distinguir qual estado do rascunho está sendo descrito.
Classe de armazenamento Registrar se o objeto estava em área tratada como rascunho.
Escopo criptográfico e identificador da chave exclusiva do autor Demonstrar que a proteção do rascunho permaneceu no domínio do autor.
Clientes capazes de descriptografar e atualizar Tornar explícita a continuidade permitida entre MUAs.
Último gravador ou evento de mesclagem Explicar qual cliente produziu o estado corrente.
Confirmação de que a chave normal não assinou aquele rascunho Registrar o fato relevante sem afirmar que a chave estava ausente do dispositivo.
Ausência de criptografia para destinatários antes do envio Preservar a separação entre composição e entrega.
Evento real de envio, cliente, horário e digest do conjunto final de destinatários Marcar a transição efetiva de autoridade.
Hash do objeto Vincular o recibo ao estado correspondente sem guardar o corpo.
Limpeza ou tombstone Indicar o destino do estado de rascunho depois da transição.
Responsável e data de revisão ou expiração Limitar custódia e retenção da própria evidência.

O recibo não deveria reter corpo, assunto, lista irrestrita de destinatários, chaves, credenciais ou logs gerais do cliente. Também não convém tratar um hash comum como anonimização automática. Valores de baixa entropia podem ser enumerados; registros separados podem ser correlacionados; um digest de um conjunto pequeno e previsível pode revelar mais do que parece. Em ambientes que realmente precisem dessa evidência, a alternativa pode ser prova com chave ou acesso controlado, finalidade explicitamente limitada e retenção curta.

O recibo também não resolve concorrência. Se dois clientes editarem versões diferentes, ainda será necessário um comportamento de atualização ou mesclagem. A função do registro é mais modesta: deixar um rastro suficiente para distinguir qual cliente gravou ou combinou estados, e qual evento foi o envio real.

O que as fontes não permitem concluir

No corte desta reportagem, a consulta de errata do RFC 9787 não apontava errata correspondente. Isso não amplia o alcance do documento. Nenhuma das fontes revisadas estabelece prevalência de criptografia de rascunhos, conformidade de fornecedores, volume medido de vazamentos, efeito jurídico de assinaturas de rascunho ou um mecanismo padronizado de troca de chave de rascunho entre dispositivos.

A página de informações do RFC 9787 também deve ser lida junto com sua categoria: trata-se de orientação Informational. Recomendação não é prova de implantação. Esse é um uso útil, mas limitado, de três lentes editoriais associadas a Heng Lu: Running-Code Primacy lembra que texto normativo ou recomendação precisa ser separado do que sistemas realmente executam; Minimum Initial Specification incentiva manter estreita a fronteira comum necessária; e Reality Not Advocacy oferece uma disciplina editorial para distinguir descrição de promoção. Aqui, essas ideias são lentes de análise, não doutrina da IETF.

A separação metodológica é simples: fato é aquilo que os RFCs realmente especificam; inferência é a consequência operacional que decorre desses estados e dependências; proposta é o recibo de custódia sugerido acima. Misturar as três categorias faria parecer que existe hoje uma solução padronizada de sincronização e prova que as fontes não demonstram.

Fontes