Resumo

  • A source route explícita era estado mutável do envelope SMTP: cada relé consumia a primeira etapa do forward-path e acumulava essa etapa no reverse-path.
  • Rota e mailbox absoluto eram conceitos distintos; envelope e cabeçalhos To: e From: também. O caminho não autenticava autoria nem comprovava os saltos percorridos.
  • MX e nomes de domínio globalmente significativos entregaram a escolha normal do próximo salto ao MTA, ao DNS e à política local. Entender a sintaxe antiga deixou de significar obedecê-la.

O endereço tinha uma parte que era gasta

Depois de apresentar um reverse-path em MAIL FROM, um cliente poderia emitir:

RCPT TO:<@ONE,@TWO:JOE@THREE>

O RFC 821 chama o argumento de RCPT de forward-path. À direita dos dois-pontos, JOE@THREE é o mailbox absoluto. À esquerda, @ONE,@TWO indica como chegar até ele. O documento faz questão de separar a identidade do destino da rota até o destino.

Quando ONE reconhece a si próprio no primeiro elemento, remove esse elemento. O que segue é @TWO:JOE@THREE. Ao mesmo tempo, ONE acrescenta sua identidade ao início do reverse-path. A etapa não some: deixa de orientar um percurso ainda por fazer e passa a compor o caminho para uma eventual mensagem de impossibilidade.

Essa dupla alteração revela por que não se tratava apenas de uma grafia comprida para e-mail. O caminho para a frente era consumível; o caminho de retorno acumulava responsabilidade já atravessada. Cada relé executava uma transição, não apenas consultava um rótulo.

O envelope carregava obrigações diferentes do cabeçalho

O reverse-path de MAIL FROM não precisa coincidir com o From: visto pelo leitor. Ele serve à transação SMTP e ao encaminhamento de falhas posteriores. Não é Reply-To:, não certifica o autor e não prova quem escreveu o conteúdo.

O forward-path de RCPT TO tampouco precisa aparecer em To: ou Cc:. Um mesmo corpo pode ter vários destinatários de envelope; Bcc existe justamente sem exposição no cabeçalho; um nome no texto pode não ser destinatário daquela sessão.

O RFC 822 separa rota e addr-spec em route-addr e já desencoraja source routing sem necessidade especial. A proximidade histórica entre formas de endereço não dissolve a separação entre mensagem e transporte.

Por isso, dizer que ONE moveu a rota “para trás” não significa que tenha editado o campo From:. O objeto modificado é o envelope. Uma investigação que guarda apenas a mensagem entregue pode perder exatamente a instrução que determinou o comportamento do relé.

A identidade do relé dependia do lado da fronteira

Ao se inserir no reverse-path, ONE deveria usar o nome pelo qual era conhecido no ambiente de saída, não repetir cegamente o nome usado no ambiente de entrada. O detalhe do RFC 821 reconhecia gateways entre comunidades e sistemas de nomes diferentes.

Assim, uma lista aparentemente completa ainda precisava de interpretação local. O mesmo agente podia ter uma designação de um lado e outra do outro. Para que o retorno funcionasse, o próximo ambiente precisava compreender o nome gravado.

Se o servidor atual não fosse o primeiro elemento da rota, não poderia simplesmente eliminá-lo. Aquele elemento poderia selecionar o próximo SMTP. O direito de consumir uma etapa dependia de sua posição e do reconhecimento do próprio relé.

Nada nessa regra autenticava nomes. Uma source route não demonstrava controle de domínio, trânsito real por cada máquina ou integridade da sequência. Era uma instrução operacional, não um recibo criptográfico do percurso.

MX tornou o endereço mais estável que a rota

No RFC 974, o domínio de destino publica mail exchangers com preferências. O MTA remetente consulta esse domínio e tenta candidatos conforme as regras. O usuário continua escrevendo user@domain; a infraestrutura decide a próxima conexão no momento do envio.

MX não converte uma source route em registro DNS. Os hosts listados não são uma cadeia serial de passagens obrigatórias. O RFC 974 alerta contra perseguir MX de MX recursivamente para montar rotas extravagantes.

O ganho foi separar algo durável de algo mutável. O domínio pode trocar os servidores receptores sem alterar o mailbox. O MTA pode considerar falha, alcance e política atuais. Uma agenda não congela a topologia da semana em que o endereço foi salvo.

Com a separação, mudou também quem pode corrigir um erro. Uma source route velha pode estar copiada em filas, aliases e cadastros. Um registro MX pode ser atualizado no ponto que administra o domínio. A rota vira uma decisão transitória, não parte permanente da identidade.

A gramática teve uma aposentadoria em duas velocidades

O RFC 1123 afirma que um Sender-SMTP não deveria enviar uma rota explícita @...: em RCPT. A escolha arquitetural foi por nomes universais: user@domain, domínios globalmente interpretáveis e MX atenderiam à necessidade principal.

Mas o Receiver-SMTP ainda precisava aceitar a sintaxe. Aqui, aceitar quer dizer reconhecê-la corretamente, não conceder relay irrestrito. Um servidor que não implementasse o trajeto solicitado poderia, sob as condições do padrão, tentar entrega direta ao domínio depois do @ mais à direita.

Essa assimetria impede duas rupturas. Se clientes e servidores abandonassem a forma no mesmo dia, endereços em software antigo e filas se tornariam ilegíveis. Se todos continuassem a gerar e obedecer, nenhuma aposentadoria ocorreria. Parar de produzir e continuar entendendo deixa a base instalada escoar.

