Resumo

  • A RFC 2298, de março de 1998, criou o pedido Disposition-Notification-To. O agente do destinatário podia ignorá-lo em silêncio ou, na versão original, devolver denied.
  • O aviso descrevia ações como exibir, encaminhar, processar e apagar a mensagem. A RFC recomendava fortemente o consentimento do usuário e limitava a um aviso por destinatário e mensagem. A RFC 3798, de 2004, retirou denied e failed por falta de uso.

Uma pergunta escondida no cabeçalho

É o fim dos anos 1990. Alguém envia um e-mail de trabalho e deseja saber se a mensagem apareceu do outro lado. Seu programa põe Disposition-Notification-To no cabeçalho, com o endereço para receber a notícia. A mensagem chega à caixa de entrada alheia. Ali começam as escolhas de outro software e de outra pessoa. O remetente escreveu a pergunta; o controle da resposta ficou na mesa do destinatário.

A RFC 2298 definiu as Message Disposition Notifications, ou MDNs. Na segunda seção, o texto trata o cabeçalho como pedido. O programa receptor pode deixá-lo passar sem resposta. A versão de 1998 também oferecia denied, resposta explícita de quem preferia guardar para si o destino da mensagem. Antes de enviar um aviso, a RFC recomendava fortemente obter consentimento do usuário. Isso podia acontecer a cada e-mail ou por uma preferência salva no programa. Pedir um recibo tinha regras de etiqueta escritas em bits.

As categorias do recibo eram concretas. Displayed dizia que o programa mostrou a mensagem a alguém que acessava a caixa. Dispatched podia incluir impressão ou encaminhamento. Processed abrangia trabalho feito por filtros ou servidores. Deleted registrava a exclusão. A definição do documento original descrevia eventos do programa. A palavra popular “lido” tentava resumir um processo humano que o campo da máquina não acompanhava.

O relatório ainda distinguia como o evento e o envio ocorreram. Havia uma marca para ação manual ou automática, e outra para a autorização dada a este aviso ou derivada de configuração anterior. Um displayed podia resultar de caminhos locais distintos. Separar as duas perguntas — o que ocorreu com a mensagem e quem permitiu contar — tornava o recibo mais honesto.

Um pequeno limite evitava que a cortesia virasse pingue-pongue de programas. Para cada destinatário, o agente só podia emitir uma MDN por mensagem. Uma MDN não podia pedir outra, nem sua chegada produzir uma nova. Imagine duas máquinas eternamente agradecendo uma à outra pelo último agradecimento. A RFC encerrou a cena antes da primeira repetição.

O endereço de retorno exigia cuidado próprio. Um remetente malicioso podia indicar um terceiro como destino dos avisos e fazer muitas caixas postarem recibos para uma pessoa estranha à conversa. A RFC recomendava comparar Disposition-Notification-To com Return-Path. Se as direções divergiam, faltava o caminho de retorno ou havia vários destinos, o programa deveria pedir confirmação ou deixar de enviar automaticamente. O texto citava loops de correio e bombardeio de mensagens. Um cabeçalho pequeno podia virar uma ferramenta de incômodo em escala.

O protocolo dividiu os papéis com precisão. O remetente expressava interesse. O programa receptor avaliava pedido, endereços e preferências. A pessoa podia consentir ou manter o silêncio. O aviso enviado, quando existia, relatava uma ação delimitada. O recebimento do e-mail não entregava ao remetente as chaves da caixa alheia.

A história guardou uma ironia para 2004. A RFC 3798 substituiu a de 1998 e removeu denied e failed da lista, citando ausência de implementação ou uso. O carimbo formal de recusa saiu da papelada. A ausência de resposta continuou disponível. A porta ainda podia permanecer fechada sem que a caixa escrevesse uma carta explicando por quê.

O “aviso de leitura” era, na verdade, uma conversa limitada entre sistemas. O remetente solicitava; o destinatário decidia; o software relatava o que tinha feito. A curiosidade podia viajar pelo fio, mas a permissão para respondê-la ficava no lugar onde a mensagem chegava.