Resumo

  • A RFC 3461 permitiu pedir notificações de sucesso, falha ou atraso por destinatário, além de carregar a identidade da transação e do destinatário original. A RFC 3464 organizou a resposta em campos legíveis por máquinas.
  • A própria linguagem contém limites: delivered não significa lido, relayed marca uma fronteira sem responsabilidade por confirmação final, e uma DSN estruturada ainda pode ser forjada, perdida ou reduzida por confidencialidade.

A antiga mensagem de devolução tentava servir a três públicos. Explicava a falha para uma pessoa, entregava pistas a um operador e oferecia algum material para um programa associá-la ao envio. Cada sistema escrevia de um jeito e devolvia trechos diferentes. Em uma lista grande, centenas de avisos podiam chegar sem revelar com segurança qual host, qual destinatário e qual transação tinham falhado.

O problema tocava a responsabilidade central do SMTP. Ao aceitar RCPT, um servidor normalmente assume entregar ou avisar depois que não conseguiu. Mas “avisar” não esclarece se o remetente deseja sucesso, falha, demora incomum ou silêncio. Também não preserva naturalmente o destinatário inicial quando encaminhamentos alteram o endereço operacional.

As RFCs 3461, 3463 e 3464, publicadas em janeiro de 2003, separaram pedido, formato e diagnóstico. A primeira leva a solicitação no envelope SMTP; a segunda define o relatório; a terceira fornece códigos de estado independentes do transporte. O conjunto não inventa uma promessa de entrega. Ele distribui com precisão quem pede evidência, quem observa uma ação e onde a certeza termina.

Quatro parâmetros carregavam escolhas diferentes

O servidor anuncia DSN no EHLO. Nenhum verbo novo é criado. MAIL recebe RET e ENVID; RCPT recebe NOTIFY e ORCPT.

NOTIFY vale para cada destinatário. SUCCESS, FAILURE e DELAY podem ser combinados, enquanto NEVER aparece sozinho. Sem o parâmetro, o servidor pode manter a notificação tradicional de falha, com ou sem atraso. O remetente escolhe quais notícias aceita, não o resultado que o MTA deve declarar.

DELAY tampouco fixa um prazo. O MTA que retém a mensagem decide quando a espera se tornou anormal, ainda sem conhecer o desfecho. A mesma condição 4.x.x pode acompanhar delayed enquanto há novas tentativas e failed quando a fila finalmente desiste.

RET=FULL pede o conteúdo completo no relatório de falha; RET=HDRS, apenas os cabeçalhos. Se não houver destinatário com falha, só os cabeçalhos devem retornar. A escolha contrapõe diagnóstico e exposição: devolver o corpo cria outra cópia em rota e armazenamento diferentes.

Uma mensagem possuía identidades que não eram intercambiáveis

ENVID identifica a transação do envelope e pode reaparecer como Original-Envelope-Id. O sistema de e-mail não interpreta seu valor; essa função pertence ao remetente. Por isso ele não é o Message-Id do cabeçalho. Um identifica uma submissão, o outro identifica conteúdo. O mesmo conteúdo pode ser submetido novamente, e uma transação pode incluir vários destinatários com destinos diferentes.

ORCPT conserva o endereço originalmente informado. Na primeira submissão deve coincidir com RCPT TO. Depois de um encaminhamento, o endereço usado na próxima etapa pode mudar e o original continuar ao lado. Um indica para onde segue a tentativa; o outro indica a qual destinatário do pedido inicial pertence a evidência.

Os dois valores permitem reconciliar transação e destinatário, mas não autenticam nada. Um ENVID plausível não prova a origem da DSN. ORCPT não prova que uma pessoa controla o endereço. São referências cuja utilidade depende de preservação pelos relays e de controles adicionais no destino.

Ação e condição ganharam campos próprios

A RFC 3464 modela a DSN como multipart/report. Vêm primeiro uma explicação humana, depois message/delivery-status com campos da mensagem e grupos por destinatário, e opcionalmente o conteúdo ou os cabeçalhos originais.

Cada destinatário recebe uma Action: failed, delayed, delivered, relayed ou expanded. O Status segue a RFC 3463: 2.x.x para sucesso, 4.x.x para falha transitória persistente e 5.x.x para falha permanente, com assunto e detalhe nos outros componentes.

Os campos não repetem a mesma informação. Uma espera de DNS pode manter o estado 4.x.x durante tentativas e depois do abandono. A Action muda de delayed para failed: o status descreve a condição; a ação registra a decisão operacional.

failed é terminal; delayed não. delivered encerra a responsabilidade para aquele destinatário, mas pode ser entrega a um distribuidor de lista e nunca significa leitura. expanded registra que um alias de múltiplos destinatários aceitou a mensagem e criou novos destinos; relatórios posteriores ainda podem surgir.

relayed revela a fronteira. A mensagem entrou em um ambiente que não assume gerar DSN de sucesso. O MTA comprova o repasse, não a caixa postal final. Em vez de chamar a passagem de entrega completa, o protocolo nomeia o ponto em que perdeu observabilidade.

A falha de uma notificação precisava acabar em silêncio

Uma DSN é e-mail e também pode falhar. Se isso gerasse outra DSN, sistemas inalcançáveis criariam uma sequência infinita de avisos sobre avisos. Por isso, uma DSN enviada por SMTP usa o caminho reverso nulo MAIL FROM:<>; sua falha não produz nova DSN na rede.

A estabilidade exige abrir mão da visibilidade recursiva. O remetente talvez nunca saiba que o relatório sumiu. Essa incerteza limitada evita um ciclo ilimitado.

Relays compatíveis devem repassar solicitação e identificadores. Ao entrar em outro ambiente de mensagens, o gateway apenas tenta preservar a semântica. Encaminhamento confidencial ainda pode ocultar o destino, omitir campos remotos ou interromper notificações positivas. Telemetria completa e privacidade do destinatário nem sempre cabem juntas.

Formato comum não era prova de autenticidade

A RFC 3464 reconhece que uma DSN pode ser falsificada tão facilmente quanto e-mail comum. Um sucesso falso encerra acompanhamento; uma falha inventada provoca repetição, exclusão de lista ou atendimento equivocado. ENVID melhora a correlação, mas não é assinatura.

O material devolvido cria outra exposição. FULL pode replicar uma mensagem sensível em novos sistemas, logs e caixas. Cabeçalhos já revelam participantes, assunto e caminho. O remetente escolhe a extensão do retorno, não controla todo armazenamento posterior.

O legado de DSN é uma gramática de autoridade limitada. O remetente escolhe pedido e referências. Os MTAs aceitam, repetem ou abandonam e relatam a própria ação. Gateways traduzem até onde conseguem. A confidencialidade pode fechar a trilha. Leitura humana permanece fora do SMTP.

O registro SMTP da IANA ainda associa DSN à RFC 3461. O recibo se tornou útil porque identifica transação, destinatário original, relator, ação e diagnóstico sem converter isso em promessa de caixa de entrada ou atenção humana. A fronteira faz parte da evidência.

Fontes