Resumo

  • Uma mensagem comum informa um caminho reverso para futuros avisos de entrega. Uma notificação usa MAIL FROM:<>, pois a falha da própria notificação não deve gerar outra e formar um ciclo.
  • O valor nulo pertence ao envelope SMTP; não equivale ao campo visível From:, não prova legitimidade e não dispensa controles. Servidores de submissão precisam aceitá-lo, enquanto HELO e SPF ainda oferecem uma superfície de avaliação do host.
  • Os DSNs estruturados acrescentaram correlação e resultados por destinatário, sem remover o estado terminal. Quando o relato remoto acaba, o sistema que o gerou conserva a obrigação de tratar localmente o último erro.

O problema começa depois do “sim”

Enquanto o cliente SMTP permanece conectado, uma recusa é simples. O servidor responde negativamente a MAIL, RCPT ou ao fim de DATA, e o cliente continua dono da mensagem. A falha percorre a sessão existente, sem precisar virar um novo email.

A situação muda quando o servidor responde positivamente depois de DATA. Ele aceitou a responsabilidade por entregar, retransmitir ou relatar um problema posterior. Um gateway pode então ficar indisponível, uma caixa pode desaparecer ou a expansão de uma lista pode revelar um endereço inválido. O cliente original já foi embora; a notícia do fracasso precisa ser enviada como outra mensagem ao caminho reverso do envelope original.

Se essa segunda mensagem anunciar uma caixa comum como seu próprio remetente, cria uma nova promessa. A impossibilidade de entregar o aviso gera um aviso ao remetente do aviso. Outra falha repete a operação. O mecanismo criado para preservar a responsabilidade passa a produzir uma sequência sem limite.

O RFC 821 já descrevia essa dificuldade em 1982. Ao tratar de falhas posteriores em tarefas de retransmissão, advertia contra mensagens de notificação sobre problemas em mensagens de notificação e mostrava a forma que interrompe o ciclo: MAIL FROM:<>.

Os sinais <> não representam uma caixa postal com nome vazio. Eles codificam a ausência deliberada de um destino remoto para o próximo relatório de entrega. A mensagem ainda tem um sistema gerador, uma conexão, destinatários e rastros. “Sem remetente” é, portanto, uma abreviação enganosa: não falta um produtor; falta somente a aresta para outro bounce.

Aceitar o vazio também significa obedecer ao fim

O RFC 1123 transformou a antiga técnica em requisito de host. Uma implementação SMTP deve suportar o caminho reverso vazio e não pode rejeitar MAIL FROM:<> apenas porque não há um endereço convencional.

O texto também fecha a regra: a notificação de uma falha descoberta após a aceitação usa caminho reverso nulo; se o endereço ao qual ela seria enviada já for nulo, não se envia a notificação. Há duas obrigações inseparáveis. Recusar todo nulo elimina relatórios legítimos. Aceitar a sintaxe, mas responder a ela, restaura a recursão.

Esse “nada” possui semântica positiva. Ele permite distinguir um campo ausente por engano de um estado final escolhido pelo protocolo. Sistemas de banco de dados e automações que preenchem todo vazio com um valor provável podem destruir justamente a informação necessária para o encerramento.

Envelope, From e Reply-To não são o mesmo endereço

O caminho reverso é dado durante a transação SMTP. Já o From: visível participa da conversa humana, e Reply-To: pode orientar uma resposta consciente. Uma notificação automática pode mostrar no cabeçalho o nome do serviço que a criou e, simultaneamente, usar envelope MAIL FROM:<> para dizer ao transporte que não deseja outro DSN.

Copiar o From visível para o envelope porque o campo parece mais completo muda o grafo de controle. Um robô que encontra o envelope vazio e responde ao Reply-To também reabre a aresta que o emissor fechou. A separação não é preciosismo: uma superfície explica autoria ao leitor; outra distribui responsabilidade mecânica por falha de entrega.

O RFC 5321 mantém essa disciplina e o marco da resposta positiva após DATA. Antes da aceitação, rejeitar cedo costuma ser melhor quando há evidência suficiente: o cliente real recebe o erro na sessão e não é preciso mandar um bounce a um caminho reverso que pode ter sido falsificado.

Depois da aceitação, certos problemas são inevitavelmente tardios. DNS temporário, reprocessamento, listas e saltos seguintes podem falhar. O aviso então é necessário, e o endereço nulo contém o risco ao impedir que esse ramo crie descendentes.

Isso não resolve sozinho o backscatter. Um atacante pode colocar o endereço de uma vítima no caminho reverso de uma mensagem comum; um servidor que aceita e depois devolve ainda enviará o primeiro aviso à vítima. O nulo impede avisos sobre esse aviso, mas não corrige a atribuição inicial. Rejeição durante a transação, autorização do host e política de abuso protegem bordas diferentes.

O fim remoto devolve o problema ao operador

Se um DSN válido não puder ser entregue, a cadeia externa precisa acabar. O problema operacional, porém, continua existindo. O RFC 5321 permite registrar ou transmitir localmente informações sobre falhas de mensagens com endereço nulo e menciona o encaminhamento ao postmaster capaz de corrigir o sistema. Essa rota interna não pode gerar mais um DSN externo.

Há aqui uma fronteira de governança. O relato remoto informa ao domínio que ofereceu um caminho reverso o resultado de uma responsabilidade transferida. O alerta local informa ao operador: “nosso relatório terminal também falhou; verifique fila, roteamento e configuração”. Encerrar o primeiro não autoriza apagar o segundo.

IDs de fila, envelope original, resultados por destinatário, último diagnóstico e horizonte de tentativas precisam ser preservados segundo limites operacionais e de privacidade. <> determina quem não deve receber outra mensagem, não aquilo que o sistema pode esquecer.

