Resumo

  • Um Internet-Draft individual de 27 de outubro propõe o DeletedItem, com prazo de recuperação para mensagens, contatos, eventos, arquivos e scripts de filtro destruídos.
  • Em contas compartilhadas, ter podido ler o objeto quando ele foi destruído é a condição inicial para ver a cópia; expurgar e restaurar dependem de controles próprios.

Uma mensagem some da pasta de contratos da equipe. Para o correio normal, acabou. No rascunho JMAP Undelete, um servidor que adote a extensão manteria uma ficha paralela: data da destruição, prazo de expiração, resumo do objeto e, quando disponível, um blob para baixar o conteúdo. A conta anunciaria previamente quais tipos guarda e por quanto tempo uma exclusão nova pode ser desfeita.

O rascunho olha para a destruição efetiva. Ela pode vir de JMAP, de um expunge por IMAP, de uma exclusão POP3 ou do esvaziamento automático da lixeira. Mover uma mensagem para a lixeira ainda não aciona esse registro. É uma diferença pequena na tela e grande na promessa feita ao usuário: “recuperável” precisa de um ponto de partida identificável.

Na conta compartilhada, o primeiro porteiro trabalha com uma fotografia antiga. A seção 3.3 permite mostrar um DeletedItem somente a quem tinha direito de ler o objeto em pelo menos um contêiner no momento da destruição. Isso abre a possibilidade de análise, não um direito automático de entrada. O servidor pode restringir mais, inclusive ao dono da conta; se não consegue reconstruir os direitos passados com segurança, o texto recomenda esse caminho. O RFC 9670 descreve a partilha JMAP; a nova ficha obriga a confrontar esse controle com uma data anterior.

As outras duas perguntas seguem o presente. Para expurgar a ficha, a conta precisa permitir mayPurge e a pessoa deve poder remover o objeto dos contêineres onde ele estava. Para restaurar, deve poder criar um objeto no destino. Se a pasta antiga deixou de existir ou não admite escrita, o servidor tenta uma pasta padrão, como a caixa de entrada; se não houver destino permitido, falha. Um leitor antigo pode passar pelo filtro de visibilidade e esbarrar nas duas operações seguintes.

O prazo de uma ficha já criada tem peso: uma troca posterior na política de retenção não pode antecipar seu expiresAt. Ao vencer, o item deixa imediatamente de aparecer em qualquer método da extensão. O expurgo também encerra esse caminho de recuperação. A seção de segurança registra que uma sessão delegada ou credenciais roubadas com acesso à conta podem alcançar dados recém-destruídos. O Datatracker mostra apenas um rascunho individual em I-D Exists; o servidor citado usa sua própria interface de recuperação e ainda não implementou a interface JMAP proposta. Falta um teste de uma mudança de partilha depois da exclusão para sabermos quem vê a ficha numa implementação real.