Resumo

  • O RFC 5248 criou custódia pública para os códigos de status SMTP ampliados, com três tabelas, referências, solicitantes, controladores de mudança e política de registro.
  • Essa custódia evita colisões no vocabulário; ela não audita o servidor que escolheu o código, o cliente que o interpretou, a fila que tomou uma decisão ou o sistema que recebeu a mensagem.

O registro resolve uma disputa de nomes

Antes de existir uma autoridade explícita para novas atribuições, a extensibilidade prevista no RFC 3463 começou a produzir definições incompatíveis. O problema não era falta de dígitos. Era falta de um lugar comum que dissesse qual significado estava ocupado, qual documento o sustentava e quem podia alterá-lo.

O RFC 5248 respondeu como Best Current Practice 138. Ele instituiu o registro IANA e atualizou documentos que já haviam estendido a família, entre eles os RFCs 4468 e 4954. O ganho foi institucional: implementações diferentes passaram a poder apontar para uma mesma definição e reduzir o risco de colisão.

Essa história importa porque delimita a autoridade alcançada. O registro consegue arbitrar um nome. Não enxerga a sessão SMTP em que o nome foi usado. Não sabe qual teste o servidor executou, se o destinatário mudou depois, se a fila repetiu a tentativa ou se o destino final aceitou a mensagem. Um código registrado continua sendo uma afirmação de quem o emitiu.

A gramática distribui o controle

O formato tem classe, assunto e detalhe. Em vez de uma lista plana, o RFC 5248 mantém tabelas de subcódigos de classe, subcódigos de assunto e códigos enumerados. A entrada enumerada junta assunto e detalhe, mas mantém a classe como curinga, pois a especificação pode permitir a mesma condição em mais de uma classe.

Uma linha contém código, resumo ou texto de exemplo, descrição, referência e situação normativa, solicitante e controlador de mudança. Para códigos enumerados, contém ainda um status SMTP básico associado. Esses campos respondem a perguntas de governança: de onde veio a definição, qual contexto a explica e quem tem legitimidade para corrigi-la.

O status básico associado não é exclusivo. O próprio RFC impede a leitura de que um código de três dígitos listado elimina todas as outras combinações. O campo pode ser Any ou Not given. Uma regra automática que exija correspondência única transforma metadado em proibição e perde casos que a especificação deixou abertos de propósito.

Há também um lugar formal para a incerteza. X.0.0 é o único código indefinido e cabe quando apenas a classe é conhecida. Ele não autoriza o operador a deduzir assunto e detalhe pelo histórico, nem converte a ausência de diagnóstico em confirmação genérica da causa.

O especialista avalia um significado proposto

O critério de novas atribuições é Specification Required. No RFC 5248, especificações fora do trilho normativo precisam estar prontamente disponíveis, e o objetivo declarado é evitar confusão e colisão sem criar obstáculos desnecessários. No quadro atual do RFC 8126, uma especificação pública e permanente é combinada à revisão de um especialista designado, que examina clareza, estabilidade e qualidade técnica.

O escopo da revisão termina na proposta compartilhável. O especialista não certifica versões de servidores, não reproduz falhas de produção, não compara logs de remetente e destinatário e não aprova a política de reenvio de uma empresa. Portanto, a aceitação de um código não transfere confiabilidade automática para cada ocorrência dele.

O regime de mudança reforça a separação. Uma entrada de padrão costuma mudar mediante atualização do padrão. Uma entrada não normativa fica com o controlador indicado. Ajustes ordinários corrigem descrição ou referência, em vez de reutilizar silenciosamente o número e o texto. A IESG conserva poder excepcional para resolver conflitos.

Nem todas as linhas iniciais nasceram da mesma forma. O RFC 5248 incorporou valores de RFCs e também valores já usados na indústria sem especificação publicada. Três condições de segurança foram colocadas sob controle da IESG. “Trust Relationship Required” recebeu X.7.14, substituindo um uso anterior de X.7.8. A correção do mapa semântico é verificável; a migração de cada programa e a interpretação de cada log antigo não são.

O primeiro dígito não prevê o futuro

O RFC 3463 usa a classe 2 para sucesso numa notificação de status de entrega. A classe 4 significa falha transitória persistente, na qual outra tentativa pode dar certo. A classe 5 significa falha permanente que em geral exige mudança da mensagem ou do destino.

Esses sinais orientam a interoperabilidade, mas não cancelam o tempo. O RFC 5321 manda o cliente agir pelo código, não pelo texto explicativo. 4yz permite repetir mais tarde sob as condições aplicáveis. 5yz indica que a mesma solicitação não deve ser repetida sem alteração. O documento também reconhece que uma condição aparentemente permanente pode ser corrigida.

Uma fila responsável precisa guardar mais: identidade da mensagem e do destinatário, número da tentativa, relógio, servidor que respondeu, rota, configuração e resposta posterior. 4.x.x não promete recuperação. 5.x.x não prova impossibilidade eterna. A classificação limita a ação imediata; não escreve o resultado futuro.

O RFC 2034 define como carregar códigos ampliados nas respostas SMTP. O RFC 5248 governa o vocabulário. A lógica que escolhe a resposta, o parser que a recebe, a fila que a armazena e a automação que decide constituem outros limites. Depois da aceitação por um relay, ainda é preciso observar o sistema final, a caixa ou aplicação e qualquer resultado humano.

Uma resposta mais precisa pode expor demais

A segurança acrescenta uma assimetria. O RFC 5248 alerta que códigos ampliados podem revelar detalhes da implementação interna. Durante autenticação, distinguir “usuário inexistente” de “senha incorreta” pode oferecer a um atacante um mecanismo de enumeração. As especificações devem orientar o servidor sobre quando restringir o detalhe.

Consequentemente, o código público pode ser menos específico que o diagnóstico privado por uma boa razão. O sistema de evidência precisa ligar os dois, junto da política de divulgação, sem exigir igualdade. Pouco detalhe externo não prova diagnóstico interno fraco; muito detalhe externo não prova causa verdadeira. São eixos diferentes.

Não pule os degraus da evidência

Primeiro se comprova que o código é sintaticamente válido. Depois, que a versão observada do registro contém a atribuição. Em seguida vem apenas a afirmação operacional: a implementação declarou aquela condição. A compatibilidade com o status básico, a preservação do comando e da resposta e a confirmação em logs ou transições de fila formam degraus posteriores.

Acima deles estão ação e desfecho: o reenvio atingiu a mensagem correta; uma nova transferência ocorreu; o destino aceitou; a caixa processou; uma pessoa ou processo usou o conteúdo. Nenhum degrau inferior herda a autoridade do seguinte. Normalizar todos em “entregue”, “adiado” ou “falhou” destrói diferenças que uma investigação precisará recuperar.

A disciplina de Lu Heng sobre running code e camadas de realidade ajuda a manter a fronteira. O registro coordena símbolos. A implementação executa uma interpretação. A telemetria observa transições. A organização toma decisões. O padrão continua valioso justamente quando não é usado para substituir as provas que pertencem às outras camadas.

Fontes