A compatibilidade preserva legibilidade, não autoridade. O servidor pode interpretar a intenção histórica e, ainda assim, aplicar uma política moderna de ignorar, rejeitar ou tratar o destino final.

Parser compatível não é open relay

Uma implementação pode decompor corretamente @ONE,@TWO:JOE@THREE e negar o trânsito porque o cliente não está autorizado. Autenticação, rede de origem, domínios locais e política antispam pertencem à decisão de relay; a gramática pertence ao parser.

O RFC 2821 marca source routes como deprecated. Servidores devem estar preparados para receber a forma, normalmente devem ignorar a rota e podem recusar relay. Clientes não devem continuar a gerá-la.

Ao ignorar o caminho, o servidor não deve copiar os nomes intermediários para o reverse-path. A transferência descrita no RFC 821 corresponde ao modo em que o trajeto é realmente utilizado, não a uma reescrita universal de todo SMTP posterior.

Se escolher usar a rota numa exceção, o servidor deve encaminhar para o primeiro domínio indicado e não inventar atalhos. Usar apenas a parte conveniente produziria uma decisão que nem segue o texto nem assume claramente que o ignorou.

Logo, “aceitou source route” é uma frase insuficiente. É preciso perguntar se aceitou a sintaxe, o destinatário, a responsabilidade após DATA ou o serviço de trânsito. Esses eventos têm efeitos e riscos diferentes.

Houve um tempo em que o usuário possuía o melhor mapa

O RFC 1711, de 1994, descreve a source route explícita como um MTA desejado pelo usuário integrado ao endereço. Ao receber a mensagem, o MTA retira a si próprio e continua com o restante.

Em um mundo de “ilhas de correio” pouco conectadas, saber qual gateway alcançava uma ilha distante podia ser essencial. A pessoa colocava no endereço uma informação topológica que a rede ainda não distribuía de modo universal.

Com maior interconexão, esse conhecimento do usuário perdeu utilidade cotidiana e passou a envelhecer mal. O RFC 1711 cita também o tratamento inconsistente entre relés como motivo para desencorajar a prática.

Essa é uma avaliação histórica, não uma medição atual. Ela não afirma que todo gateway ou diagnóstico desapareceu. Registra uma inversão: o mapa estático do usuário, antes solução para lacunas de conectividade, tornou-se interferência diante de sistemas dinâmicos mais próximos do estado real.

Percent hack, bang paths de UUCP e mapeamentos de gateways viveram problemas vizinhos, mas não são a mesma gramática nem necessariamente executam a mesma transição forward/reverse. Eles servem de contraste, não de substituto para o mecanismo @relay1,@relay2:user@host.

Obsoleto não significou apagado do parser

O RFC 5321 atribui a MX a eliminação da necessidade normal de rotas explícitas e aos nomes de domínio plenamente qualificados o fim da última justificativa geral relevante. Clientes só deveriam recorrer à forma em situações incomuns, como depuração ou um problema DNS grave e temporário.

Servidores ainda reconhecem a sintaxe. Podem negar relay, ignorar a rota e tratar o destino final ou, em circunstância limitada, utilizá-la sob as regras. O status obsoleto retira a forma do comportamento novo normal sem tornar entradas antigas incompreensíveis.

Ignorar a rota não garante sucesso. Alguns endereços antigos dependiam de nomes que só faziam sentido num ambiente intermediário. Depois de retirar os relés, o domínio final pode não resolver globalmente. Compatibilidade não é capacidade de adivinhar um namespace local perdido.

Assim, “suportado” esconde estados relevantes: reconhecido, preservado, ignorado, recusado ou utilizado. O destino pode resolver ou não. A responsabilidade pode ter sido recusada durante a sessão ou aceita antes de uma falha. Operar bem exige observar cada transição.

Texto de rota não é evidência de trânsito

Encontrar @ONE,@TWO em um registro prova a presença da string. Não prova que ONE a consumiu, TWO recebeu uma conexão ou THREE aceitou a mensagem. Para isso são necessários endpoints, respostas SMTP, resolução, fila e tempo.

O inverso também vale. Um log contendo apenas JOE@THREE não demonstra que a entrada já era simples. Um MTA pode ter removido o trajeto; um normalizador pode ter guardado só o mailbox; os cabeçalhos do corpo podem nunca ter carregado a source route.

O melhor registro preserva argumento bruto, decomposição, decisão use/ignore/reject, próximo salto e resultado. O endereço normalizado pode existir como derivação, nunca como substituto silencioso da evidência recebida.

Até um reverse-path que cresceu ao longo do percurso continua sendo mecanismo de devolução, não atestado. Não autentica cada nome nem garante uma passagem única e honesta. A força da conclusão deve permanecer dentro da função definida pelo protocolo.

Limites do conjunto de fontes

RFC 821, RFC 822, RFC 974, RFC 1123, RFC 1711, RFC 2821 e RFC 5321 fecham sintaxe, comportamento normativo e transição histórica. Não medem prevalência atual, conformidade de produtos, exposição de open relay, volume de ataques ou taxa de entrega.

Também não permitem fundir a source route SMTP com LSRR ou SSRR de IPv4. A semelhança no nome não iguala camada, objeto, agente de processamento ou limite de autoridade.