Resumo

  • RFC 3503 transformou $MDNSent em memória comum do mailbox para coordenar vários agentes de usuário e impedir Message Disposition Notifications duplicadas.
  • O marcador podia ser gravado quando o usuário recusava, quando uma cópia enviada ou inacabada era salva e depois de decisões automáticas sem envio efetivo; ele autorizava a supressão futura, não comprovava um evento passado.

Um cliente de e-mail sozinho consegue guardar em seu próprio disco que já tratou um pedido de confirmação. O problema muda quando vários clientes acessam o mesmo mailstore por IMAP. O segundo programa enxerga a mensagem, mas não a memória privada do primeiro. Sem um estado compartilhado, cada um pode acreditar que ainda precisa responder.

RFC 3503, publicado em março de 2003, escolheu uma intervenção estreita. Não definiu comando nem resposta novos. Criou a palavra-chave especial de mailbox $MDNSent e estabeleceu uma disciplina de interoperabilidade. A mensagem armazenada carregaria o bastante para coordenar agentes que não compartilhavam outra memória.

O nome parece registrar uma conclusão: MDN enviada. As regras mostram outra coisa. No processamento automático, o cliente marcava toda mensagem sujeita à decisão, independentemente de a MDN ter sido realmente enviada. Se o usuário proibisse a notificação, a mesma marca podia impedir outro agente de tentar mais tarde. Ao salvar uma cópia de mensagem enviada, o cliente precisava aplicar a marca. Ao salvar uma mensagem inacabada, também.

Logo, histórias diferentes desembocavam no mesmo estado. A afirmação segura era prospectiva: nenhum agente conforme deveria gerar outra MDN para aquele objeto armazenado. A presença da palavra não identificava o agente, o consentimento, a criação do relatório, a submissão, o transporte ou a chegada. Muito menos demonstrava leitura humana.

O primeiro passo era descobrir se o mailbox sustentava esse estado. Ao selecionar a caixa, o cliente examinava PERMANENTFLAGS. O servidor deveria aceitar $MDNSent especificamente ou palavras-chave arbitrárias. Ainda assim, anúncio não era execução. Um STORE podia falhar com NO se a caixa tivesse atingido o número de palavras que conseguia guardar.

A recomendação para essa falha era não enviar a MDN. Enviar sem conseguir deixar a memória comum permitiria que outro cliente repetisse a ação. A especificação preferiu a ausência de uma notificação ao risco de multiplicá-la. Esse comportamento não promete exatamente uma execução diante de todos os acidentes; fecha a saída quando o mecanismo mínimo de coordenação não pode ser confirmado.

Os flags existentes não serviam como substitutos. \Recent era especialmente inadequado: em conexões simultâneas, o protocolo deixava indefinido qual delas veria o estado recente. Uma observação que aparece para um participante e não para outro não pode distribuir responsabilidade. \Seen poderia contribuir para uma decisão de não enviar, mas tinha significado próprio. \Draft protegia mensagens incompletas. Com $MDNSent presente, os demais indicadores eram ignorados para a geração da MDN.

O estado também era monotônico. Um cliente não podia remover $MDNSent depois de gravá-lo. Assim evitava reabrir uma solicitação antiga sem reconstruir sua história. Mas um bit que só avança não é um diário: não guarda quem decidiu, quando, por quê ou com qual resultado externo. Ele controla o próximo comportamento e nada diz de forma completa sobre o anterior.

A cópia precisava preservar o freio. O cliente deveria verificar se COPY mantinha $MDNSent. Numa transferência entre servidores feita por APPEND, precisava fornecer a palavra corretamente. Se o conteúdo chegasse sem a marca, o destino poderia interpretar perda de metadado como ausência de decisão.

A regra de ACL separava o direito de copiar do direito geral de editar flags. O servidor ainda verificava se o cliente tinha permissão para executar a cópia. Depois de autorizá-la, porém, deveria preservar $MDNSent mesmo quando faltasse a permissão de escrita de flags. Não era uma licença para alterar estado livremente; era conservação de uma propriedade do objeto copiado.

Maiúsculas e minúsculas não criavam identidades novas. Os exemplos de RFC 3503 tratavam $MdnSENt, $MdnSENT e $mdnsent como a mesma palavra e permitiam a busca por outra grafia. Uma divisão por capitalização destruiria justamente a memória compartilhada que a extensão pretendia criar.

O relatório de disposição pertence a outra camada. RFC 2298 forneceu o formato inicial, RFC 3798 o revisou e RFC 8098 tornou-se o Internet Standard STD 85. Mesmo ali, os tipos têm alcance limitado. displayed significa que o agente apresentou a mensagem a alguém que consultava o mailbox, sem garantia de que o conteúdo foi lido ou compreendido. processed pode ser trabalho de uma regra. deleted não prova que ninguém viu a mensagem nem que ela não poderá voltar.

A privacidade limita o envio. A preferência padrão deveria ser não enviar; diferenças de endereço exigem confirmação; uma MDN pode ser forjada, perdida, usada para bombardeio de e-mail ou revelar detalhes do cliente. RFC 8098 diz expressamente que MDNs não dão não repúdio de entrega nem garantem que uma mensagem foi ou não vista.

O registro posterior da palavra-chave tornou o significado mais claro. RFC 5788 definiu $MDNSent como palavra compartilhada que especifica que uma MDN não deve ser enviada para a mensagem anotada. Trata-se de uma proibição para o próximo ator, não de um certificado do ator anterior.

RFC 9007 levou a ideia ao JMAP e aproximou estado e ação. Uma chamada MDN/send deve organizar a atualização de $mdnsent; o servidor recusa a operação se ela não resultar nessa atualização e pode retornar mdnAlreadySent quando a marca já existe. A composição reduz a lacuna no método JMAP, mas não comprova atenção humana, entrega final ou conformidade universal de sistemas antigos.

Uma leitura operacional correta mantém uma escada. PERMANENTFLAGS anuncia capacidade. STORE OK aceita uma mudança de estado. $MDNSent manda suprimir novas MDNs. Construção, submissão, trânsito e chegada da notificação exigem recibos próprios. O campo de disposição contém uma alegação tipada. Atenção, entendimento e resposta da pessoa ficam além.

A lição histórica é que uma camada comum pode ser poderosa justamente por ser fina. Os clientes precisavam compartilhar a regra contra repetição. Não precisavam entregar ao servidor autoridade sobre o que uma pessoa leu, entendeu ou aceitou. O registro coordenava uma ação sem se tornar soberano sobre o resultado.

Quando sistemas posteriores tratam o rótulo como prova, a ordem se inverte: um freio vira histórico, histórico vira entrega, entrega vira leitura. RFC 3503 oferece o antídoto em suas próprias rotas de escrita. Às vezes, $MDNSent estava correto porque nenhum recibo deveria sair — e nenhum saiu.

Fontes