Resumo

  • O RFC 2034 exige class.subject.detail antes do texto de quase todas as respostas SMTP 2xx, 4xx e 5xx. A classe aprimorada deve concordar com a classe da resposta principal.
  • O servidor envia o código mesmo quando o cliente não usa EHLO e não dispõe de pedido ou recusa. O documento trata isso como exceção de compatibilidade estrita, não como permissão geral para extensões silenciosas.
  • A estrutura melhora classificação, retentativa e localização, mas comprova apenas a categoria declarada por um servidor naquela troca, não a causa real, a entrega final ou a leitura.

Um sistema automático sabe que 550 é uma negativa permanente. Ainda assim, pode precisar distinguir endereço inexistente, encaminhamento proibido e política de acesso. Se essa distinção depender de procurar palavras na frase seguinte, cada produto e cada idioma passam a fazer parte do código do remetente.

Publicado em outubro de 1996, o RFC 2034 preservou a resposta SMTP tradicional e o texto para pessoas. Entre os dois, no começo do campo textual, inseriu uma marca com classe, assunto e detalhe. A decisão ampla continuou no código de três dígitos; a classificação fina ganhou formato estável; a explicação permaneceu livre para ser clara e localizada.

Estrutura adicional no lugar certo

A extensão é anunciada como ENHANCEDSTATUSCODES, sem parâmetro e sem novos verbos. A classe só pode ser 2, 4 ou 5, enquanto assunto e detalhe têm de um a três dígitos. O primeiro componente deve acompanhar o código principal: 2xx com 2.X.X, 4xx com 4.X.X, 5xx com 5.X.X.

Essa correspondência impede que a mesma linha mande sinais de controle incompatíveis. O cliente mantém a lógica geral de SMTP e usa os componentes adicionais para separar condições dentro de uma classe. Filas, alertas e equipes podem agir sobre categorias comuns sem interpretar prosa variável.

Também fica mais fácil explicar o evento a uma pessoa. Uma interface em português pode renderizar uma mensagem adequada a partir do código e preservar o texto original. Mas essa tradução editorial não amplia a evidência. 550 5.1.1 mostra a declaração de um problema permanente de caixa de destino; não examina a base remota nem demonstra que a regra aplicada era correta.

Nem toda resposta recebe o prefixo

O requisito cobre linhas 2xx, 4xx e 5xx, exceto a saudação inicial e respostas a HELO ou EHLO. Respostas 3xx estão fora. Por isso o diálogo do RFC deixa 354 sem código aprimorado, embora use códigos em aceitações, rejeições e encerramento.

O contexto precisa sobreviver na telemetria. Um teste que exige o prefixo depois de qualquer código SMTP acusará falha onde há conformidade. Comando anterior e posição na sessão são necessários para distinguir exceção de omissão.

Os exemplos mostram 2.1.0, 2.1.5, 5.1.1, 5.7.1, 2.6.0 e 2.0.0. Eles demonstram a gramática, não uma cadeia de custódia até o leitor. Aceitar uma mensagem é uma mudança de estado do servidor receptor; não prova caixa de entrada, exibição, abertura ou leitura.

Funcionamento sem solicitação

O aspecto mais incomum é que o cliente não opta pela mudança. Servidores compatíveis incluem os códigos com ou sem EHLO. Não existe comando de ativação nem de recusa.

A compatibilidade vem do confinamento sintático. Clientes antigos já tinham de aceitar texto após o código principal e podem tratar o novo prefixo como parte desse texto. Os autores também consideraram fraca a implementação de erros SMTP e quiseram que clientes estendidos ou não recebessem categorias mais compreensíveis.

O próprio RFC limita o precedente: chama o mecanismo de caso muito especial e proíbe usá-lo para justificar mudanças futuras sem anúncio do servidor e comando correspondente do cliente. Ausência de negociação só é defensável aqui porque o efeito fica dentro de um campo existente e não cria uma nova sequência de estados.

Uma resposta multilinha, uma classificação

Quando a resposta ocupa várias linhas, o mesmo código aprimorado deve iniciar o texto de cada uma. O exemplo repete 5.7.1 em duas linhas 551; as regras gerais de SMTP também exigem o mesmo código principal.

A repetição preserva a categoria em registros processados linha a linha e impede que uma única resposta assuma condições incompatíveis. O texto pode acrescentar contexto, mas a declaração operacional permanece única.

O detalhe adicional traz exposição. A seção de segurança do RFC 2034 observa que mais informação ensina mais sobre o servidor e pode ajudar alguém a contornar proteções. Nomes internos, existência de contas, rotas de encaminhamento, regras e limiares não devem aparecer apenas porque o campo comporta.

Boa implementação combina consistência e minimização: repete a categoria, oferece orientação útil e não entrega o raciocínio interno a um par remoto desconhecido.

A evidência termina na declaração recebida

Uma categoria 4 pode legitimamente colocar trabalho em retentativa; categoria 5 pode encerrá-la conforme política local. Assunto e detalhe podem direcionar o caso a endereço, capacidade, segurança ou configuração. Séries históricas podem mostrar que um servidor mudou sua classificação após uma versão.

Nada disso certifica a causa. O código não mostra por que uma consulta interna falhou, não avalia justiça de um filtro, não promete repetição do resultado e não prova preservação por intermediários. Uma resposta positiva também não atravessa todas as etapas posteriores da entrega.

O exemplo do RFC gera depois uma notificação e registra que o MTA relator omitiu códigos aprimorados de campos diagnósticos para reduzir ruído. Isso separa quatro artefatos: resposta ao vivo, registro da fila, relatório gerado e resumo exibido. Cada transformação pode remover informação e precisa de proveniência.

O RFC 5248 criou posteriormente um registro IANA para evitar conflitos de definição. Registro coordena vocabulário; não certifica uma ocorrência. Código registrado ainda pode ser emitido por software defeituoso ou ligado ao evento errado.

A disciplina é guardar o evento antes de explicar o mundo: par, hora, comando, código principal, código aprimorado, texto integral, limites de linha, resultado do analisador e ação local. Sintaxe, concordância e repetição são verificáveis. Causa, legitimidade e resultado exigem fontes independentes. O RFC 2034 tornou a declaração legível; não a tornou soberana.

Fontes