O DSN ganhou estrutura sem ganhar um novo remetente

Avisos antigos variavam em texto e idioma, o que dificultava a correlação automática. O RFC 3461 definiu a extensão SMTP para Delivery Status Notifications. ENVID leva um identificador de envelope escolhido para correlação; RET controla quanto da mensagem original volta; ORCPT preserva o destinatário antes de reescritas. NOTIFY permite solicitar SUCCESS, FAILURE ou DELAY; o valor exclusivo NEVER solicita nenhum aviso.

Esses parâmetros expressam preferência de relatório e contexto probatório. Não deveriam alterar a aceitação de MAIL ou RCPT que seria válida sem eles. E não superam a regra terminal: um MTA não deve gerar DSN para uma mensagem cujo MAIL FROM seja nulo, ainda que um cabeçalho pareça oferecer outro remetente.

Quando um DSN é transmitido, seu endereço de remetente deve ser nulo. A transação do próprio DSN não usa RET; se trouxer NOTIFY, ele deve ser NEVER. O relatório pode ser detalhado, mas recusa categoricamente um relatório sobre si mesmo.

O RFC 3464 estruturou o conteúdo como multipart/report de tipo delivery-status: uma parte legível por pessoas, outra message/delivery-status para máquinas e, conforme regras de retorno e privacidade, material da mensagem original.

Cada DSN trata exatamente uma mensagem original, mas pode separar vários destinatários. Action distingue estados como failed, delayed, delivered, relayed e expanded; Status carrega um código estruturado. Assim, sucesso para uma pessoa, atraso para outra e falha final para uma terceira não são reduzidos a um vago “a mensagem falhou”.

Listas podem suspender somente o membro que falhou; aplicações podem manter pendente quem ainda está em tentativa. A precisão, no entanto, amplia o risco de exposição de destinatários, endereços de encaminhamento e conteúdo original. O formato permite omissões em fronteiras confidenciais. E pode ser falsificado: campos estruturados são evidência operacional declarada, não não repúdio.

Bots de férias repetem o mesmo dilema

Notificações de entrega não são a única automação capaz de conversar consigo mesma. Respostas de férias, grupos, centrais de ajuda e processadores podem disparar uns aos outros. O RFC 3834 generaliza a prudência: um respondente automático não gera resposta cujo destino seja nulo e normalmente usa o Return-Path do envelope, em vez de adivinhar a partir de From ou Reply-To.

Quando uma resposta não deve receber outra resposta automática, pode sair com MAIL FROM:<>; havendo extensão DSN, NOTIFY=NEVER é apropriado. Mas terminar o ciclo não resolve consentimento nem amplificação. Endereços de retorno são fáceis de falsificar; um serviço não deve mandar conteúdo volumoso ou provocar efeitos sem base para acreditar que a parte afetada autorizou o pedido.

No ponto de submissão, o RFC 6409 determina que o caminho nulo, isoladamente, não seja causa de rejeição. Clientes legítimos produzem mensagens assim, inclusive certas notificações de disposição. O MSA ainda autentica a conta, verifica autorização, taxa e conteúdo. Reconhecer um estado reservado não significa confiar nele sem controles.

A caixa some, mas a identidade do host permanece

SPF costuma avaliar o domínio do MAIL FROM. Para o caso nulo, o RFC 7208 constrói a identidade MAIL FROM como postmaster no domínio da identidade HELO. Dessa forma, a relação entre o host transmissor e seu domínio ainda pode ser avaliada, mesmo sem uma caixa de remetente.

O resultado precisa ser interpretado com precisão. SPF não autentica o conteúdo do DSN, não prova a falha relatada e não identifica uma pessoa. Um host autorizado pode emitir um relatório incorreto. O mecanismo mostra apenas que o estado terminal não elimina toda superfície de autorização.

Também não se deve confundir caminho reverso nulo com null MX. O null MX é uma declaração DNS de que um domínio não recebe email. O caminho reverso nulo aparece no envelope de uma mensagem efetivamente em trânsito e encerra apenas o ramo de notificações daquela transação. Um fecha uma capacidade de destino; o outro fecha a recursão de responsabilidade.

Fontes e limites da evidência

A notificação original de impossibilidade de entrega e o rompimento de ciclo por MAIL FROM:<> constam no RFC 821: https://www.rfc-editor.org/rfc/rfc821.html

O suporte obrigatório ao caminho vazio e a proibição de notificar um retorno nulo constam no RFC 1123: https://www.rfc-editor.org/rfc/rfc1123.html

Os parâmetros de envelope DSN, o tratamento do remetente nulo e NOTIFY=NEVER constam no RFC 3461: https://www.rfc-editor.org/rfc/rfc3461.html

O DSN multipart estruturado, os campos por mensagem e destinatário e os limites de privacidade constam no RFC 3464: https://www.rfc-editor.org/rfc/rfc3464.html

As regras para respostas de férias, grupos e serviços constam no RFC 3834: https://www.rfc-editor.org/rfc/rfc3834.html

A transferência atual de responsabilidade SMTP, as classes de mensagem nula e a via local do postmaster constam no RFC 5321: https://www.rfc-editor.org/rfc/rfc5321.html

O uso legítimo do remetente nulo na submissão consta no RFC 6409: https://www.rfc-editor.org/rfc/rfc6409.html

A identidade SPF baseada em HELO para caminho reverso nulo consta no RFC 7208: https://www.rfc-editor.org/rfc/rfc7208.html

Esses documentos estabelecem obrigações do protocolo, não a autenticidade de um DSN específico ou o comportamento atual de um provedor. Este artigo não estima volume presente de bounces, rejeições, spam ou implantação.